Skip to main content

Minutes IETF105: nvo3
minutes-105-nvo3-00

Meeting Minutes Network Virtualization Overlays (nvo3) WG
Title Minutes IETF105: nvo3
State Active
Other versions plain text
Last updated 2019-07-30

minutes-105-nvo3-00
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