Hi, Jesse
For NSH implementation in OVS, we have two more topics want to discuss with you:
Except for NSH encapsulation format of “VxLAN GPE + NSH”, we also want to
support another encapsulation mode defined in NSH SPEC: “Ethernet + NSH”, which
is to add only one L2 header out of NSH header. We have two proposals to
support it.
1) We use an integer action code for action “push_nsh” to decide whether push
the Ethernet header or not:
a) “push_nsh:1” is used for pushing Ethernet header + NSH header (Ethernet
+ NSH + original packet).
b) “push_nsh:0” is used for pushing only NSH header (NSH + original packet).
Then the sample for Ethernet+NSH encapsulation is as following:
ovs-ofctl add-flow br-int “priority=200, in_port=1, actions=push_nsh:1,
set_field:221->nsp, set_field:3->nsi, set_field:111->nshc1,
set_field:00:11:22:33:44:55->encap_eth_dst, output:${VXLAN_PORT}"
2)Push NSH header action and push Ethernet action are decoupled. The action
“push_nsh“ is used for pushing NSH header and the action “push_eth” is used for
push Ethernet header. Then the encapsulation sample can be implemented as
following:
ovs-ofctl add-flow br-int “priority=200, in_port=1, actions=push_nsh,
set_field:221->nsp, set_field:3->nsi, set_field:111->nshc1, push_eth,
set_field:00:11:22:33:44:55->encap_eth_dst, output:${VXLAN_PORT}"
We prefer to take option 2. What do you think about it?
> > So for NSH header, we need to add the TLV support. For the fixed
> > fields of NSH header like NSI, NSP, we’d like to add specific
> > meta-flow fields for them, for example:
> >
> > MFF_NSP Type: NXM_NX_NSP (105), Length:4 bytes
> >
> > MFF_NSI Type: NXM_NX_NSI (106), Length:1 bytes
> >
> > But for the variable length context headers of NSH, we’d like to use
> > fields like “tun_metadata” (tnl->metadata) to support it. We also have two
> options:
> >
> > 1) Reuse the “tun_metadata” for NSH variable context header, it’s
> > similar to current Geneve TLV support. But it’s a little wield because
> > the NSH header is already an independent protocol layer but not belong
> > to the tunnel layer.
> >
> > 2) Define a new “nsh_metadata” fields for NSH variable context header.
> >
> > Which one do you prefer? Please tell us for you inputs on our
> > modification plan.
>
> I would definitely like to reuse the same set of fields as were used for
> Geneve since there are a large number of them and have a second set
> seems wasteful. I don't think there is anything that inherently ties them to
> tunneling, so if you have a different name that is more generic we can still
> change them as long as it is before OVS 2.5 is released.
>
> By the way, there are several OpenFlow commands that were added support
> mapping TLVs to fields. These are currently specific to Geneve because they
> validate some protocol specific aspects. NSH actually uses the same TLV
> format as Geneve, so in theory they could be shared (and it would be nice to
> avoid duplicating these). The main thing that concerns me about this is the
> possibility that the protocols will diverge in the future or some other
> protocol
> that does not have the same format will want to use the same thing. In any
> case, it would be nice to think about how this could be made useable by
> everybody before OVS 2.5.
For NSH TLV implementation, We agree that we should reuse the same set of
fields as were used for Geneve. As NSH in MD-Type 2 use same TLV format as
Geneve, they can share the pool of 64 NXMs which can be mapped on Geneve TLVs
or NSH TLVs. It may be better to make the command name more generic. For
example, we can rename “add-geneve-map” to “add-tlv-map”.
An example in our initial design for NSH MD-type 2 support:
ovs-ofctl add-tlv-map br0 {class=0xffff,type=0,len=4}->tun_metadata0
ovs-ofctl add-flow br0 in_port=LOCAL, actions=push_nsh, set_field:221->nsp,
set_field:3->nsi, set_field:2->nsh_md_type,set_field:111->tun_metadata0, 1
What do you think about this proposal for NSH TLV support?
-Mengke
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
