IETF 96 - NVo3 Meeting Agenda Wednesday 20th July-2016, 1400 - 1530 CEST. (90 min) WG Chairs - Matthew Bocci, Sam Aldrin Note Taker: Ignaz Bandanas Jabber Scribe: Carlos Pignataro Potsdam I conference room Afternoon Session I Meeting Minutes: =============== Note well applies. 1.1 - WG Chairs - Welcome, Agenda Bashing, Status Update (15 min) Agenda. Personnel changes - Sam is a co-chair. OAM topics will cover both OOAM and NVO3 OAM specifics. Discussion on use cases document. Alia Atlas: Use cases documents can be helpful at the beginning of the WG, the question is whether they are useful several years later. If there is an enthusiastic agreement in WG to progress that - it may be helpful to publish it. Would suggest to shape use cases to the applicability - here is a use case and how it maps to solution components. Lucy Young: Agree that this document could have been completed long time ago. Very little progress over the years. We continue to push back this work, this draft created the scope, maybe it would indeed be better to move to applicability document. Erik Nordmark: There are parts of content of the use cases document in other documents, it might have already served its purpose. 1.2 - IEEE802.1Qcn update: VDP extension to support NVO3 (10 min) https://datatracker.ietf.org/doc/draft-ietf-nvo3-hpvr2nve-cp-req Presenter: Pat Thaler [presentation] The current draft will be liaised with IEEE 802 next week. There is no YANG model - VDP was done before YANG time. May need to develop YANG model, otherwise will end up extending the MIB. Sam Aldrin: Will the YANG model be within IEEE, or IETF draft? Pat: Possibly within IETF, especially if we get someone to draft it here. [discussion] No questions or comments. 1.3 - Identifier Locator Addressing (10 min) https://datatracker.ietf.org/doc/draft-herbert-nvo3-ila/ Presenter: Tom Herbert [presentation] ILA overview, use cases. ILA being used in deployments at Facebook for task addressing. [Pierre Pfister presenting VPP hackathon results] Implemented from scratch during the hackathon. Verified interoperability with Linux implementation. ILA specification seems to be relatively clear, some more clarification details would help though. [discussion] Erik Nordmark: A comment on 5G BOF - it was a side meeting, not a BOF. Tom: I have worked a bit with Linda Dunbar on hyperscale addressing. David Mozes/Mellanox: Can you clarify what is the issue with the checksum? Pierre Pfister: there is a need to indicate whether the translation has set the checksum to zero (?) Behcet Sarikaya: 5gangip was a lunch meeting, not a BoF. There is a mailing list for it. Behcet: I have some concerns in a way that you change ILA. Behcet: Not certain too what do you mean by the identifier-locator BOF. 1.4 - Overlay OAM Design team update (10min) Presenter: Erik Nordmark [presentation] [discussion] Sam Aldrin: Some of your proposals are in the context of overlay OAM, but others apply to non-overlay environments too. What is the scope? Erik: Overlay defines new ways of doing OAM. But if we do that, could we reuse those new OAM mechanisms not for overlay too? It depends on the interworking of overlay and underlay, there is an overlay protocol that has a concept of VNI and we need to discover it. Sam: Are you proposing any architecture guidelines on what if support is not available on platforms or networks? Greg Mirsky: What separates what is in scope and what is not - for overlay OAM we are marking OAM as an explicit payload type, and that will ensure that OAM payload is inband with data. Greg: Query operations may be out of band and still get the valid data. But for other operations it is essential that OAM is inband. Greg: In the gap analysis document there is a section that mentions this specifically. OAM needs to be recognized as a distinct payload type. Marking methods need to be used that are not considered for the forwarding of the packets. Tom Herbert: OAM ping format - is that with the format header? Does it have payload type? Why do we need 16 bit version number? Carlos Pignataro/Cisco: My perspective is what Greg was talking about is about encapsulation specific, but not overlay specific OAM. Cross-layer correlation is an important area to cover. Jesse Gross: Inband telemetry work has some overlap with this, it is a P4 document. Erik: Could you send a pointer to that document. Dino: You said you need to test the remote side. You need a control plane for this to be effective. Dino: Another comment - how do I verify that this endpoint can communicate with another endpoint - that will have scaling issues. Probing is not needed at the encapsulation layer. Dino: We are doing probes to reach the other side, it takes 4 drafts to describe this feature - this seems too much. Dino: You can use ping and traceroute to find it out. This is a control plane feature, you should stay away from data plane. Erik: You would not run BFD across N-squared mesh of VNIs. But you may want to run directed proactive probes to specific VNIs. Dino: You always know the addresses as you do encapsulation to them. 1.5 - In-band OAM for NVO3 (10 min) draft-brockners-inband-oam-requirements-00.txt draft-brockners-inband-oam-data-00.txt draft-brockners-inband-oam-transport-00.txt draft-brockners-proof-of-transit-00.txt Presenter: Frank Brockners [presentation] [same presentation as in RTGWG] [discussion] Greg Mirsky: You said this method can be used for ECMP - unfortunately not. You will see only the paths that your traffic will be able to take. To see all paths you need active OAM and discovery to explore all paths. Greg: Second comment - test traffic could be detected and treated specially. You need to use dynamic port ranges to send your traffic. Frank: On ECMP - we do things for customer traffic, not the ECMP traffic. If customer traffic does not use that - it is fine. Frank: If you want to monitor something - monitor that, and not send an additional traffic. It is complementing existing solutions. Sam: Out of time for discussions. 1.6 - Discussion (35min) Matthew: Discussion on dataplane drafts. We have 3 WG drafts. GUE is moving to intarea. The concern of the chairs is that we are not helping the community by progressing all of them. We could publish all of them as informational and one on standards track based on deployment experience. We could also move to standards track and keeping others informational. Would like to hear the opinion at the mike. Alia Atlas: WG picked 3 different encapsulations that sat there for last 18 months. If people want to progress the work the WG needs to make the decision what to progress. Alia: If WG cannot come to a conclusion we can add a paragraph stating that WG had no consensus on the outcome. Alia: I would like to hear opinions. Alia: Are there strong technical reasons why the WG cannot make a decision? We need to do something specific that is needed for the industry. Please speak up. Dino: I think you should close the WG. Erik Nordmark: Historically there are deployments of VXLAN but that is an individual stream document. There are requirements for picking yet one more bit in the header for some new functionality. Erik: It is just an observation, I am not saying that the 3 proposals are technically bad. Sam Aldrin as individual: If we take drafts to informational, any work that we do in the control plane needs to support all of them. We have to pick one that is deployed and base the further work on it. VXLAN is deployed but is not a WG work item. Sam: If there are reasons for other protocols to exist, we can always bring them back. Tom Herbert: There is a reason why VXLAN is not on this list - there is no way to extend it. You cannot change it to include protocol type. This brings to a question of a least common denominator - if we do that to VXLAN, we need to convey onto all other possible protocols. Tom Herbert: VXLAN is not extensible into the future. There have been multiple attempts in this group to extend VXLAN. We likely need to move beyond VXLAN, but to which one of the three - they are not that different, they are fundamentally the same. Tom Herbert: VXLAN is likely not going away. Thomas Morin/Orange: Many solutions are looked at from implementation perspective in software. We also need to cover hardware implementations. If VXLAN is not good going into the future, we need to recommend one that is also implementable in hardware. Alia: I would like to get some sense of the room of how many people think we should pick only one? [quite many hands]. Alia: Who thinks it is not a correct answer of the WG to pick one? [no hands] Alia: Great - we need to pick one. Tom Herbert: Did you mean pick one encapsulation, or one of the options from the slides? Matthew: The first question was pick one. Alia: I would like to see significant technical objection against encapsulations. Matthew: Who has significant objection against VXLAN-GPE? Erik Nordmark: The extensibility pieces in GPE are somewhat limited. There are options that might be doable on the endpoint only, not on the hardware side. We still need that extensibility more generally. Jesse Gross: It is not feasible to use VXLAN-GPE. no name stated: VXLAN-GPE can encapsulate NSH. Andrew Dolganow: Can I ask that people state technical objectives, and not general statements? Tom Herbert: VXLAN-GPE - how do we insert security cookie? I have got no answer. How do I add a bit to do remote checksum offload? Did not get answer. Encapsulation design team has gone through many of those issues multiple times. I haven’t seen responses to those issues. There were no technical discussions on those topics. We are not going to make a decision now in 5 minutes. Alia: The reason IETF does consensus is to ensure not that there are no technical problems, but that we know them and are able to address them. I need to know what the technical problems are. Tom Herbert: We are not having technical issues being raised on the list. Alia: We will be taking conversation to the list. Lucy Young: If we are picking one encapsulation, does that mean that other cannot be published as experimental, provided that there are implementations in the industry? Matthew: That is possible, they would be informational. Alia: Are there more substantial objections on VXLAN-GPE? Matthew: Next encapsulation is GUE. Who has significant technical objections? Dino: I believe protocols do not need to be extensible. Example - LISP header is fixed, and we added crypto after the RFC came out. Adding new TLVs will require changes to hardware, and you may also change the port number at the same time. Jesse Gross: I disagree with that statement. There are possible ways to deal with it in backwards compatible manner. Dino: Interoperability is needed on data plane. Tom Herbert: TLVs are nondeterministically ordered. I am not convinced that we need to do TLVs in the hardware, I am worried about needing to support TLVs. Pat Thaler: Even skipping TLVs is not free, we have pressure to reduce the handling time or processing, and skipping does not help with that. Fixed format allows faster processing. This is what customers are demanding. Matthew: Issues with Geneve? Dino: Same as with GUE. Alia: There is also a reality of what is being implemented and deployed. Thank you for initiating this discussion. I hope that the draft authors for VXLAN-GPE and GUE now understand the concerns and would be able to respond. Tom Herbert: I would like to suggest is a correlation between those protocols and what we put into encapsulation DT considerations. Maybe draft authors could go line by line and see how they implement the encapsulation considerations. End of meeting, remaining topics on the agenda were not covered. - Data Plane encapsulation - OAM discussion - YANG modeling (Modeling work happening at IEEE) - Control plane discussion 1.7 - NVo3 Control Plane Protocol Using IS-IS (10min) https://tools.ietf.org/html/draft-xu-nvo3-isis-cp-02 Presenter - Xuxiao Hu 1.8 - Tunnel stitching for NVO traffic (10min) https://tools.ietf.org/html/draft-yong-nvo3-tunnel-stitching-00 Presenter - Lucy Yong