NVO3 meeting minutes Wednesday November 16th, 13:30-15:00, 90 minutes ----- Meeting starting. 1. Welcome, Agenda Bashing, Status Update WG Chairs (15 min) Note well applies. 2. IEEE 802.1Qcn (VDP extension for NVO3) status update https://datatracker.ietf.org/doc/draft-ietf-nvo3-hpvr2nve-cp-req/ Pat Thaler (5 min) Pat presenting. [discussion] No questions and comments. Matthew: Is anyone interested in reviewing this draft? Benson is interested. Matthew: Will send a request to the list. 3. VXLAN YANG Data Model https://datatracker.ietf.org/doc/draft-chen-nvo3-vxlan-yang/ Fangwei Hu (10 min) Fangwei presenting. [discussion] Greg Mirsky: You have container for EVPN - should that be part of EVPN model and then you augment VXLAN and use this container? It is just a question? Fangwei: I agree with you, will discuss with the EVPN team on this. Lycy Young: Where do you specify the maximum MTU, and also tunnel security parameters? Suppose I am using IPsec. Fangwei: You mean the way how to configure the MTU for the tunnel? Lucy: Configure or discover, does not matter. Fangwei: I will consider your suggestion. Matthew: Please a show of hands who have read this draft? A few people. 4. BFD for VXLAN https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/ Greg Mirsky (10 min) Greg presenting. [discussion] Matthew: Who has read this version of the document? Version 4. A few people. Matthew: Would be good to get more review on the list. Please read and send comments. Sam: Have you presented this in BFD WG too? Greg: BFD is not meeting this time. We have announced on the mailing list. 5. Round table discussions (50 min) Matthew: Moving to roundtable discussion sessions. Alia: Injecting energy into the room. :-) Alia: We have OAM, data plane and control plane discussions. All of you have your own views on architecture and how it works, and please get into groups and encourage the discussion. [End of minutes for Wednesday meeting] Thursday November 17th, 13:30-15:00, 90 minutes ----- Meeting starting. Note well applies. 1. OAM Header for use in Overlay Networks https://datatracker.ietf.org/doc/draft-ooamdt-rtgwg-ooam-header/ Greg Mirsky (10 min) Greg presenting. [discussion] Matthew: The question is whether this work gets adopted here or in RTGWG. Greg: Yes. We also have two other documents in this set, use cases and gap analysis. Greg: In BIER we do have working group document already, if there is an agreement that these documents are something that we want to progress, we will work with BIER to make it more generic. There are multiple BIER specifics in BIER documents that are not applicable to scenarios seen here. Greg: Appreciate comments for common work on common overlay technologies. Lycy Young: The next version protocol - it could be used for inband OAM too? Greg: I would call it in-situ OAM and active OAM. Active OAM can be inband as well. In our discussion yesterday we talked about that. It can be inband and share the fate of the flow that it is monitoring. Greg: I would not refer to it as out of band OAM. We want to interpret defect detection and performance management - we want to correlate it with the data flow. Lucy: You have format and reserved fields - why are they separate? Greg: We originally took everything into flags, but added in reserved field for future extensibility. If there is a strong opinion against reserved field – let’s discuss it. It is possible to redefine and merge reserved flags. Reserved flags can be dedicated to something. Frank Brockners: How would this fit that into something like VXLAN-GPE? Greg: This is an update on version 0. OAM header follows immediately the packet header. In OAM header you can identify the next type of payload that follows the OAM control packet. Lucy: That would change the processing of the payload. Greg: We are open to discussion. You are right, in a case of active OAM it usually gets punted up. It may be a bump in the wire or something more complex, depends on implementation. In-situ OAM proposal is interesting and therefore this approach can work for both. Matthew: Who has read the draft? Please could more people read it? Greg: May I ask to keep all the groups - RTGWG and NVO3 - in the discussion loop? Matthew: Best would be to send comments to RTGWG instead of cross-posting. 2. On-demand Continuity Check (CC) and Connectivity Verification (CV) for Overlay Networks https://datatracker.ietf.org/doc/draft-ooamdt-rtgwg-demand-cc-cv/ Greg Mirsky (10 min) Greg presenting. [discussion] Matthew: Would be useful to get more feedback on this in the context of the transcending traceroute draft. Erik Nordmark: It works on a basis of regular traceroute packets, and tunnel operates in uniform mode, and not pipe mode. ICMP errors get propagated back to the edge routers. Sam: Do you envision it to support point to multipoint? Greg: We looked into it for BIER use cases which are point to multipoint. Matthew: Show of hands who has read the draft? A few more this time. Please send comments to the list. Sam: How do you propose this for different OAM that has different encapsulations? Greg: One of the objections was to make it transport independent. We have many instruments that are MPLS specific. In IPv6 it is not clear how this would work. We can develop comprehensive functionality and operators could choose what they need. Sam: Are you expecting both to be supported? Greg: Yes, it could work across multiple scenarios and multiple encapsulations. 3. Report back on round table discussions WG Chairs (70 min) Control plane - Benson presenting. Alia Atlas: L3SM has just finished and closing. There is an interesting YANG model on service description on topologies and attachments. It is a model of interaction for a customer and provider. It would be interesting to make a model to describe the pieces that are needed to set up this instance if service. Pat Thaler: One of the things that the control plane would need to deal with is migration and getting the changed information that the other NVEs need when migration happens. Lucy: The northbound - whether we call it operational data model? It is not necessary a service model as that one deals with customer interfaces. This is nortbound interface. Alia: The point was that it is not at the level of operational model, but Benson was talking about the higher layer abstractions and not trying to make a technology binding. Benson: it is to understand where the work needs to be done, maybe L2SM/L3SM example fit, maybe not. Lucy: In the industry we call it a controller and therefore I call it northbound. Benson: We try to distinguish between management and control plane and identify their separate functions. It is about the reachability, what needs to be exchanged. Without talking much about the implementation details - you may think about the tunnel implementation and a FIB as one or separate entities. How we model that is the discussion here. Lucy: Control plane is NVA to NVE, what I talk about is nortbound of NVA. Alia: There are many things that could be interesting, the question is who is interested on working on then and getting the work moving forward. There are many technologies in these contexts and control plane work has been neglected. Greg Mirsky: I would think that the liveness detection bullet may be a function of OAM. Benson: I agree. We talked about two types of liveness detection yesterday - NVE-NVE and NVE-NVA. Greg: We first had that functionality as part of routing protocols, but then we found that they cannot provide aggressive enough detection. Let’s see what the requirements are and see whether that can be part of control plane or OAM. Nabil: We need to first find out the things that we need to do on the interface between NVE and NVA. It seems to be a blur between what is management and control interface. Nabil: What Lucy is raising is somewhat different, it is more about the interface between the entities here. First we need to cover the NVE-NVA part, and then later talk about northbound. Nabil: We talked about configuring OAM endpoint via management, then we have liveness between NVE and NVA. That is not necessary a control plane. NVE could rely from management plane for push to the control plane. The reachability is in the context between NVE and NVA. How you configure the OAM functionality is not necessary the OAM itself, it is rather how to communicate and how to configure it. Benson: OAM definition and how it behaves happens in the control plane. We need to talk about the triggers. There may be connectivity between NVEs. Nabil: NVA needs to enable to trigger the OAM between NVEs. The enabling is important here, not necessary the OAM itself. If you have a very static environment you could configure the routing context and that could be done in the management plane. Reachability information that is dynamic in the nature could be pushed from the controller. Nabil: There may be very highly dynamic environment with a high rate of change then you may need to push the reachability information and the associated policies. That may be part of the service model, and maybe it needs to be discussed whether that needs to be communicated via management interface. Benson: I like the idea of having working group talking and understanding the static routing equivalent. It is complex to operate but simple to implement. Parviz Yegani: I need some clarification on relationship between service model, the control functions, and the NVA. In the context of SDN controller - if you put a controller layer synonymous to NVA, is that the intention here that you want to use NVA to capture the functionality of the controller layer? Benson: The way that we imagined that was exactly that - the word controller may carry some baggage though. We discussed yesterday whether we should think of NVA as only a controller. Parviz: In the industry if you look - that train has already passed. If IETF want to bring single control and orchestration layer into one layer then I am not certain whether that is relevant. Dynamic service and dynamic device configuration - there are two separate aspects Benson: You are raising a good point. If you think of NVE as a device, the FIB associated with the tenant - that relates to the configuration. Parviz: I disagree. The CRUD operations belong to orchestration. The controller is not in the business of doing lifecycle management. When you have service configuration aspects - where are they? We are doing service and device configuration aspects and that is part of ONOS, ODL, OpenStack, and that is happening elsewhere. The interaction between the NVA and NVE if there is a need to define a new protocol that is the task for the IETF. There are too many of southbound interfaces already. Benson: My opinion that there are too many of them and I cannot see how we could interoperate. Alia: Sometimes I have a bigger picture because many people come in and bang on my head. Alia: We need to get the interoperability - bring some of it here and discuss. This morning we had an open source routing meeting. Please think how we can interact better, what parts are standard, what are stable. Parviz: I want to see the management function moved to orchestration layer. Ali: Write a draft. Parviz: Also to expand on the service model. The service model is different from a dynamic service configuration of the service. Parviz: Then we have a dynamic configuration of the device. We need to understand that those 3 entities exist. Ali Sajassi: Seems that we have some confusion on the scope of work. What should be in scope is management and control for setting up the overlay. How do you configure and extended VLAN across the network that spans datacenters, core network. Configuring that extended VLAN requires configuration. The scope should not be above the NVA - no northbound. Benson: That also matches our charter. Greg: Another topic to discuss would be to get the proper terminology on what we consider to be static network. Once we have a proactive OAM and once it notifies the network then it is no longer static. Lucy: A comment on management and control - SDN controller imposes management and some of the control plane constructs. That is not necessary aligned with that model. Benson: These are just labels that I assigned to some buckets and in those buckets I put different things. We can use different names. Certainly service model term may imply different things to different people. Lucy: We can define same interfaces to management interfaces from different controllers. Jeff Tantsura: We could look at TEAS and I2RS, those have very clear interfaces to expose the business logic. Benson: That was a helpful discussion. Data plane roundtable. Pat presenting. David Black: Did the security discussion distinguish between the security of the header and integrity of the header? Pat: It as about the security and there were some discussions on the header checksum. Pat: I did get the feeling that we started getting some more closure on the extensions and it is more on how we take those extensions that they are friendly to the hardware. We were building good consensus on that. Sam/Google: what was the next step? How do we take it forward? Pat: We need a length and a way to say that some extensions need to come first, there was a string consensus to put any tunnel extensions in front. At this point it would be good to get some discussion on the list on the exact nature of the extensions. Another area that we need to build consensus is to see how much flexibility do we need of the extensions. We need to support vendor dependent extensions. What size, how many - that is an open question to standardize. What extensions do we want to standardize. Sam: Question to working group at large - do you think that most of the things that you would like to see covered here? What is missing? Nabil: I haven’t followed all the dataplane discussions. Today we are talking about extensions, but do we have something that we can extend already? Rather than trying to move this way, why not look from the dataplane requirements perspective. What is the minimal amount of things to be done beyond VXLAN as that is deployed? What other extensions need to be standardized? Matthew: That is the point to work out what that minimum set of extensions is. Pat: This is a list of extensions that we have consolidated. There are drafts that cover parts of them. We haven’t had as much discussion on the details of the extensions and that is good to bring in those discussions. Nabil: Do we have an NVO3 dataplane protocol? Alia: We have a design team that expressed the consensus of the WG to standardize the single dataplane encapsulation. Design team is working on the extensions of the current encapsulation. One source of confusion is trying to understand what kind of functionality is needed Nabil: The work on dataplane is happening. And at the same time we are talking about the extensions to that dataplane. Pat: Dataplane extensions include things how many extension you can carry, and we need to finish talking about that before we finish the dataplane work. We need to build consensus on what dataplane needs to do to carry those extensions. We need not to underdesign and overdesign here. Nabil: The protocol whatever we design allows to carry extensions, but define the extensions later. Make sure that the protocol is flexible enough to carry those extensions. Alia: We need to understand the details about the extensions. That drives the details on what we need to have in the extensions. Lucy:If we design an encapsulation protocol we need that protocol to be extendable. Matthew: Thank you. OAM roundtable discussion Greg presenting. Lucy: Why do you need another mailing list? Greg: I expect that after this meeting will be a lot of discussion. We are not requiring to do that. Matthew: Let’s keep on the WG mailing list for now. Tal: On alternative marking - we may allocate a few bits for the OAM encapsulation or other OAM related purposes. Greg: We will discuss and provide a proper justification. For now we identify it as a field that does not affect the forwarding decision and handling of the packet. David Black: On PMTUD - does it involve the DF bit? Greg: Before the meeting there was an agenda to align to some scenarios on pathMTU discovery, and one of them is heterogeneous tunnels. David: MTU discovery needs to be solved. It seems that OAM packets between the tunnel endpoints may provide some insight. David: genarea tunnels draft may be good to reference. Matthew: Thank you all for making this excellent roundtable session and discussion. Let us know if you found this as a useful experiment. [End of minutes for Thursday]