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 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
