> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata > >> is not in tun_metadata as well? > > > > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is > > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a > > lot of rework on tun_metadata to make it shared between GENEVE and NSH, > > I don't think this can happen in near term. So tun_metadata isn't option > > for this now. > > Sorry, I couldn't follow you. Why can't you store the context headers in > tun_metadata exactly? >
I think we mixing things. Let me try to clarify: 1. NSH context metadata has end-to-end significance for the SFP. They must be part of the NSH header and cannot be transported as tunnel metadata, because transport tunnels (e.g. Geneve) only connect pairs of SFFs in the path. So we need OVS to be able to match on and set NSH context header fields, also for MD2 TLVs in the future. 2. OVS today has support for matching on TLV tunnel metadata after termination of a Geneve tunnel. This infrastructure is only usable for OVS tunnel ports (like Geneve) but not for matching on TLV headers of the NSH protocol, which is not modelled as an OVS tunnel port but handled in the OpenFlow pipeline (with generic encp/decap actions to enter/terminate an NSH SFP). This was a strategic decision by the OVS community two years ago. There is no way we can re-use the existing TLV tunnel metadata infrastructure in OVS for matching and setting NSH MD2 TLV headers. We will need to introduce a new (perhaps similar) scheme for modelling generic TLV match registers in OVS that are assigned to protocol TLVs by the controller. This is FFS. BR, Jan
