Thanks for the minutes, Jan! The time difference between Central Europe and Pacific Standard Time is 9 hours, so the next meeting will start at 8am PST.
Jarno > On Nov 30, 2016, at 2:52 PM, Jan Scheurich <jan.scheur...@ericsson.com> wrote: > > A small team is driving the implementation of NSH based on a number of new > features to be implemented in OVS: > Packet type-aware pipeline (PTAP, EXT-112) in OF 1.5 > Generic tunnel encap/decap actions (EXT-382) intended for OF 1.6 > “versatile” tunnel ports (aka L3 tunnels) > > The ongoing design work is captured in the following Google doc that is > accessible to the public for comments: > https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit?usp=sharing > > <https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit?usp=sharing> > > The basic principles of PTAP bridges and their interwork with “versatile” > tunnels (tunnels that can carry various payload types, L2 and L3) was > discussed in an earlier meeting. In this meeting (Nov 29) we discussed the > draft of EXT-382 with Ben Mack-Crane of ONF and clarified question about its > use for encap/decap of Ethernet and headers in the OF pipeline. > > The corresponding section in the document is already updated with the results > of the discussion. So please have look. There’s also a short summary of the > main results at the end of the mail. > > The next session scheduled for Wed Dec 7, 17-18:30h CET (9-10.30am PST) will > focus on how to apply the tools PTAP, versatile tunnels and EXT-382 for NSH. > > If you would like to join the meeting series or are interested in > contributing to the development, please drop me an email. > > BR, Jan > > > Summary: > Participants: Jan, Zoltan, Ben MC, Ben Pfaff, Jarno > EXT-382 is seen as a suitable OF mechanism to push/pop individual packet > headers at the front of a packet. Implementation in OVS should provide > valuable input to ongoing specification for OF 1.6. > P4 and generated control APIs may in the future replace OF and EXT-382, but > that is a more long-term option only and doesn’t solve the current problem. > We will focus on “simple” use cases for EXT-382: Ethernet and NSH headers. > The draft is generic enough to allow arbitrarily complex encap/decap > operations for entire tunnel stacks (e.g. GTP/UDP/IP/Ethernet) but that is > not needed right now. Also no implicit creation of logical ports through > encap/decap actions. > Encap(Ethernet) should set the Ethertype based on the encapsulated packet’s > type. This can be overridden by the controller with set_field(ethertype) > after encap if wanted. > Encap(Ethernet) of an Ethernet packet shall be supported (TEB) > Decap of an Ethernet packet should by default only remove the Ethernet > header. Present VLAN tags would remain (e.g. with packet type (ns=Ethertype, > type=0x8100)). A PTAP can continue to process such packets. > For convenience there should be an optional property to also decap any VAN > tags between Ethernet header and L3 payload. > Two distinct flow entries are required to match IPv4 packets in a PTAP bridge: > 1. packet_type=(0, 0), ethertype=0x800 (IPv4 in Ethernet) > 2. packet_type=(1, 0x800) IPv4 > To avoid duplication of all L3/L4 flow entries in a PTAP bridge, the > controller could normalize IPv4 packets to packet type (1, 0x800) before > sending them to L3/L4 tables by popping the Ethernet header. As this is > mainly a logical operation, this need not be expensive. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
