At the end of my initial long response (http://openvswitch.org/pipermail/dev/2016-July/075115.html) I had included an example for how the OF pipeline could be programmed if the NSH fields are treated as packet header match fields and not metadata fields. As you say, the interesting case is how to match NSH header fields after having popped the NSH header.
The clean OVS way (which is already supported today) is to save the interesting fields into NXM_REGISTER fields before popping the NSH header. Here's the example again: # SFF flow entry for terminating an RSP and forwarding the decapsulated packet # saving the NSH C2 metadata in register to be used as e.g. VRF tag in IP forwarding decision table=4, priority=100,eth_type=0x894f,nsi=252,nsp=4 actions=move:nsh_c2[]->NXM_NX_REG0[],pop_nsh,goto_table:10 # Exit IP forwarding table (e.g. in Netvirt complex) table=10, priority=100, ip,nw_dst=10.0.36.4,NXM_NX_REG0=0x64, actions=push_eth,set_field:22:33:44:55:66:77->eth_src,set_field:11:22:33:44:55:66->eth_dst,output:4 This may appear a bit clumsy from controller perspective, but it has the advantage that the datapath does not have to save all NSH headers in metadata fields at pop_mpls just in case the anybody needs to match on them later, which is not the normal case for most of the fields. I understand that your current patches do not distinguish packet header and metadata usage of the NSH fields. That looks very convenient from controller perspective but it is conceptually broken. Packet header match fields are typically bound to a pre-requisite in OF. In the NSH case the pre-requisite should be eth_type=0x894f. It must not be allowed to match on NSH fields unless you also match on eth_type=0x894f. Metadata fields, on the other hand, would always be present with the packet. If they have not been set by a pop_nsh action or a set_field() action, they will simply be zero. There is no way a flow entry can distinguish between a non-initialized metadata field and a true value of zero. The eth_type of the packet is no longer 0x894f after pop_nsh but typically 0x800 (IPv4). The controller must rely on implicit knowledge of the history of the packet in the pipeline. As we definitely must have NSH packet header fields and we can solve access to selected headers after pop_nsh as shown above, my preference would be to go for packet header match fields. Unless the OVS community has an acceptable solution for the problem using the same fields in both ways. BR, Jan N.B.: There is one potential future use case I can see which may complicate things. I'm thinking about adding or removing TLV fields to an NSH header in MD2 format. This cannot be done in-place. One way to do this would be to pop the NSH header into metadata fields, add or delete some MD2 TLV metadata (how?), and finally push the NSH header again with the changed set of MD2 TLVs. This might become very cumbersome without implicit storage of NSH headers into metadata fields at pop_mpls and implicit loading from metadata at push_nsh. But perhaps that use case will never be needed > -----Original Message----- > From: Yang, Yi Y [mailto:yi.y.y...@intel.com] > Sent: Wednesday, 20 July, 2016 04:30 > To: Jan Scheurich; Li, Johnson; dev@openvswitch.org > Cc: Manuel Buil; László Sürü > Subject: RE: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header > Support > > Jan, although NSH isn't tunnel, but we still need to do some matches after > pop_nsh, this is similar to vxlan tunnel, we still can match vxlan tunnel > metadata after the patch is de-capsulated, such as TUN_ID and TUN_DST. So > my point is maybe we need both header fields and metadata fields. > > -----Original Message----- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jan > Scheurich > Sent: Friday, July 15, 2016 6:27 PM > To: Jan Scheurich <jan.scheur...@ericsson.com>; Li, Johnson > <johnson...@intel.com>; dev@openvswitch.org > Cc: Manuel Buil <manuel.b...@ericsson.com>; László Sürü > <laszlo.s...@ericsson.com> > Subject: Re: [ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header > Support > > It would be great if we could get guidance by the OVS committers on below > question whether to model NSH fields as packet header match fields or as > metada fields or both. > > Right now patch v2 mixes those and uses the same set of NXM fields both > when matching packet headers of an NSH packet and as metadata fields > after pop_nsh or before push_nsh. > > Is that acceptable from an OpenFlow and OVS perspective? > > > Access to NSH header fields in the OF pipeline > > ----------------------------------------------- > > > > OpenFlow has two ways for this: packet header and metadata match fields. > > Packet header match fields are populated when parsing a packet with > > NSH ethertype and are only valid and accessible while the NSH header > > is in place (i.e. before pop_nsh or after push_nsh). Metadata fields, > > in contrast, would be populated by a pop_nsh action to save the > > content of the popped NSH header and would be used in a push_nsh > > action to populate the pushed header fields in the packet. > > > > I doubt that the OVS community will accept a single set of NXM fields > > that can be used both as packet header and metadata fields > > interchangingly. That is really a fundamental question that we should > > agree up front. It will very much determine the OF interface that ODL SFC > needs to adapt to. > > > > If that is not acceptable, we should focus on one of these approaches, > > otherwise we would have to create two complete sets of NXM match > > fields for NSH. > > > > The benefit of NSH packet header match fields is that an SFF can match > > on e.g. NSP and NSI without having to pop the NSH header and push > > again for transmission to an SF or SFF. This will be important for SFF > > performance as this is the most frequent traffic case > > > > A benefit of NSH metadata fields might be that all NSH header data is > > implicitly kept with the packet after pop so that SFC controller > > developers don’t have to manually take care of copying NSH headers > > into NXM registers to use them after pop_nsh. Not sure how frequently > > this will actually be needed. > > > > My preference would be to go for NSH packet header match fields as > > these are more general and optimal for the most frequent use case. > > > > We have some tricky aspects to consider for NSH format MD2 with variable > TLVs. > > Assuming we re-use the TLV mapping mechanism to bind > TUN_METADATA<IDX> fields to NSH MD2 TLVs, I believe it should be > technically feasible to parse NSH TLVs into the TUN_METADATA fields and > match on them. Also set_field or move actions should be OK as each > individual TLVs has a fixed length defined at mapping time, right? > > But for a push_nsh action the TUN_METADATA fields for NSH TLVs must be > populated with data before the push_nsh action so that the datapath can > reserve the correct space for the entire NSH MD2 header. So these > TUN_METADATA fields would definitely be used both as packet header and > metadata fields. > > How does the current implementation for Geneve decide whether or not to > include a TLV option with a mapping during push? Based on the value of the > TUN_METADATA field or always include all TLV options with a mapping? > > Thanks, Jan > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
