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

Brady Allen Johnson brady.allen.johnson at ericsson.com
Wed Jul 13 17:06:39 UTC 2016


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 
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.




More information about the dev mailing list