> > As discussed please adjust the netlink uAPI for NSH as follows: > > > > OVS_KEY_ATTR_NSH > > -- OVS_NSH_KEY_ATTR_BASE mandatory > > -- OVS_NSH_KEY_ATTR_MD1 conditional: if mdtype=MD1 > > > > OVS_ACTION_ATTR_PUSH_NSH > > -- OVS_NSH_KEY_ATTR_BASE mandatory > > -- OVS_NSH_PUSH_ATTR_CONTEXT conditional: currently if MD1 or > > MD2 with TLV encap properties > > > > OVS_ACTION_ATTR_POP_NSH no data > > > > Remove OVS_NSH_KEY_ATTR_MD2 because the MD2 context headers > will not > > be modelled as dedicated key fields but mapped to some generic TLV > fields, > > similar to but independent from the current tunnel metadata TLV > registers. > > > > Using the name OVS_NSH_KEY_ATTR_MD2 for the opaque context data > in > > PUSH_NSH would be misleading as the variable length byte array can > carry > > any type of metadata format: MD1, MD2, or any future MD type. For > that > > reason I prefer the generic name OVS_NSH_PUSH_ATTR_CONTEXT. > > Then why even have ATTR_MD1? Sounds a single attribute is enough to > support all cases.
OVS_NSH_KEY_ATTR_MD1 represents a struct containing the four fixed length context headers defined in MD1. These are match fields in OVS and must be represented explicitly in OVS_KEY_ATTR_NSH. But their presence is conditional on MD type 1, that's why Jiri rightly insisted on having it split from OVS_NSH_KEY_ATTR_BASE. In OVS_ACTION_ATTR_PUSH_NSH we again have the same mandatory header part represented by OVS_NSH_KEY_ATTR_BASE, this time followed by an optional variable length opaque container for up to 248 octets of context data (the format is of no concern for the push_nsh action). The content of the ATTR_CONTEXT, if any, is compiled by ofproto when the action is sent. BR, Jan _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev