Skip to main content

Minutes IETF108: nvo3
minutes-108-nvo3-01

Meeting Minutes Network Virtualization Overlays (nvo3) WG
Title Minutes IETF108: nvo3
State Active
Other versions plain text
Last updated 2020-08-05

minutes-108-nvo3-01
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.