Network Virtualisation Overlays WG
Friday Afternoon session I - 12:20-13:50 ¨C Duluth
1. WG Status update?
(WG Chairs, 10mins)

agenda bashing.

Matthew: show of hands for data encapsulation doc. Who recently read the draft?
Reasonable proportion of the number of people in the room. Take that to list and do a poll. It's a pretty mature document. It was the output of the design team so we just thought it was a good idea to publish it as a documentation of our experience in picking an encapsulation from multiple competing encapsulations. Martin?

Martin: Martin, as a routing AD. I'm fine if the working group believes that it's needed. Be aware that typically on some of these types of documents IESG tends to ask whether that's really needed to publish as an RFC.

Matthew: This is more for the benefit of the broader eyes you have to document the process by which we picks an encapsulation format when we had quite a lot of controversy around which encapsulation should move forward and this is something that happens repeatedly in different working groups. 

Martin: okay is that clear in the document that the type of information we will find?
Matthew: Yeah.

Matthew: In working group last call, we had the evpn applicability to Geneve which is currently with the document shepherd. It went through working group last call there wasn't any objection to that. I think Sam you're handling that. Any update? 

Sam: I think the Shepherd writeup will due so I will be doing that after the IETF meeting.

Matthew: We also had a virtual machine mobility draft that some of you may remember that went through working group last call last year. It also had some reviews and quite a lot of discussion on the list from TSV area review team, the ops Directorate and there was also a routing Directorate review. I think that some of the issues that were raised by the TSVART directorate reviews weren't fully addressed by the editor at the time. And the editor has gone absent so we have a volunteer to pick up the pen on the draft. So hopefully we'll be able to move forward with that document and get those reviews addressed. I don't think there was any other real problems with that. I think it was mostly some comments that were raised during these area reviews that needed to be addressed properly. So thanks Linda who was unfortunately not here for picking it up. 

Tal Mizrahi: just a short question regarding the VXLAN-GPE document we have a plan to publish that in the future?

Matthew: now Geneve is with IESG, so just to refresh the working groups memory: the original decision was that the other encapsulation drafts could go forward as informational or experimental following a publication of Geneve. So it's kind of up to the authors to at least refresh the drafts. Can I get a show of hands who has read any of those other encapsulation drafts and such as VXLAN-GPE recently?

A few hands.

Matthew: okay. We did promise we would do that and a working group agreed to do that so I think we should probably maybe after the design team encapsulation draft has been published, it's going to the IESG, it'll be good time then.

Tal: thanks.

Matthew: then a little bit of context to the IESG about why we're going forward or publishing some other encapsulation drafts.
 
Gregory: I appreciated that Tal brought it up. So you mentioned that because GUE went to different area, so the VXLAN-GPE you consider it to be informational or experimental? 

Matthew: Yes, because this working group decided to pick one standard track.

Greg: How much of influence you see that the working group will have over the informational or experimental track document? 

Matthew: They're still working group documents here, they're not individual submissions to the RFC editor. It's not like when we originally did VXLAN and it went to individual in which case we didn't own it and in this case we own it¡­. 

Greg: because in my interpretation of experimental and information it's just reflective whatever being implemented so it's not that¡­. 

Matthew: I think that's true for experimental but for informational. It's definitely can be more than that. Because in either case they're still working group documents.
 
Greg: okay because I do have strong concerns about what they've done in their recent versions. 

Sam: Given that they are working group documents I think working group has a say in how the document is going to be¡­

Greg: I appreciate your clarification because again in the standards it's quite clear in my mind that their editors in the working group is working with the document. But with informational or experimental it's¡­..

Matthew: I don't know if for the experimental case, Martin do you have any comment on that? I guess the question is if VXLAN-GPR for example is published as experimental or goes forward as an experimental document, how much say does the working group have over the technical details of the draft? Because of course it's documenting an implementation. 

Martin: (missed¡­ not on microphone) 

Greg: In some cases we have at IETF where their implementation or de facto standard being put on an informational track. But experimental is more of really reflective of some experience of particular implementation. So basically we cannot really say, oh you should have implemented differently. Because the response I would imagine will be ¡°no!¡±¡­.

Tal: At this point it's informational. So maybe we can leave it that way and avoid the potential issues. 

Greg: My understanding is that if we don't have anybody from this group of working with the VXLAN-GPE document I think that needs to be discussed with them what they would like to do¡­ 

Matthew: We kind of need to have a consensus of the working group as well as to which way forward. You can argue probably they could be experimental because we have one standard track document so why are we arguing over there or debating the technical details of another encapsulation? why don't we just document what's been implemented for the other encapsulations? My personal view is it seems slightly contradictory to have an informational document describing encapsulation and the standard track document describing an encapsulation. Perhaps an experimental description might be more appropriate 

Tal: I think in my view the main problem with the experimental is that you need to revisit it two or three or whatever years afterwards and if it's informational you don't necessarily need to revisit it.

Matthew: The security requirements draft that's on the agenda. It's next up on the agenda. I just want to have a notes about there's a draft that was originally discussed in the BFD working group for BFD over Geneve. It doesn't really propose any changes to BFD. It's not more about how you encapsulate in Geneve. There was some discussion between the BFD and NVo3 chairs about where this document should be progressed. The feeling amongst the chairs was it should go forward in NVO3.

Greg: yes and we followed on your suggestion. We resubmitted it with the individual draft. We are not presenting at this time so¡­ 

Matthew: Need some review of that draft and we should go for it with a working group adoption poll if there sufficient interest in the working group. Can I get a show of hands has anyone read this document?

4 or 5¡­

Matthew: we definitely need a little bit more people reading it. Greg, if you can send something to the list asking for review?

Greg: Yes. First let's discuss their encapsulation draft, so then we'll take this feedback from encapsulation discussion and use it in our BFD document and then we'll do a discussion of the BFD document.

2. Security update?
(Daniel Migault,20 mins)
draft-mglt-nvo3-geneve-security-requirements-06?
draft-mglt-nvo3-geneve-security-architecture-00?

Daniel presenting...

Transit devices (TD) vs non-transit devices
Problem: when transit devices are in use, there could be no security protection on their options.?
Need mechanism to enforce TD only READ and restricting TD reading other data by partial encryption

Sami: do not think it works. Option length has to be known in advance. What we discussed is it is able to authenticate some of the options. But not encryption. It could be good to change some of the options, but not add options by TD. You can authenticate some of the options, not all options. You can pick what you want to authenticate to allow the midpoint to change some of the options they want.

Daniel: What you're saying is that the transit device may change an option?  

Sami: Correct. May update it. 

Daniel: okay so that's a different requirement.

Sami: okay I think we probably miss this one. so may want to consider this one. but in terms of encrypting one option only, I don't think is possible. 

Daniel: so it's feasible it might not be a good idea. 

Sami: I am not sure it is feasible.
Daniel: okay so that we can discuss. It may make no sense to encrypt one option. That's the kind of things we'd like to know on how to design the security requirements to know exactly what we would like to achieve because we can end up in something very complex. The requirement we have now are pretty complex because we're kind of opening all the different possibilities. 

Sami: In my opinion encrypt only the payload or the whole thing. For options, we authenticate the whole thing or portion.

Daniel: so which means all options will be either encrypted or not encrypted

Sami: and option can be authenticated, all of them or portion.

Daniel: That's a good point. I'm fine. We can discuss it.

Ilango: First of all I would like to state that architecturally what we envisioned is NVE is an end to end protocol. I think I've explained this multiple times in the mailing list as well as part of the review. It's an end-to-end protocol and so the transit devices are nothing but forwarding elements that are already available in the underlay network. It could be routers or switches and so on. So if there is an end-to-end encryption employed which means that these forwarding elements will not be able to see the options header, that's perfectly fine. We have already described saying that if such is the case these elements which are called as transit devices will have to forward it like any other IP packet. That's it. That's very clear. These forwarding devices or transit devices interpreting these options is not an absolute requirement for the functioning of the protocol. So we did not envision saying that let's just show part of this option to this particular transit device and exchange keys between the transit device in the endpoint, that was not the intent at all. That's very clear if you read the draft. 

Ilango: There are many different protocols, for example, if you take it in RFC 8086 which is GRE over UDP. Same thing, GRE key is an equivalent to an option here. There is no requirement that you selectively encrypt or decrypt or send it in the clear. Just this GRE key, so that intermediate forwarding no need to look at it. No, that's not the intent. Same here. Geneve is no different than any other UDP encapsulation protocol. So this whole argument or talking about saying that let's go and show this partially encrypt some parts of the options, that's not supported in the architecture and that's not what we really wanted to go in this direction.

Greg: Actually I think that in addition to looking at the payload we need to look at how this security framework will be impacting active oam. Because if we want to do traceroute, the tunnel that we're using, so to determine where in underlay we are traversing the network, so we need to transcending and how to work if we're doing encryption or we saying that oam would not be encrypted. We don't have to discuss it now, just something to think about it and look at how it may work. 

Daniel: When you say OAM, is it a Geneve option? Oh, it's a bit in the header?

Greg: The bit in the header now refers to as a control packet. We¡¯ll be discussing oam encapsulation later today in the session. What I'm just saying is that active oam is a specially constructed packet that injected, but what's important and critical is that active oam follows the same path and receives the same treatment as data flow packet, so basically they fate sharing. So would encrypting the data packets and for example possibly speculating not encrypting test packets, will still enable us to do fate sharing or not? 

Daniel: Just want to understand, OAM is implemented through maybe an option and some fields in the fixed header?

Greg: No, oam implemented through the payload.

Daniel: Oh within the payload. okay and so what you would like is that some payload would be non-encrypted.

Greg: I envisioned that there is a need to traverse the underlay tunnel and for that the payload needs to be visible to TD

Daniel: We have to check how to make it but it's interesting. 

Greg: One possible scenario is that add oam for that purpose should not be encrypted, but the question then is that would that still preserve or let us preserve fate sharing with the data flow?

Sam: If you're sending the packet, just the data plane itself is encrypted, right? From end to end, it doesn't mean anything because you cannot peek into the payload irrespective of whether you're a transit device or not. It should behave just like any other data packet, otherwise you are pretty much breaking the security whatever you have set up. 

Sam: I have a couple of for high-level questions. The first one is I know this was kind of discussed but I just want to bring to the notice of working group. We had this as Geneve security requirements. Why not NVO3? Because this is nothing to do with specifically Geneve. This should be for the virtual networks because we are driving the virtual networks.

Daniel: One reason is that there is an NVO3 requirement document, but this draft has not been continued. So we started a Geneve because one of the main difference between the security requirements provide for nvo3 did not consider the transit device.

Sam: Sure. but that goes to my question of like what is transit device in the architectures. That should be addressed from the architecture perspective but not the security. Neither should encap define what TDs are. It should be part of the architect. 

Daniel: Yes definitely, because we don't understand what those transit device do and I think currently the situation is that this device have not been defined properly, so they can have a single option, they can read, they can have a single option dedicated for that device, can encrypt and probably we are providing too many use cases that are not intended to be used.

Sam: Sure. That goes to the solution aspect, not the requirement aspect. From the requirement perspective, if there is a definition for what transit device is then the requirement should address NVO3. If you're considering this as end-to-end protocol and you're going to define the protocol for end-to-end, then the security should address the end to end part of that, and for the transit then I think Matthew and I can talk about what the transit, how we are planning to do that, but we shouldn't be defining what transit means as part of the secure requirements.

Matthew: The thing was when transit devices were originally envisaged perhaps some people were saying they were more than just a router. It could be a firewall for example or there could be some other box that does some deep packet inspection or something on the nvo3 frame. But the problem is that was never discussed or never described as part of the NVO3 architecture. Neither of functionality. So the only definition that we really have of a transit devices is in the Geneve encapsulation draft which may not be a complete definition.

Sami: I think from what I understood from what Ilango was saying, if the transit device will be only a router or firewall, then it shouldn't be inspecting any options. Then transit device here simply a router, not be looking at option. It's only the NVE who looked. NVE can look. When we are talking about option between NVEs, should we encrypt them, should we only authenticate them, and that's about it. If a device will inspect the options, then it is an NVE. I think we can go that definition too. That should be fine. There is no transit device that inspects option. Of course transit device exists but only as router or as far as forwarding IP packet and cannot look beyond IP packet. 

Matthew: The problem with that statement¡­..do ECMP¡­ 

Sami: yeah, if they do hashing on five tuples or even seven couples, you are looking at UDP or the transport layer port. They do not look beyond layer four. So the router even the firewall they look only at UDP ports or TCP port so sure you can look at port if it exists if then NVE decide to expose the UDP header and the Geneve header and not encrypted then the router can look at it. Maybe this should be the definition if everybody is okay with that: Transit device really has no role in NVO3 architecture and Geneve as well. It only exists because there are routers that can switch back. 

Ilango: In practice there exists the devices is ECMP router. For example, they look inside the packet, they skip over possibly the options and look inside the payload and then might still employ ECMP policies¡­ 

Sami: You want the router here to look inside the payload after the option and do something with it? 

Ilango: It could. We can¡¯t preclude that. If the packet is in clear, no one can stop an intermediate device in the underlined network to look into that information and then do what it wants to do. All we are saying is if you look into it then there are certain restrictions we are trying to make the people aware that if they are looking into it they're not supposed to do certain things. That's all we defined in the draft.

Sami: okay. So what you are is the transit device can do whatever he needs to do to forward a packet, but really not alter any data on the packet.

Ilango: That's exactly what we have defined in the draft. If you're worried about a transit device tampering with the data, then there's a possibility for you to introduce an end to end authentication mechanisms. 

Sami: What we are saying is if the whole packet is encrypted, a transit device won't be able to look at any payload here because it's encrypted. If the packet goes in clear, the transit device can do whatever it can do with it but without changing anything of the packet if security is in play with the authentication for example. So I think what you are saying here, who is handling options really handling meaning processing, understanding what the option is about, and so on, is going to be NVEs, not transit device.

Ilango: That's correct. That's what we have a clearly explanation in the draft. What the security requirement draft is trying to give some solutions like what Daniel is explaining, that's not what is supported in the Geneve architecture and that's basically what I am trying to say. 

Sami: okay so from security aspect we just need not to have any transit devices here, we'll just call them NVE¡­ 

Ilango: it will be there whether we like it or not. These are underlay devices¡­ 

Sami: I am not saying the transit device will not be there, but what we are saying is it is not playing a role in security. Meaning it¡¯s not authenticating, it¡¯s not encrypting, it¡¯s not decrypting, it's not doing any of that. So where the device exists as from a security perspective as a pass-through device.

Sam: To what you said earlier was we do have similar technologies like VPN and all that stuff. And this is no different to that. So we shouldn't be redefining like the partial lookup for the transit device. There is no specification or precedence to set like partial option and those kind of things. We shouldn't be coming up with some new requirement when other protocols which are already in existence do not define those. This is not different.
Sami: I agree. If they are NVEs now and they can change the options and re-authenticate¡­ So the whole option or the whole packet can be encrypted, the whole packet can be authenticated, option and payload.. 

Sam: The final thing, should we convert this to a NVO3 security requirements instead of a Geneve security requirements?

Sami: NVO3 shouldn't worry about the transit devices in terms of security procedure. But as Geneve is defining as the transit is the pass-through device for packet, whatever it do to the packet its own decision, but if security should not change any options of that. 

Daniel: so in the Geneve we won't have any transit device, is that correct in the specification?

Sami: We will not have a transit device from the security procedure perspective, but the transit device would exist to still forward the packet.

Daniel: but the problem we have is that if the transit device is able to look at the options?

Sami: He can look at the option, but he's not allowed to alter or touch it. 

Matthew: In some VPN architecture, they do describe them. So we've got to recognize that they're there. You can say what they're not expected to do to the Geneve header. They can read it. As soon as you terminate it, that's an NVE. 

More than one: correct/yes.

Matthew: If you want to change anything in it, you're an NVE. But you can read it. The transit devices can read it to make some forwarding decision¡­

Sami: Yes, it can make forwarding decisions based on that with no touching of it or altering it.

Matthew: If we can scope what it does to Geneve or doesn't to Geneve¡­. 

Sami: Geneve is apparently describing this, so if that description is fine, then they already have a description¡­ 

Matthew: but there's nothing specific to Geneve. This is not special to Geneve, it¡¯s just written in a Geneve draft because it wasn't been done anywhere else. 

Sami: because Geneve was acknowledging there will be devices between NVEs that will forward packets.. 

Matthew: because a lot of this discussion arose after the NVO3 architecture was done, so¡­ 

Sami: maybe NVO3 architecture probably assumed that there will be transit device, but we have no role for tunnel¡­

Matthew: I don't recall the discussion even coming up until we started talking about traceroute, OAM. 

Sami: I see

Matthew: there's OAM implications of these things as well.

Sami: In terms of OAM as well, with traceroute and so on, it can be treated like an IP packet. An IP UDP packet, if the TTL expires, it would send ICMP error back.

Matthew: That¡¯s for the underlay¡­

Matthew: I think the objective of that was to trace a particular VNI.

Sami: I assume here was what you are defining is security¡­and the transit devices cannot really change any option.

Daniel: but a device that has a different behavior if it's secured or non-secured.. it is bringing a contradiction into the architecture because it means if you want to secure that deployment, you have to balance¡­

Sami: The ingress point and the egress point are the only nodes who are allowed to touch that and do anything to the packet. If you are touching, you are NVE. If you want to do traceroute between those two NVE by transit routers, it's fine too because they are not going to be touching anything on the packet. It would simply be sending errors back or some indication back to say I am on the way.

Daniel: but the thing is that if you have a deployment that is going through a transit device and you rely on the fact that he's inspecting the packet, you won't be able to secure that. 

Sam: that's fine, that's the deployment scenario. We do have like VCCV deployments, we have different deployments. If you don't secure end-to-end, then you are defining your network design to make sure that others can actually inspect the packet, but if you really want to do that, you secure the whole payload including whatever ¡­ In other words,  there is no requirement that it should or shouldn't do certain selectively things. If the end-to-end is encrypted, period, I cannot look into that. If it is not restricted or not encrypted, then transit device can look into that. 

Daniel: but if you have a deployment where that is relying on those transit devices and then you have been asked to say can you secure NVE to NVE communications 

Sami: You can secure it because you are either encrypting between NVEs so the transit device is a passthrough, doesn't know what's inside the packet, or you can authenticate it and in that case he can look because the data is clear, but he cannot do much as well ,he's only looking at what you sent in clear

Daniel: but the deployment of security is going to be deeply impacted by those transit device because depending on what you are¡­.

Sami: ¡­you want to show stuff in clear or not. If you don't want to show stuff in clear, then the transit is a simply forwarding an IP packet.

Daniel: but once you choose you can't go back, it's really hard¡­ 

More than one: that¡¯s fine¡­

Matthew: we should take this to list because we've got three more presentations¡­

3. Base YANG Data Model for NVO3 Protocols?
(Remy Liu, 10 mins)
draft-zhang-nvo3-yang-cfg-06
Remy presenting...
New co-author from another YANG draft.
Change NVE from container to an interface
Change VNI to be mapped to L2vpn and l3vpn
adoption?

show of hands.
quite a good number of people. Take it to the list.


4. MAC move over Geneve encapsulation
(Sami Boutros, 10 mins)
draft-boutros-nvo3-mac-move-over-geneve-01?
Sami presenting....

Jorge: clarification questions. Try to get MAC moving problems and solutions proposed¡­
The use case is confusing¡­
Sami: will update the draft.

Jeff: confusing too. If MAC has moved and that interface became unavailable, you've got some relationship between NVE1 and NVE2 from service perspective.
Sami: clarifying..
 
Yizhou: We did more or less the similar things in TRILL before. Some idea could borrow. NVE1 & 2 are using anycast address. Gratuitous ARP as MAC move signal? Any special tunnel between NVE1 to NVE2?
Sami: clarify and explain the whole picture. Similar as pseudowire¡­
Yizhou: understand the motivation. but the mechanisms are not clear
Sami: will update

Alberto: so you need data plane traffic to trigger the update?
Sami: No, it¡¯s a special message. You send a Geneve packet with option, with no data no payload. 
Alberto: A control plane signal?
Sami: sure if you want to call it this way.

5. OAM for use in Geneve
(Greg Mirsky, 15 mins)
draft-mmbb-nvo3-geneve-oam-00
Greg presenting...
Active oam. different approches...

Matthew: should o-bit be better defined? I mean it seems to me that you've got three potential..

Greg: I was of opinion that we don't need o-bit or at least we don't need o-bit for identifying active oam. If somebody wants to use all be to identify the presence of OAM information and extensions, of course... but for active oam I don't see the reason. we have protocol type, that's sufficient.

Prakash: How is it different from the existing NVO3 oam draft? Earlier draft..

Greg: I don't recall the NVO3 oam draft

Prakash: similar oam channel used 8902 ethertype?

Greg: if you can send me the link¡­ similar information is Geneve BFD draft... I'm not familiar with the draft, if you can find the draft and send it to the list 

Continue with Geneve Associated Channel page

Matthew: Which ethertype are you using?

Greg: the same that 1731 is using 
Matthew: but it's not 1731 
Greg: no, but we're using the same ethertype.

Matthew: so specifically the question is which of the encapsulation should be selected?

Greg: Yes. We need to select one encapsulation, we don't need multiple because that will be painful for everyone.

Frank: Just for my understanding, so if the protocol type is OAM, that's the aforementioned 8902 ethertype, that means the active OAM packet would be CFM or what goes into this active OAM thing?

Greg: No, it doesn't have to be CFM. Why it has to be CFM?

Frank: trying to understand what active oam is and what you assuming.. 

Greg: BFD control packet. Because it will be channel type. The channel type defines what is active oam, not protocol type defines what active oam is. Demultiplexing is based on channel type.

Frank: What do you foresee go in active oam?

Greg: ethertype oam.

Frank: give me an example of what active oam packet would mean from your perspective? 

Greg: It's BFD control packets for example¡­ channel type.. have you looked at the VCCV..

Matthew: my concern is overloading the meaning of the protocol type oam if that really means effectively CFM 

Greg: yeah but we are reusing it 

Matthew: but it's not CFM, here is ACH. Do we need an ethertype for ACH?

Greg: If it's confusing that we can get the another ethertype, but i think that¡¯s one option for Geneve we can reuse it because if we can use for example IP over Ethernet as indication of IP payload, then why we cannot use ethernet oam as indication of Geneve oam? I understand that we are not allocating new IP over Geneve ethertype, or are we? 

Tal: Are you suggesting to use channel type 8902?

Greg: No, the channel type is what's in IANA pseudowire ACH registry. So it's a BFD. It's all there. So that's demultiplexing. What I'm suggesting is to use protocol type as Ethernet oam. 

Matthew: My concern is if there is extensibility in future if we do want to run raw CFM over this then what you use for the protocol type?

Greg: but why would we run CFM over Geneve? CFM can be run over service, and then it will be transported as pure data, because if it's end-to-end ethernet oam, that for Geneve it's a data.

Matthew: In theory, but there are use cases where CFM gets run on all sorts of things. So I just question whether or not it's appropriate to use the protocol type fields CFM rather than Geneve OAM or something?

Greg: To run CFM it will require so much additional configuration. So I really don't see the case and why would we do it for layer three. Because we understand that you need to configure maintenance domain name and association, so the complexity of running layer 2 OAM when we can run layer 3 oam on this tunnel segment.

Matthew: The issue is it's confusing to overload a well-recognized codepoint for the protocol type. If you take a wireshark snapshot of the packet, you might expect that if it says CFM in the protocol type you're carrying directly CFM. 

Greg: I need to double check whether it's really interpretation of ethertype. But it's not really a sticking point, so if that's the problem we can ask to allocate another ethertype.
 
Prakash: CFM can go over the tunnel or over any other technology, so it is not exactly layer 2 service oam

Greg: No. But if CFM goes over tunnel, it goes as data not as CFM. So then in this encapsulation, it will be Ethernet. Geneve will see CFM as Ethernet not as CFM.

Prakash: earlier draft¡­

Greg: please send the link, otherwise I cannot answer you. 

Greg: if group thinks that it's confusing we can look for allocation of new ethertype. 

Sam: How do you want the working group to respond you? You have multiple proposals, how exactly you would like working group to actually respond?

Greg: We need to start eliminating some options, saying this is not acceptable at all and so probably we¡¯ll end up with two options. So let's first eliminate two options out of four and once we get two options then we'll have more extended discussion. 

Greg: What I will do is I will send a note and I would expect people to vote because I think that eliminating two options doesn't require a real argument or technical discussion.

Martin: We don¡¯t vote.

Greg: okay, no voting. What I would like to do is to make this decision way before meeting in Singapore.

Matthew: discussion on the list so we can get some consensus on the pros and cons of the different approaches 

Greg: okay. Let's have a discussion. We'll try to measure the level of support, but I would probably do it in two rounds. So the first round is with objective to get to two options, and then in the second round just get one option.

Matthew: Let's see how it goes because we don't have a very good record of coming to consensus on encapsulations or for anything in NVO3. So we may have to go for design team¡­

Greg: Actually then I would ask chairs to decide what the nuclear option will be. Because then you will say if you don't come to consensus, the nuclear option is this.

Matthew: I think the chairs would have to say what the consensus is in the working group or get a design team to come up with a recommendation that we can then get consensus on in working group. 

Greg: okay.

Ignas: Common question. What is the goal of this? What are we trying to achieve here and especially from the actual usability perspective? Greg, you mentioned about CFM and the complexity of that. CFM is a technology stack which is rather well understood in the field. For trying to invent something similar but not the same, that probably would not resonate too well with the community. That's just additional complexity. Can we run CFM over this channel and while we are happily talking about the fields, values, bits and other things, what is the general problem that is being addressed here? What's a deliverable out of that? To provide for different encapsulations and channels to carry oam not necessarily knowing what are the problems, what that OAM solving? Do we have the requirements what is needed for running these types of networks? Do we have a view on the overall manageability of the stacks basically NVO3 tunnel running on some form of underlay? What are the manageability problems? I don't expect an answer from you here. This is basically an open question, but do we have this understanding. 

Greg: Well we don't have it formulated in a document. I would say that at IETF we do have well-developed and longtime deployed and tested oam stack. CFM might not be the best example. I would then use 1731 because 1731 combines fault management and performance monitoring. But we do have a suit of active oam tools that are functionally match to 1731. So I would not say that we are inventing new OAM protocol. 

Matthew: You have a good point here because if back to the OAM protocols that we defined for those channel types or that were identified by those channel types you listed there, a number of them were originally developed in the context of an MPLS transport network, not for data center VPN. So there is a question here of which of those are actually applicable in this sort of an operational environment.

Ignas:  If we look from the field perspective, MPLS OAM is another technology stack which is rather well understood by the community. If we can take and reuse that, that would be definitely a benefit instead of trying to reinvent something new which basically does the same function but in a different way.

Greg: MPLS oam stack and IP oam stack are practically identical. Because it was not developed for MPLS, it was adopted from IP into MPLS, or at least created look alike, for example LSP ping. BFD works the same way as it works in IP network it works over in MPLS LSP tunnels. What we're discussing here is what is the best and simplest way to make available oam toolset work over Geneve tunnel. The goal of this discussion is not to develop new OAM protocol, but how to make existing oam tools to work over Geneve.

Ignas: I'm very happy by the first part of the answer. Please don't invent another oam thing because there are plenty. This is definitely for broader discussion over the broader community. I kind of get the feeling that the group does not necessarily see the clear view of how this can be used, what are the actual requirements. Maybe that would be a good starting point to see what is available and how those things are being used, basically what are the problems in these types of the deployments and how to address those.

Greg: I agree that actually the requirements for oam functions it's a good document to produce, but I don't see that this discussion of how we encapsulate active oam and discussion of what we need to do in active oam, I think they can go concurrently in parallel. Because this is not what we do, this is how we do it. So discuss, decide and then we¡¯ll planning to do look at what extensions we need for echo request reply because continuing on what Ignas said, I do believe that this environment may require certain extensions, especially to probe the particular things. I will send the email starting the discussion, you'll be judging the consensus.

Matthew: In addition to Ignas¡¯ very good points about the requirements, normally which tools you need to use in a given environment probably shouldn't dictate the encapsulation but may be here it might influence say the choice between UDP and an ACH. There's a whole bunch of tools¡­

Greg: I have to bring that back history. Some time ago we had overlay oam design team. Overlay oam design team came up with their requirements, and then I was told that no we don't need this document. So we have a document and at least that we can start working with because it lists requirements, I can bring it up, I can bring it into nvo working group specifically, and then the working group can start looking and say yes that's relevant, no that's not relevant, and that's missing. So would that be a plan to play?

Sam: This is going back and forth, right? We have had this effort within the routing area 
to form the design team¡­

Greg: well, design team worked. It produced a number of documents, and among these documents was pretty generic. I admit there is a list of requirements. We can start it from scratch or we can start it from the existing document.

Sam: I don't have the context of that, but at least my understanding of the outcome was that there was no consensus on what is to be done.

Matthew: take it to the list