Minutes for NVO3 at interim-2015-nvo3-7
|Meeting Minutes||Network Virtualization Overlays (nvo3) WG|
|Title||Minutes for NVO3 at interim-2015-nvo3-7|
|Other versions||plain text|
IETF NVO3 WG Virtual Interim Meeting Minutes 2015-03-13 11:00-12:30 EST (15:00-16:30 GMT) Chairs: Benson Schliesser, Matthew Bocci Secretary: Sam Aldrin Note takers: Ignas, Sam Topic: Data Plane (This meeting will be a replacement of the virtual interim meeting originally scheduled for 2015-02-27.) 1. Meeting Introduction and Agenda Bashing (10 min) Chairs Benson: starting. Waiting for Eric Nordmark to get audio. This is the same meeting as planned two weeks ago, webex problems last time prevented from running it. Benson going through agenda. •Everyone please sign into Bluesheet •Today’s agenda is Data plane related topics. •Making up for the last virtual meeting due to Webex issue •This is an IETF meeting please read NoteWell •We are going to hear from Erik about DP efforts •Later we are going to hear from three encap authors. Uri: do we plan to rerun this same discussion in two weeks? Benson: we have a physical meeting in two weeks. I would like to see discussion on mailing list starting on the data plane, and during the IETF we can continue with that. 2. Update from the Routing Area Encap Considerations Design Team (20 min) https://tools.ietf.org/html/draft-rtg-dt-encap-01 Erik Nordmark <email@example.com> Eric Nordmark: overview of DT and some history since Hawaii. - 8 of us, part of DT, discussed about DP requirements and encaps proposed - What have we done in the past and what we can learn from it. - The observation is that there may be multiple encapsulations happening at the same time. The observation is that the - encaps take care of the issues that are important for them only. Not necessary independent of the specifics of each encap. - As an example, what about congestion control? - We try to look from the perspective of the impact to the packet format, and not only control plane. - Did not attempt to bring in all what was done for MPLS and L2TP. More focus on IP and UDP. - Entropy label architecturally appeared to fit well even with no MPLS. - This is not an attempt to define a new encap that will rule them all. - A list of common aspects - also covered in charter (slide of 12 steps). - This will also be covered in rtgwg in Dallas. David Black: as TSVWG chair: yes, it will be put on agenda for Dallas meeting. Erik: - what common data and behavior encapsulation should have? VNI ID is the minimum. If OAM is carried, do we carry it as is, or allow modifications? - SFC requires much more modifications. - BIER needs to modify the bitmap as it is forwarded to turn off bits to indicate that a copy has been sent. - NVO3 might be the easiest in the space of modifications. - What happens when you use multiple of these encaps? What should be the common set of functionality? - The underlying transport also needs some indication that what is carried is an encap too. - The question for broader IETF is whether it makes sense to pick something common from transport perspective. Or should one group use Ethernet types, and another use something else? Security> Three things - anti-spoofing, can you leverage IPSec, and privacy considerations. - Anti-spoofing - there is a difference between ULP traffic over say SSL, and injecting traffic into the overlay. - Might need to do some hash of header fields, but needs to exclude modifiable fields. NVO3 needs to understand what kind of threats there may be. Header protection> running over IPv6 and no header checksum. Do we care about the headers in the actual encapsulation header not covered by checksum? Should be at least optional to protect those fields to avoid eg: mis-delivery in case of error in VNI ID field. Extensibility> new functionality not seen/needed at the moment and how far do we go before it breaks? What would actually get implemented in a practical way? HW friendly> protocol design may impact how it will get deployed later, component design especially. Example of checksum: if NIC has offload capabilities, it can do full packet checksum whereas intermediate node cannot do that easily. - Hardware scales best in parallel. If the field can be discovered without much sequential processing that would be benefitial. TLVs don't easily fit this scheme. Middle-boxes> new middle-boxes may appear that can provide additional processing of particular encapsulation protocol. NVO3 has touched this briefly with NVO3/MPLS interworking. NVO3 enabled firewall as an example that looks at VNI ids. - There is a line of thinking that middle-boxes are evil, same as NATs are. Open questions> what is in-order delivery? Do we need to define that over encap? Timestamps and congestion control indication too. Next steps> present in rtgwg and tsvwg in Dallas. Any questions? Benson: few minutes for questions? Lucy Yong: would it be good to group the issues for different encaps? Tunneling? Some may not apply for all encapsulations. Eric: fair point , we did not yet discuss that. High order message is that we should think about all of these issues. Ilango Ganga: you have listed many encap protocols. Do you plan to make recommendations to each of the relevant working groups? What would be next steps? Eric: most of these issues are for the broader area than a specific WG. Example of MPLS over UDP. Some aspects could be seen as recommendations. Others are broader discussion items. David Black: a comment on UDP aspects in transport. Transport area is in process of revising RFC5xxx on UDP transport (?). That might be a good place to consolidate the requirements. Benson: wrapping up to move to next topic. 3. GENEVE (10 min) https://tools.ietf.org/html/draft-gross-geneve-02 Jon Hudson <firstname.lastname@example.org> Jon Hudson: Overview of why we do Geneve. Looking for room for more functionality in format. Use existing underlay IP fabrics. - Header: no changes since last revision. - No significant changes to draft since -02 version. - Implementations: Intel provides support for their NIC now. Linux and OVS support it now. Jesse Gross: this slide was done for Honolulu, there are some more announcements coming. Jon: looking for adoption and increasing support in the community. Questions? Benson: as an individual: last slide showed different implementations. Is there any cross vendor capability overlap in the existing implementations? Jesse: different implementations do not need to expose the capabilities? Sam Aldrin: have you considered the issues that Eric has presented previously? Jesse: Geneve was designed before the DT document came out, but we were aware of many of those issues already. Benson: moving to next one. Lucy Yong: do current implementations support optional headers? Jesse: yes. Uri: is there any work on what are the requirements for guidelines for the encapsulations? Benson: that is a good question that we need to discuss on mailing list. There are a number of considerations that we would want to discuss separately. We do not necessary want to have a 'pick one' approach. Uri: Interoperability is important in this case - given several possible options that get built and deployed. Benson: if we are not building interoperable solutions then what is the point of IETF. Maybe pick one protocol s must implement and others may be optional for specific use cases. Would like to see this being discussed on mailing list. 4. VXLAN-GPE (10 min) https://tools.ietf.org/html/draft-quinn-vxlan-gpe-04 Larry Kreeger <email@example.com> Larry Kreeger: - generic protocol extensions for VXLAN. - What we want to achieve - we are extending VXLAN. Allow to carry IPv4/v6, shim headers. OAM is also important. - Header has a P - next protocol indicator. Examples: - Extensibility example with NSH. - OAM uses another flag bit, O Future enhancements> - one way is the reserved bits. - In order to avoid getting another reserved UDP port, version could be used. - udp/4790 was allocated for VXLAN-GPE. - Many changes since previous draft version - Several closed and open source implementations are on the way, both SW and HW. Benson: one minute for questions: Sam Aldrin: you mentioned in OAM slide - the packet should not leak to the tenant system. How do you ensure in case it does not support OAM bit? Larry: it must support it. Sam: is there any other way that could leak to tenant system? Larry: you need to follow the protocol. Erik Nordmark: what was the reason for not picking the first two bits for version field? Larry: VXLAN header is aligned with LISp header, and they are used there too. Paul Quinn: LISP group could propose de deprecate the bits. Lucy: OAM packet is standalone (?) Larry: OAM packet is a specific type. It requires to recognize OAM bit and then send to OAM component. If there is no OAM component then drop it. Benson: moving to next presentation. 5. GUE (10 min) http://tools.ietf.org/html/draft-herbert-gue-03 Tom Herbert <firstname.lastname@example.org> Tom Herbert: Overview. Header format. - GUE is derived from GRE. - Extensibility via extension header. - VNI id, security, checksum fields defined now. - Many other options discussed and possibly could be implemented. - A class of extensions that do not seem interesting - that includes pseudo-wires, routing header. service related aspects. - Security field - it needs to protect VNI id and GUE header to avoid corruption and spoofing. - IPSec interaction - GUE header is outside of IPSec ESP. Requests - WG adoption. Benson: questions? Larry: is this already adopted in TSVWG? Tom: no, not yet. TSVWG might be more interested in transport, while NVO in tunneling. David Black: I would prefer data plane stuff to be sorted in NVO3. Transport aspects - yes, in TSVWG. 6. Open Discussion (30 min) Benson: any broader questions related to data plane topic: Ilango: there are 3 different encap protocols all asking for WG adoption. How WG will proceed here? Benson: we have some flexibility allowed by the charter. One thing I would like to avoid is beauty contest here. Rather would like to see WG adopting multiple data plane encaps and let the market decide. It would be helpful if we had an ability to name one as a must and others as optional. Would also like to talk on the list about comparisons on the mailing list. Immediate next step would be to start adoption discussion on the mailing list. Ilango: adopting one as mandatory and others as optional is not necessary solving the interoperability issue. Benson: yes, good point, please discuss on the list. Erik Nordmark: was there any discussion on rechartering in case when group cannot pick one and treat all as experimental? Benson: we might have multiple experimental, yes. Erik: different choices may be implemented, and then we have no interoperability. Benson: if we can pick one that would be ideal. Another option is to standardize multiple. Right now I am thinking that we adopt all. Lucy Yong: If we compare then we should align it with the DT recommendations. Benson: my tentative plan is to send email as a call for adoption and that discussion should compare design considerations. Anoop Ghanwani: the danger with multiple encaps is similar to having multiple ways for extensions. That is difficult for hardware. Benson: yes, agree. Benson: does the two step process of adopting all and revisiting later is a bad idea? Ilango: my preference is to better agree on one. Jesse Gross: it is some contention between what people prefer and what is realistic. David Black: [...] Erik Nordmark: I suspect that all of the encaps are at different levels of implementation. To what extent people are willing to chage those things. Do not know how will that play out because it is already implemented. Ilango Ganga: maybe we could come up with a hybrid, another protocol, but that is yet another protocol. Eric: from an industry perspective it gets more flexibility. Benson: I do not have an answer and was leaning to multiple options and let market decide. Benson: before Dallas hopefully we have a good discussion on the list. Benson: thank you for coming. Matthew and I will talk and followup on the mailing list.