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

[Jan Scheurich]

I hate to be pestering but I believe the answer to the question below will have significant impact on the design of the NSH patch as well as the way SDN controllers can use NSH. So could the OVS maintainers please have a look and provide feedback?

Thanks a lot, Jan

> -----Original Message-----
> From: Jan Scheurich
> Sent: Friday, 15 July, 2016 12:27
> 
> 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