Nvo3 Status PagesNetwork Virtualization Overlays (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2012-May-01 —Chairs:
IETF-101 nvo3 minutes
Session 2018-03-21 1520-1650: Blenheim - Audio stream - nvo3 chatroom
IETF101 NVO3 WG agenda Network Virtualization Overlays WG Wednesday Afternoon session I - 15:20-16:50 - Blenheim Matthew: Welcome to NVO3 down in the dungeons. Matthew: Note well applies. 1. Administrativia. WG Chairs. 5 min Matthew: Blue sheets circulating. Note takers. This is a normal meeting, no roundtables. Please keep to your time slots. Alia is stepping as RTG AD. Thank you Alia for your guidance and support and encouragement. Martin is taking over as a new responsible AD, and good luck. Ignas has been a secretary for a while, he is stepping down. We will be looking for a new WG secretary. If you are interested in this role please come and see WG chairs after the meeting. Agenda bashing. Milestones. 2. WG status update. WG Chairs. 10 min Document status. Split NVE liaison to IEEE. Appreciate if you could take a look at the liaison and review it. See chairs for access credentials. LC plans for Geneve and DT encapsulation document. There is an ongoing poll for security requirements document. VMM protocol draft might be about the time to go into WG LC. Jorge: We have EVPN applicability draft that you have requested. We should issue WG adoption call soon. Matthew: Yes. Sam Aldrin: We will start the process. Jorge: Sounds good. Matthew: Incoming liaison from IEEE P802.1Qcy. Feedback by 15 May for this draft document. Pat Thaler: I will be retiring, but will send the message to the list with the names of the editors who will be managing this that people can send the feedback to the correct contacts. We appreciate feedback before we progress the document. Sponsor ballot is equivalent to LC in the IETF and it is getting close to be done. Pat: Last time it helped to get some people who committed to the review, if you could ask for people. Mat: If you would like to volunteer either raise your hand now or see the chairs at the end. Pat: This document is the control plane for the split NVE. 3. draft-mglt-nvo3-geneve-security-requirements-03 a) Ilango Ganga b) Daniel Migault Discussion on outstanding issues and comments 20 min Matthew: Ilango is going to do a remote presentation on his comments to the document, and Daniel is going to respond as an editor of the security document. Ilango presenting. Daniel presenting. Responses. Matthew: The old NVO3 security requirements document was written several years ago and since has expired. This one needs to go independently from the old security requirements document, the old one may never be published. What you need for Geneve should be in this requirements document. Matthew: We should avoid getting a misref from that document. Sam: Do you plan to address the comments from Ilango in the next version? Daniel: Yes. Sam: What is the timeframe? Daniel: Mid-April. Matthew: Maybe the way forward is to publish a new document. Not saying that the document has to be perfect, it just puts the document in to the hands of the WG to represent the consensus of the WG. Daniel: The next version is going to be -02 and not -00. 4. draft-ooamdt-rtgwg-ooam-header-03 Greg Mirsky 10 min Greg presenting. Asking for WG adoption. Matthew: A bit of history on this. We did run a WG adoption poll for this document. At that time we had very few participants proposing and opposing the adoption, it was difficult to judge the consensus given the lack of participation on the list. It would be very good to sense whether people have read this document and express their opinion. There are other OAM drafts too, we cannot sit and wait. Frank Brockners: Would help the document if you added the applicability section that said how that particular header would be slotted in with Geneve, GRE, and the likes. What you have now work well for protocols that have a pointer of next header of 8 bits. That would not work for 16 bit protocol pointers. Showing how that fits in a general way would give more appeal for people to care about it. Greg: Are you suggesting that different encapsulations have different length of the next protocol field? Frank: It depends where you want to go with this. If you have GRE, next type will be ethertype. I wonder where it does apply, how does that apply, and adding that to the document would be of great help. Greg: I will look into the document, but our original goal was to use ion new encapsulations like BIER, Geneve, SFC. Whether that is applicable to GRE we need to discuss. Frank. Having applicability and deployment section would be good. Greg: In BIER, Geneve, and NSH it looks not different. Sam: . ?/Cisco: Curious to know - this seems to be an inband OAM type. How would this relate to IOAM work in IPPM? Greg: I would stress that inband behavior of OAM is the function of the encapsulation layer. If it draws only from the encapsulation layer and not from the payload then any type of OAM will be inband. In order to ensure that active OAM is inband with the data flow it puts certain restrictions on how the following decision should be drawn. One of the examples that we have is an example how this type of encapsulation can be used for IOAM. The format of the header is something that we can discuss. ?/Cisco: Can you explain how the next protocol is supposed to be used? Do you need to look at the first part of the header? Greg: Yes. If next protocol is 0 it means you have only OAM control packet. If you have nonzero it means that there is something following after the control packet. ?/Cisco: I will take this offline. Greg: Next protocol registry is something that we can discuss. Ilango: The OAM proposal that you have is applicable at different layers, it could be on the overlay layer, it could be on the service layer. Both could coexist, and the document does not have enough applicability information for this case. Greg: I would personally think that the same packet for the OAM for different layers. Ilango: Not necessarily. NSH can be transported on multiple different transports. If you go through multiple encapsulations before reaching the service node. OAM as part of the NSH header is independent from OAM in the overlay layer. Greg: It would be interesting and helpful to get some operational considerations where one packet is OAM for NSH and overlay transport at the same time. How to identify where the fault happened. It is much easier if it is done on the on the different layers. Ilango: Can you clarify that in the further version of the document? Greg: This can be applied on both layers but independently. Parviz: Back to Franks question on applicability - you are going to change behavior of SFC nodes? Is it going to impact the behavior of the SF node, or is it transparent? Greg: If we talk about active OAM, we have multilayer OAM individual document in SFC WG, the scope is SFF. Parviz: Forwarding behavior? Greg: Forwarding behavior is based on SFF, not SF. Parviz: The behavior of the forwarding node is captured? Greg: The expected behavior - the document introduces echo request and reply, and SFF can reply to the sender out of band as requested. Sam: Clarification question. Are you going to pursue this in other WGs? Are you going to pursue to get a common solution? Greg: If the WG in the current work in the header - there is a dependency between OOAM DT and this work in header. If both documents get adopted I will pursue a common solution, if not I will continue with SFC. Matthew: Show of hands who have read the draft? 10 hands. Matthew: Of those who have read the draft, how many think of common header? 1 hand. Matthew: Of those who have read who do not think it is a good idea? None. Matthew: Please read the draft. Alia: I would like to reiterate - I am very happy to see the discussion happening, this is something that WG was working for 3-4 years. We need this. VXLAN has been deployed for a very long time, and Geneve is coming. Lets get this done. 5. draft-ao-nvo3-multi-encap-interconnect-00 Ting Ao 10 min Ting presenting. Discussion. Kyle Larose/Sandvine: Curious what motivated you to start to work on this? This seems to be similar to Network Slicing. There is a gateway function there. The other document that I am reading is much higher layer. Is this appropriate to COMS BoF tomorrow? Ting: This is for dataplane. Zachy Haramaty/Mellanox: The TNV can be combined, what is the reason for this? Logically it is a separate entity even if vendor would combine it? Ting: . Zachy: I still think that TNV as a component does not need to connect, it is a separate logical component. Greg: Can you roll back to the reference model. Zachy: TNV in the middle can be connected to a TS. Greg: It is not a requirement. Zachy: That is a different logical entity. Greg: That is why we give a different name. Frank Brockners: Where do you want to take this work? Right now it is an articulation of the problem domain. I have this uber thing that provides for mapping device. Do you want to specify protocols, what is the next step? Ting: Do you mean the protocol between TNV and ? Frank: You articulated on the architecture. Today I have VXLAN getting in and Gneeve leaving, that is set up. What you articulating is that someone needs to set up the control protocols. Are you intending to standardize the control protocols? Greg: Yes. Frank is right. This is a problem statement at this time. We are looking whether this is a problem to be solved. What is the conclusion - adoption of this document will be an agreement that this is a problem that needs to be solved. Not necessarily this will be a document that provides a protocol or a standard way of a solution. There needs to be some normalization of negotiation of what protocol is capable of, what needs to be translated. Yes, there will be some negotiation of the control plane in order to work on the data plane layer. Matthew: That is a problem statement. We have one standard dataplane encapsulation. Interworking between how standard encapsulation and a set of those that are not standard ones. Greg: That is why we are not going to the solution but first say that if WG agrees that this is a problem that is worth to be working on. Mathew: We have architecture RFC, and this is an extension that can apply to it. 6. draft-xiang-nvo3-geneve-packet-spray-00 Yolanda Yu 10 min Yolanda presenting. Kyle: That was pretty cool. Why did you put source UDP port? Was it the same for all the flows that you would get distribution within the mesh? Kyle: You used Geneve? When you build Geneve header and you out in UDP header, what value did you use for source port? Yolanda: It was random. We are considering to involve node aware parameter. Kyle: It would be nice to have some guidance on this draft - if all packets take one point and there is a congestion there it is different if you would use different source point input. Zachy: Name of the document - packet spraying is a unique case, the document talks about packet reordering. Greg: That is not necessary. Packet reordering may happen, it is not the goal. Zachy: The document defines the framework for packet handling. Greg: My understanding of the document - because of spraying reordering may happen and this is how we recommend to handle the situation. This is a proposal for mitigating this. Zachy: There is a chapter 5.3, I think this is a generic infrastructure. Yolanda: I got a comment via email that this should be a separate draft. There is no encapsulation for TCP over Geneve directly. We will post another draft about that. Matthew: question from Meetecho: [audio unusable]. 7. Working Group next steps open mic Chairs 10 min Matthew: Next steps in WG. OAM is a topic that needs to be covered. EVPN applicability draft. That leaves centralized control plane/management plane. We need YANG model for Geneve, and a generic YANG model for configuring various elements in the NVO3 architecture. We may want to have a YANG DT team for NVO3. Matthew: Anyone interested in developing YANG model? None. Matthew: Have a think about it. This is more in the management plane. We have not focused on a true centralized management plane yet. Alia: What are you all interested in working on? Just Geneve? Do we need any other chunks? What are you looking for, what are the things that are missing? Obviously you here are watching and interested what do you see as gaps? Matthew: Any comments? Is there anything that needs to be done for management plane? There is work in LSVR on centralized control plane? Would you like to see any work in that area done in NVO3? Please raise your hand if you would like NVO3 to work on a more centralized dynamic management plane? No hands. Martin, incoming RTG AD: Seeing an overwhelming number of responses, I would ask a different question - should we close NVO3 when we have done Geneve? Please raise your hands. Greg: Lets define what is done. Does it mean that Geneve specification achieves standard, or we have done OAM as well, and done YANG model? To me to say yes first I need to understand what done means. Sam: For YANG, no-one in the room raised hands. Greg: Give us some time to sleep on it. Jumping the gun may not be the best thing. Probably I would appreciate if we discussed really more seriously what done means, what scope of the work is a complete set of functionality that we can release to the world and say that we are done. ?: One document discussed potential new options for Geneve header. YANG model for the configuration would be a very useful thing. I am speaking in favor of doing something for the centralized model. Sam: We have a good presentation from Frank, I am not sure whether the authors would like to pursue that work. Daniel: When you say Geneve is completed, do you include security mechanisms too? Matthew: Yes. Do we need to do anything more in the control and management plane? Frank: There are many aspects to OAM, some of the work is done in IPPM. It would make sense to continue with big items to make a complete protocol solution. Maybe call it Geneve maintenance. I also advocate for YANG models. That would be useful. Jeff Tantsura: I would recommend to have a YANG DT. We had routing YANG DT, they delivered great models. Matthew: Drop us email if you would like to serve on YANG DT. Jeff: YANG expertise outside of NETMOD is sparse, potentially those who worked on routing. Martin: May I suggest that you relay those questions on the list to reach a broader audience? Matthew: Yes. Matthew: End of meeting.