Re: Discussed introduction of a new OXM class for the proposed GEN_TLV fields
- No problem to reserve an OXM class even before those fields are standardized We have allocated OXM class 0x8005 for TLV value mapping (experimental for now) in the ONF Registry <https://rs.opennetworking.org/wiki/display/PUBLIC/ONF+Registry>. Regards, Ben On Thu, Dec 22, 2016 at 4:51 AM, Jan Scheurich <[email protected]> wrote: > Thanks for the good meeting. Here are my notes: > > Date: 2016-12-21, 17-18:30 CET > Participants: Jarno R, Ben P, Ben M-C, Jiri B, Simon H, Zoltan B, Jan S > > Summary: > > - Discussed making PTAP, EXT-382 and NSH available as extensions to OF > 1.3. > > > - No big deal for the match fields and the encap/decap actions > - Potential problem could be the missing packet_type information in OF > 1.3 Packet In, Packet Out and Table Features (Note: Closer inspection of OF > 1.5.1 spec reveals that OXM packet_type is part of struct ofp_match in > Packet In and Packet Out. It should be OK for an OF 1.3 controller extended > with PTAP support) > - Is it simpler for the controllers to upgrade to OF 1.5? > - Deferred the decision > > > - Agreed to use the (to be assigned) OXM field code points for > packet_type and NSH in OVS for all OF versions > - Agreed to allow all NS=1 packet types received from/sent to a tunnel > port that uses the Ethertype name space in its protocol field (like GRE). > Other versatile tunnel ports (like VXLAN-GPE) which have their own code > points require explicit mapping and must drop packets for which no such > mapping exists. > - Discussed introduction of a new OXM class for the proposed GEN_TLV > fields > > > - No problem to reserve an OXM class even before those fields are > standardized > - For standardization we also need to specify a dynamic binding > mechanism between protocol TLVs and GEN_TLV fields. We can submit the > mechanism to be developed in OVS for standardization when its stable. > > > - Walk-through of division into work packages: > > > - Some follow up needed for the L3 packet support kernel datapath > patches > - Rest OK > - Technical discussion around GEN_TLV and use for NSH MD2 in > conjunction with encap(NSH) to be continued in the Google doc. > > > - Time line: > > > - The entire work should be targeting OVS 2.8 with feature freeze > around July > > > - OVS 2.7 is having feature freeze already in early January > > > - Work packages can be upstreamed individually. NSH MD1 support > doesn’t have to wait for MD2 > > > - Basically agreed to the work split proposed in the document: > > > - RedHat is taking the patches for L3 tunnel configuration (including > use of RTNETLINK for config) > - Ericsson take the infrastructure components (L3-tunnels, PTAP, Basic > EXT-382) > - Jarno (VMware) will handle the GEN_TLV infrastructure > - Confirm with Yi Yang (Intel): Can they take VXLAN-GPE and the > NSH-specific WPs? Or do they need help? > > > - Way of working > > > - Continue the meeting series for coordination of effort > - Can use a feature integration branch to ease the joint development > and test > - Review of patches mainly through the ovs-dev mailing list > - Use tools like git citool to break up larger patches into a series > of smaller patches for review > > > > > -----Original Appointment----- > *From:* Jan Scheurich > *Sent:* Sunday, 18 December, 2016 15:34 > *To:* Jan Scheurich; Zoltán Balogh; Yang, Yi Y ([email protected]); > Jiri Benc ([email protected]); Pravin Shelar; Simon Horman ( > [email protected]); [email protected]; [email protected]; Ben Pfaff; ' > [email protected]'; [email protected] > *Subject:* Sync on PTAP, EXT-382 and NSH > *When:* Wednesday, 21 December, 2016 17:00-18:30 (UTC+01:00) Amsterdam, > Berlin, Bern, Rome, Stockholm, Vienna. > *Where:* Skype Meeting > > > Moved to Wednesday same time to accommodate Jiri. > Hope this is still OK for the others. > > > Hello all, > > I would like to call for a final sync meeting before the Christmas break. > > Now that we have gone through the main aspects of the design, I would like > to focus on how to divide the entire function into manageable pieces, > discuss the potential work split, an integration anatomy and a rough time > plane for upstreaming. I will try to prepare input in our Google doc for > this. > > > *https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit* > <https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit> > > If there are questions left regarding the design, please bring them up as > well. You can also comment on the document at any time. > > Regards, Jan > > ............................................................ > ............................................................ > ................. > à *Join Skype Meeting* <https://meet.ericsson.com/jan.scheurich/HJ2NTF23> > > This is an online meeting for Skype for Business, the professional > meetings and communications app formerly known as Lync. > Join by phone > > *+492115343925* <+492115343925,70849799%23> (Germany) English > (United States) > *89925* <+89925,70849799%23> (Germany) English (United States) > > *Find a local number* <https://dialin.ericsson.com?id=70849799> > > Conference ID: 70849799 > *Forgot your dial-in PIN?* <https://dialin.ericsson.com> |*Help* > <http://o15.officeredir.microsoft.com/r/rlidLync15?clid=1033&p1=5&p2=2009> > > > > To join a Lync / Skype for Business meeting from an Ericsson standard > video room, add 77 before the Conference ID (e.g. 771234567 where 1234567 > is the conference ID). To join from a video room outside of Ericsson add > one of the domains after 77 and Conference ID (e.g. 771234567@ > xxxx.ericsson.net, where xxxx=emea/apac/amcs). For assistance contact > the IT Service Desk. > [!OC([1033])!] > ............................................................ > ............................................................ > ................. > > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
