On Thu, Jul 21, 2016 at 3:40 PM, Jan Scheurich
<jan.scheur...@ericsson.com> wrote:
> 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?
With Geneve, the current implementation doesn't automatically add all
TLVs that have a mapping. It will only add the options for which a
value has actually been assigned during the flow translation, for
example, using set_field. When a value is assigned to a field during
flow setup, a bit is also set in a mask that tracks which options
should be emitted. This allows different flows to use different sets
of options.
There is also an analogue to this on receive: matching on a metadata
field requires that the field be present in the original packet.
Effectively this means that the metadata fields are not initialized to
zero regardless of their presence. If you only wish match on the
presence of a field, this can be done by including the match with an
all wildcarded value. If you don't care whether it is present, then
simply don't include it in the flow specification, even if it is
defined in the mapping table.
> 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.
I guess having both map to the same set of fields doesn't necessarily
bother me that much. If they are all being stored internally in the
same place in the flow (which I think is necessary - having a second
set of option data in the flow key seems wasteful and unlikely to be
needed in practice) then it seems like it mostly comes down to naming.
I suppose there isn't that much cost to having an extra set of
OpenFlow field names but it seems cleaner not to given the number of
fields that we are talking about.
In any case, there will clearly be some limit on the amount of
metadata when nesting NSH in Geneve. As long as we do something
reasonably sane in this situation, I don't think it will be a big
issue.
In terms of tracking presence of options, does my comment above answer
your question?
> 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?
There is some reserved space in the OpenFlow mapping actions. One way
to handle this would be to allocate a protocol type out of that space
and Geneve could be assigned type 0 (which is what existing clients
will send for reserved space) and NSH assigned type 1. That should
allow this behavior without breaking backwards compatibility of the
existing interface.
I'm not sure if this is really necessary though, given that we are
tracking which options are used. Another possibility would be to use
the length field as part of the lookup when converting the raw packet
data to OpenFlow fields during upcalls (currently we only use class
and type, I suppose it is possible for the same class/type to be
defined with a different length in Geneve and NSH). Since the lookup
would use the entire tuple, it wouldn't really matter which protocol
it is supposed to be part of - there would be no reason to create a
duplicate mapping for both Geneve and NSH since it could be used
interchangeably with either. If a controller needed to distinguish
between the two protocols, then it could use the input port or some
other indication.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
