Hi,
I agree that we should go ahead with implementing support for MD2 while we are
doing NSH. There are planned use cases that will depend on MD2, like an SFF
load-sharing between SF instances based on an entropy TLV option.
But there are in fact a number of technical issues that need to be sorted out
before we can implement full MD2 support, and we need the advice of the OVS
maintainers here to be able to proceed:
1. The pending question whether to model NSH headers as packet header match
fields, metadata fields, or both applies in particular to the MD2 TLVs.
We have three main OpenFlow use cases for the MD2 TLVs:
a) Match on an MD2 TLV of an NSH packet
b) Set a MD2 TLV of an NSH packet
c) Pop an NSH header of MD2 format (saving selected TLVs in metadata)
d) Push an NSH header of MD2 format with selected TLVs and set their values
Use cases c) and d) would naturally fit the idea to re-use the TUN_METADATA[X]
fields introduced for Geneve also for NSH TLVs. The push_nsh action should take
the MD format as input parameter and in case of MD2 would push those TLVs for
which mappings have been defined (see question 2 below) and set their values
from the mapped TUN_METADATA[X] fields. I guess that is how the Geneve tunnel
ports works. Can you confirm that?
But for use cases a) and b) the same TUN_METADATA[X] fields would have to be
populated by the parser and used as packet header match fields. Technically
this might be implementable in OVS, but would it be acceptable?
Otherwise we'd have to define a second set of TLV_OPTION[X] match fields on the
OpenFlow protocol level, which could be subject to the same TLV mapping as
TUN_METADATA[X].
Internally, these fields could probably be stored in the same memory location
in the flow as TUN_METADATA[X]. There should be no collision because a mapped
NSH TLV can either be a packet header or metadata but not both. And even if NSH
would use Geneve tunnels as transport in the future, Geneve and NSH TLVs can
never be mapped to the same index.
In contrast to TUN_METADATA[X] fields, a mapped TLV_OPTION[X] may not be
present in a packet fulfilling that pre-requisite. The presence info must be
somehow be captured in the packet's flow.
2. The current Nicira extension messages for managing TLV option mappings
identify the TLV option to be mapped by {Class, Type and Length}. While such a
tuple is unique within a given protocol like Geneve, there is no guarantee that
the same triple cannot be defined for a TLV in another protocol. Thus, a
mapping for, say, NSH could collide with an independent mapping for Geneve.
To address this issue, the TLV option mapping commands could include an
additional 'protocol' identifier. But that would be a backward incompatible
change of an external interface. Would you accept that or is there a clean way
to solve this without such an impact on OpenFlow?
Thanks, Jan
> From: dev On Behalf Of Jesse Gross
> Sent: Wednesday, 20 July, 2016 18:44
>
> On Wed, Jul 20, 2016 at 5:06 PM, Paul Quinn (paulq) <pa...@cisco.com>
> wrote:
> >
> >> On Jul 14, 2016, at 11:39 AM, Jesse Gross <je...@kernel.org> wrote:
> >>
> >> On Wed, Jul 13, 2016 at 10:44 PM, Elzur, Uri <uri.el...@intel.com> wrote:
> >>> +1 on starting w MD Type = 1
> >>>
> >>> Not sure I understand the concern expressed with " implementations that
> don't implement TLVs will become deployed and then when there is a use for
> them it's no longer possible." - why will it not be possible to add MD Type=2
> later?
> >>
> >> As I said, it's a classic problem with IP options. Classic enough
> >> that people frequently content that TLVs are not usable at all
> >> because they don't get implemented which then becomes a self fulfilling
> prophesy.
> >>
> >
> > Jesse, the issue with IPv4 options has nothing do the actual option(s) but
> rather the "cost" associated with the handling, particularly in hardware, of
> variable length packets.
>
> This is a cost vs. benefit tradeoff. I'm fairly certain that had options been
> an
> integral part of handling IP from the start, router vendors would have decided
> to handle them rather than not processing IP. However, since there was little
> benefit at that time, it was generally decided that it wasn't worth it and
> certainly nobody is going to bother doing it today because everybody knows
> that options are unusable since no one implements them.
>
> I think in general it is a pretty well known property that extensibility is a
> use it
> or lose it type of thing. TCP has options as well that directly resemble IP
> and
> they are available and implemented today because they are necessary for
> common functionality. I am aware that TCP is primarily implemented at the
> software layer and not hardware but as I think we can see from the discussion
> in this thread, trying to limit implementations to the minimum functionality
> that seems necessary at the time is not only applicable to silicon.
>
> >> I think I've been extremely clear on this matter. I also think that
> >> I've been extremely consistent - I think I've said the same thing on
> >> every review of this patch series, so it should not exactly be a
> >> surprise. However, the bottom line is I want to see a complete
> >> implementation of the protocol and not a half measure that will catch
> >> people by surprise or limit future usage. That seems 100% reasonable
> >> to me.
> >
> > The adopted NSH draft clearly states that type-1 support in mandatory, and
> that type-2 support is optional. As such the OVS patches are compliant.
> Having
> said that, the current code also supports skipping the type-2 based on the
> length of NSH conveyed in the first word of the header. This, I believe,
> constitutes support: type-2 NSH packets, if used, are supported: the type-2
> info
> is skipped and OVS functions as expected.
> >
> > It appears that your definition of support differs from that, can you
> > expand on
> it please?
>
> As I have said, I would like to see real support for MD type 2 so that it is
> useable in the future. I don't think that this patch set fulfills that
> criteria.
>
> At this point, I have not heard a technical argument as to why MD type
> 2 support shouldn't be implemented now. I have given my reason why it is
> important to do it and the only objection seems to be that the authors don't
> wish to take the time. Considering that the discussion of how to do it has
> continued in another thread (thank you Jan for helping to move things
> forward),
> it seems more productive to focus on that rather that continue this debate.
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
