[ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header Support

[Li, Johnson]

> 
> Please see previous comments in this thread, such as this one:
> http://openvswitch.org/pipermail/dev/2016-July/074980.html
> 
We are trying to remove the dependency on Simon's patch set, but we have 
similar implementation for the datapath, this is duplicated effort.
So we have to wait for Simon's patch to be merged then we only to add
The explicit push_eth/pop_eth command to add Ethernet encapsulation
Support for the NSH header. 
While waiting for Simon's patch to be merged, I will try to add the full
prototype for MD type 2(the current V2 patch's prototype doesn't contain
the MD type 2 TLV fields as match fields) first. I may try to split the patch into
two sets after the prototype is finished and the refactor the common codes
for both Geneve and NSH MD type 2, one for the common codes and MD 
type 1 support  the other for the MD type 2 support.
Does this make sense to you guys? 
> On Wed, Jul 13, 2016 at 10:06 AM, Brady Allen Johnson
> <brady.allen.johnson at ericsson.com> wrote:
> > Is the current implementation really dependent on Simon's patch?
> >
> > I understood that the current implementation is for ethernet+NSH and
> > VXLAN+ethernet+NSH which doesnt require Simon's patch. Simon's patch
> > VXLAN+ethernet+would
> > be needed for VXLAN-GPE+NSH, which is not in this implementation.
> > Maybe the authors can verify this.
> >
> > Regards,
> >
> > Brady
> >
> >
> >
> > On 13/07/16 18:59, Jesse Gross wrote:
> >>
> >> On Wed, Jul 13, 2016 at 7:55 AM, Jiri Benc <jbenc at redhat.com> wrote:
> >>>
> >>> On Wed, 13 Jul 2016 07:35:59 -0700, Jesse Gross wrote:
> >>>>
> >>>> I think history tells us how this will end - similar to IPv4
> >>>> options, implementations that don't implement TLVs will become
> >>>> deployed and then when there is a use for them it's no longer
> >>>> possible. Since I don't want OVS to have a half implementation or
> >>>> contribute to this issue, I'd like to see the whole protocol
> >>>> implemented before I apply anything.
> >>>
> >>> I see a big difference between this and IPv4. While in IPv4, the
> >>> options are extension to existing headers, here we're talking about
> >>> a completely different payload. It's more comparable to http vs. ftp
> >>> (of course, it's a poor comparison, but I hope it illustrates at
> >>> least a bit what I mean).
> >>>
> >>> If NSH takes off (and it's a big "if" in my opinion), it's also well
> >>> possible we'll see more metadata types. The spec is pretty much open
> >>> to this. Obviously, the authors are aware of that and type 2 is optional.
> >>> As I guess will be type 3 and type 4 and whatever.
> >>>
> >>> It's pretty much inevitable that applications and deployments built
> >>> around MD type 1 won't support MD type 2. And vice versa. This is
> >>> regardless whether ovs supports MD type 2 or not. They're just a
> >>> different protocol.
> >>>
> >>> In my opinion, starting with MD type 1 is a good way to reduce the
> >>> initial scope. I see no problem with adding MD type 2 later.
> >>
> >> I understand what you are saying but I'm not sure that I agree that
> >> the two metadata types should be viewed as essentially independent
> >> protocols. I guess it's probably also pretty unlikely that additional
> >> metadata types will be created in the future.
> >>
> >> If you look at discussions in the IETF and other places, it seems
> >> like a frequent response to questions about MD type 1's design is
> >> that any limitations can be handled with type 2. So to me this looks
> >> like the two pieces are interrelated and the situation is quite
> >> similar to IPv4.
> >>
> >> In any case, I don't think this is a fundamental issue, just a matter
> >> of timing. Since the premise of the original question was that MD
> >> type
> >> 2 shouldn't be too much additional work and the series is currently
> >> dependent on Simon's patches, it seems like now might be a good time
> >> for the authors to look into implementing this.
> >
> >
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.