NVO3 Interim meeting – 26 October 2016 Attendees: T.Sridhar (tsridhar@vmware.com) giuseppe fioccola (giuseppe.fioccola@telecomitalia.it) Michael Smith (michsmit@cisco.com) Ignas Bagdonas (ibagdona.ietf@gmail.com) Tal Mizrahi (talmi@marvell.com) Tom Herbert (tom@herbertland.com) Alberto Rodriguez-Natal (albrodr2@cisco.com) Kiran (kiranmak@gmail.com) Alia Atlas (akatlas@gmail.com) David Melman (davidme@marvell.com) Sandy (sandy.breeze@eu.clara.net) Jon Hudson (jon.hudson@gmail.com) Sam Aldrin (aldrin.ietf@gmail.com) Matthew Bocci (matthew.bocci@nokia.com) Sowmini (sowmini.varadhan@oracle.com) Ilango (ilango.s.ganga@intel.com) Fabio Maino (fmaino@cisco.com) Greg Mirsky (gregimirsky@gmail.com) Minutes: Matthew Bocci: Meeting starting. Meeting is being recorded. Matthew: The main focus in on developments of encapsulation formats, and planning for Seoul meeting. Matthew: Note well applies. Matthew: agenda review. ------ Matthew: Review of the WG progress. Greg Mirsky: I have thought that OAM is very close to dataplane. Do you think that the solution will be closer? My recommendation to the DP design team is to take OAM requirements from overlay OAM DT. Greg: It may have implications to control plane solutions. Do you see that dataplane will have a separate document for OAM? How will it relate to overlay OAM? Matthew: Yes, there will be OAM implications on the dataplane from OAM. Sam Aldrin: WG needs to discuss how we can come to a common understanding and a common direction with OAM solutions. Greg: I see only OAM solutions here as deliverables. Do you see that a separate OAM work item on OAM requirements will be done too? Matthew: We have operational requirements document that covers OAM. Alia Atlas: Solutions documents are more important than requirements. Requirements are less valuable after the fact. But it is valuable as the work is being done. ------ Matthew: Progressing a single dataplane encapsulation. Matthew: Since adoption of 3 dataplane drafts there has been little progress done on them, and AD and chairs see that as a concern. There seems to be value in standardizing a single encapsulation. Matthew: We asked a question in Berlin and on the list whether to progress with a single encapsulation. The overall consensus seemed to be that we need a single encapsulation. Matthew: Question was asked on the list on what technical objections are there on the three encapsulations. Matthew: Responses are rather well balanced. Matthew: Existing 3 drafts could stay as informational, and one common encapsulation progressed as a standard. Fabio Maino: One of aspects of progressing on the existing proposals is for DT to share publicly how they are dealing with the requirements and how those requirements are influencing the design. Matthew: I do not want to hold DT by requiring them to produce a requirements draft. We have been through that exercise already. I would expect solutions document to include applicability statement. Fabio: I would encourage the DT to share the requirement work and what they are doing. We may contribute then. Matthew: DT will address that. Tom Herbert: We had a dataplane encapsulation team and they had looked into requirements extensively. Matthew: Yes, they produced a requirements draft and dataplane DT will reference that. Sam Aldrin: Some of the DT members were members of the previous team too. Fabio: Could you articulate the first point in your charter? Matthew: DT should produce the draft, the timing is controlled by them. Whether we can adopt it by the spring IETF is another question. 6 months away does not seem too bad. Matthew: DT charter text - with the strike out text removed. Are there any other comments on the charter? Matthew: No comments. Kiran: Will encapsulation and control plane work being done independently? Matthew: Yes those are separate work items. Kiran: Aren’t there interdependencies? Matthew: Likely not that many. Control plane needs to be extensible. Sam Aldrin: Once the DT comes up with some proposal for WG review, we should be able to see what impact is on the control plane. We do not see much impact. Kiran: If we want to add new feature for control plane, data plane needs to allow for that flexibility. Matthew: Your concern is that control plane may have implications on data plane? Kiran:L Yes. Example of OAM and trace functionality - it may need special flags or TLVs. Sam: We are not casting in stone that this is the dataplane and we have to deal with it. By the time we have a proposal we will be able to review whether it is applicable to control plane or not. This work can go in parallel. Kiran: I wanted to be sure that control plane is not overlooked. Sam: DT charter includes control plane. Matthew: Any other questions? ------ Matthew: Seoul meeting planning. Matthew: Given the OAM and control plane importance we would like to focus on those areas. Also we need to look at the more broad architecture in the context of NVO3 - broader than the DC itself, but inter-DC, gateways, etc. Matthew: And whether the solutions proposed take into account those architectural requirements. Matthew: One option is to have a roundtable discussion in the room on OAM and control plane. Matthew: Is that a good idea, or a non-starter? Alia: We had discussions on OAM work before. But there is no followup of the work that has started. There may be implications on how overall system works. Alia: We could have a smaller group discussions on specific topics and then combine the results of those separate discussions. Alia: We tried that on the mailing list but with little success. Alia: Common understanding on control plane and architectural work seems to be important. Tom Herbert: How would logistics of such meeting would work? Alia: We could ask for flipcharts and each table works on a separate topic. Then combine and present during the other meeting. Matthew: Would anyone be interested in leading one of such topics? Kiran: What would be examples of such topics? Could use cases be topics? Matthew: Yes. Or OAM, and control plane implications. Alia: Requirements for usability in different places in the network, what are the requirements on the control plane. Depending on the interest and based on use cases we may build a list of topics to develop a common understanding and expectations for the transit node, whether it needs anything more than standard IP routing and forwarding. Alia: How do you build this into a system. Kiran: All of this requires some form of control plane. Do you really think that we can split these features? Alia: There are aspects that we can talk separately. Take assumptions about control plane and make progress. Alia: EVPN work could be reused as an example. Kiran: That makes sense. Alia: It would be useful to have a sense from you all on what topics would be useful to have and discuss. Kiran: Most of the things that you have listed are good starting points. Matthew: We will develop a list of topics and sent to the list for feedback. ------ Matthew: Are there any other issues that anyone would like to raise? M: Thank you very much and see you in Seoul. Meeting ended.