IETF108 NVO3 WG agenda ---------------------- Network Virtualisation Overlays WG Tuesday - 13:00-13:50 UTC - Room 6 1. WG Status update (WG Chairs, 10 min) Agenda bashing... - nvo3-encap-05 draft Call for review and feedback - EVPN Applicability to Geneve draft Waiting for BESS draft which is protocol extension for evpn to support Geneve. It is in WG last call. We will send them together to AD Martin and he will progress both together. - Virtual Machine Mobility It is in the process of publication. - Yang Models Would ask if this is ready for WG LC. It is a high level model and it does not go into all the details of how to configure the options of the encapsulations. We probably need Yang Doctors review for that. - OAM draft On the agenda. They aave been around for some time. We do need an OAM solution. I would suggest that we have another go after the presentation today and see if we can adopt these drafts. 2. Geneve OAM (Greg Mirsky, 15 minutes) draft-mmbb-nvo3-geneve-oam Greg presenting... Active oam uses specifically constructed packets to detect, troubleshoot, localize defects and measure performance. RFC7799 gives classification of three types of oam, active oam, passive oam and in between (refered as hybrid oam). Passive oam is oam that does not affect data packet in anyway,usually that would be snmp, information from pub/sub. Hybrid oam refers to methods that are on path telemetry collection and use some information that embedded in data packets themselves. Propose two Active OAM encap, had more and moved them in appendix: •IP/UDP Encapsulation Destination port number would be used for demultiplexing UDP based active oam protocols. Most of them are UDP based with an exception of ICMP. The concern is additional IP/UDP overhead which creates a distance between Geneve header and packet payload. •Geneve Associated Channel Use EtherOAM or a new Ethertype for Geneve oam. EtherOAM might be misinterpreted as cfm Y.1731 oam type. So probably better to get a new ethertype for Geneve Associated Channel encapsulation. Demultiplexing will be using the message type. The message type can be directly mapped to already existing pseudowire VCCV oam. Suggested use VNI 1 as a management VNI for oam. Management VNI has no tenants associated with it so that oam packets are not leaked. Echo request/echo reply depends on the decision of encapsulation. Plan to investigate and it's more likely it will be a reference to existing mechanism. Sam: Regarding the control channel you are proposing, what are you trying to verify using that? You mentioned using management VNI Greg: That can be used in the same way as in IP/UDP encapsulation, between Geneve nodes, not between tenants. Any oam function proactive defect detection of their Geneve tunnel, performance measurement along Geneve tunnel. Because it shares the same encapsulation as Geneve data packets, so it shares fate with them. Sam: disagree with sharing fate conclusion. Customer VNI is different. Greg: fate sharing is critical for active oam. Hashing Sam: You are assuming that it shares the same fate. I totally disagree with that because you could have totally different load balancer setup which could take depending on which customer you are talking to, what kind of traffic it is taking. The question is: you are trying to correlate based on what are the channel with the customer VNI which is not true. Greg: Yes, that's interesting point. Fate sharing is critical requirement for active OAM. So if VNI information is used for load balancing, then effectively we are talking about service oam because then it has to be tenant to tenant. Sam: Not necessarily, because you are using oam bit or whatever to trap the packet. So not necessary that you always have to go to the tenant. My point is that you are making an assumption here that the traffic for management VNI will always take the same fate as customer traffic which is not true. You might have a use case to measure but I don't see what exactly you are trying to measure. In case of IP/UDP for example, it is you're emulating like customer traffic, you are going to apply the same policies with the options you have for the customer because in this case with the control channel of Geneve I don't know what kind of options you are going to use because you are constructing totally abstract packet kind of thing. Greg: We have problem of number of sessions. The suggestion to use management VNI is that for defect detection it gives us a continuity check so it gives us assurance that there is a way for the network to get from one Geneve node to another. In regard to the performance measurement, I agree there is a challenge. But wouldn't be that outer IP encapsulation used to create an entropy? Or it's a payload used to create an entropy? Sam: My point is that any policies you're going to apply based on that the customer traffic and the kind of encapsulation use. You are proposing a general packet and you're trying to validate the customer path so that's where I am not able to see one to one there. But we can take it offline. Santosh: I just wanted to answer Sam's question. For load balancing it is the outer IP and UDP that is going to get used, right? David: Sometimes the VNI will get used as well and maybe the path forward here is not restrict to be the management VNI depending on what you are trying to assess. If something weird going on with a customer's traffic you might want to use the same VNI to figure out where it went off the rails. Reasons to use Management VNI or VNI for ordinary traffic, depending on what the OAM is being used to check/investigate Santosh: Agreed. So only in those cases I agree, but that is something like you are really verifying a tenant to tenant. It's for a tenant you are verifying and that's when the VNI comes into picture. But if you are verifying a node, then probably you really don't need to get the Geneve header itself. The outer IP and outer UDP is the one which is actually getting used to load balance. David: I think some of the discussion we're in semi-violent agreement and we need to write careful text on which VNI to use for what purpose. 3. BFD for Geneve (Xiao Min, 10 minutes) draft-xiao-nvo3-bfd-geneve Min presenting... 5 key points, see slides Matthew: I presume the intent is to point to the other draft for the encapsulations that you need. Make sure the two drafts (oam encap & BFD) are aligned and you are pointing to the oam encapsulation draft. Min: In this draft, I have made my own selection for encap. I selected the IP/UDP encapsulation. Because I think this kind of encapsulation is fate sharing with the real data packets. David: Agree with Matthew. We ought to use one encap for both drafts. At least for the non-management VNI case. Yes we ought to get them aligned. 4. LOOPS (Local Optimizations on Path Segments) updates (Yizhou Li, 10 min) draft-bormann-loops-geneve-binding draft-li-tsvwg-loops-problem-opportunities draft-welzl-loops-gen-info Yizhou presenting... LOOPS BoF will be on Friday. The key function is in-network recovery. It relates to NVO3 in a way that Geneve will be the first focus protocol embed this function in charter proposal. LOOPS runs between two Geneve NVE nodes. Transport feature will be discussed in BoF. Encapsulation is also important so we would like to invite Geneve encapsulation experts to join. Sam: Do you require specific codepoints from Geneve protocol to make this happen? Yizhou: Not yet, because we want to make sure the transport area comfortable with what we are proposing first. Afterwards when talking about the details of encapsulation, we would like to request for the codepoints. The codepoints are for the options. Sam: Does any of the intermediate hosts, not the end host, should be taking a look at any of these options and behave differently? Because one of the things we were deliberating for last few years is that the options do not play much within the network. In other words, it is pretty much into a negotiation and you won't be using much within the path. So I was just wondering like what exactly the implication because of that. Yizhou: We are expecting the LOOPS ingress and egress nodes are NVEs and not end hosts. They can be some NFV form of virtual nodes. We are seeing Geneve option are used in controlled environment for example in data center. In our specific use case, all the virtual nodes are NVEs which can be configured by a controller so that we can make sure all the virtual nodes/overlay nodes can support the same functionality of this option. That's the plan. Closing Matthew: Please review and comment the draft especially the OAM drafts. We would like to continue discussion on and move forward with some OAM solutions.