Skip to main content

Minutes IETF104: nvo3
minutes-104-nvo3-01

Meeting Minutes Network Virtualization Overlays (nvo3) WG
Date and time 2019-03-28 09:50
Title Minutes IETF104: nvo3
State Active
Other versions plain text
Last updated 2019-04-07

minutes-104-nvo3-01
Network Virtualisation Overlays WG

Thursday Morning session II - 10:50-12:20 ¨C Berlin/Brussels

1. WG Status update
Agenda bashing...milestones, document status

2. Security requirements update
draft-mglt-nvo3-geneve-security-requirements-06
Daniel Migault presenting...

One of the key issue is Geneve & DTLS.
Geneve co-authors seem think DTLS is sufficient and security capabilities for
transit devices are not necessary. Daniel:
 - transit devices make Geneve security mechanism implemented through Geneve
 options - Geneve options are interpreted by transit device or NVE - So transit
 devices prevent e2e security with geneve. - Explainging why DTLS is not
 sufficient for all cases.
Question: Do we need transit device? (use case for transit device¡­)

Matthew: Oam requires transit devices to inspect. Have drafts talking about
trace route. I do not know if you call it a transit devices. In the framework
we don't have transit devices formally defined¡­

David: A need for transit device to insert/remove/modify options or just
visible to transit devices but not be modifiable in route?

Daniel: Only read in current spec

David: If current spec is only read, then with a little bit more design work,
unfortunately DTLS is not exactly what you want, you can arrange to secure the
readable options for integrity e2e without encrypting them and then encrypt
everything else, and at that point you are back to e2e security model, just
some of the stuff that you have integrity protected end-to-end is in the clear.

Daniel: I think that¡¯s something can be done if we need these transit devices.
Maybe we can also agree to have whatever is being read by the transit device,
protect it or not, but that's need to be clearly stated and discussed.

Ilango: You are not characterizing the transit devices accurately and that's
the main contention between what your written in the document versus what the
architecture is supposed in Geneve. Transit devices exist in the network. It
could be the switches or routers, whatever that forwards the traffic between
the two endpoints. We have a formal guidelines so that you're exposing or when
the transit devices are viewing the Geneve headers information, they can use
that information, I gave you a very specific example, could be ECMP purposes
that could be an option that has flow context. If Geneve is secure between the
NVEs then it doesn't have the visibility and if it doesn't have the visibility
it can continue to forward it based upon the outer header information. And
that's how the transit devices today operate in Geneve and even with other
encapsulations. Geneve does not require the transit devices to look at or
observe the options in order to forward the traffic. That's number one, this is
if you are using encryption. If you're not using encryption, as David black
said if you're using data integrity mechanism, then you don't have to do that.
So different deployments may choose to expose this information to the transit
devices or not depending upon what's applicable to that deployment. It doesn't
mean that Geneve is not secure or not secure e2e. So I would suggest that the
author does not miss characterize that Geneve was insecure just because you
want to take we are exposing that to the transit devices. Even if you remove
the transit devices, nothing precludes the transit devices from viewing the
data.

David Black: I don't think I heard a suggestion that was insecure. What I think
I heard was a suggestion that if you want transit devices you need to do
something Geneve specific. What I heard from Ilango was mostly in terms of
exposure not modification which is going to make the problem much simpler. I
also think back to the router, tutorial discussion yesterday afternoon, and I
would suggest that inserting or removing options in route is going to be
painful for high speed hardware. That's clearly avoided, modification would be
bad enough. If it sounds like we don't even need to do that which means that
you've probably got an end-to-end security model. You just have to figure out
how to spec the crypto to get integrity on the stuff that needs to be exposed
to the transit devices. Ilango, I must have said something.

Ilango: You said it correctly David. Transit devices can view the
Data, it cannot modify or it cannot insert the options. The options can be
inserted or in general Geneve header is inserted and removed by the endpoints,
not by the transit devices.

Tom Herbert: That last effectively means that transit devices cannot modify UDP
payload. It's problematic because they don't know if this is actually Geneve,
this could be used for anything. So this should be a must not modify in flight
as far as I'm concerned.

Ilango: We have spec in the document saying they must not modify. Herbert said
is accurate that the specification clearly says that the transit devices must
not modify Geneve headers.

Greg: I think that I understood comment differently, it was not saying that
says, it should say. In connection to yesterday BoF is there was a suggestion
to start data plane consideration especially for new encapsulations and
variable length encapsulations, I think that will be good to take it before it
becomes mandatory and add a section that will highlight impact of Geneve on a
fast path processing.

Daniel: Try to summarize some of the comments. The current spec is saying
clearly that transit device can only read, but the current spec does not make
any recommendation on how to protect the Geneve packets. So if you use the
transit device, following the current recommendation for security mechanisms,
you cannot deploy transit device in a secure way.

Matthew: Wrap up?

Daniel: More characterization is needed on the transit device so that to
clarify this, because they appear clearly like middleboxes so which need
explicit signaling. This has been debated and I think it would be useful to be
done here. Transit device are somehow hardly compatible with UDP encapsulation
because how a transit device will detect it's a Geneve packet¡­ (Continue with
conclusion slide¡­) Feel free to be active on the milling I'm happy to any
feedback.

3. Geneve update
draft-ietf-nvo3-geneve-12
Ilango Ganga presenting remotely...

David Black: TSV reviewer. Thank authors for doing a very productive and
cooperative job of addressing difficult comments on the draft. There are a
couple of issues I would characterize as half open. I want to quickly bring
attention I expect more attention during IETF last call. The first one is that
omitting UDP checksums in ipv6 is an interesting area. To zero the UDP checksum
you want to increase the hamming distance between valid packets as much as you
can. One of the recommend techniques for doing so is to vary the ipv6 source
address. Not clear that this is what running code is prepared to do. And the
other one is that it's a very good idea for an encapsulating NVE to maintain an
MTU value for the tunnel, particularly when that encapsulation NVE is not at
the origination point. The upshot is that if you send a packet into that NVE
from the network and it's too large you get the ICMP response from
encapsulating node rather than getting it downstream somewhere and risking lose
using ICMP payload. Both these I think are very good.

Ilango: Thank you, the working group members can review that those two points.

Matthew: The chairs will probably discuss how to proceed with this because we
still have these ongoing security comments coming from Daniel. He is the only
person who still has concerns on the list. They may be valid and we have to be
aware of those. May be brought up again in the security Directorate review and
review by the security ADs if we progress .We'll get together with the authors
and decide how to proceed. As far as we can see from perspective of calling
consensus from the list discussion, we're probably pretty much there. But
there's still some discussion on security that we have to be aware of. So I can
address that as a part of the Shepherd¡¯s review.

T. Sridhar: I just wanted to highlight the help from multiple folks on making
this a better draft and also we believe draft version 13 will address the
comments for the security considerations as well and clarify the text with
respect to the role of transit devices.

4. 5G-Datacenter Interconnection Use Case
draft-defoy-nvo3-5g-datacenter-interconnection-00
Xavier De Foy presenting...

Remy: I think it is a very interesting usage scenario because I think in this
room most of people are talking about DCN and you are talking about
interconnection of DCs. So in your opinion is there any usage scenarios which
permit us to define for example sub TLVs for Geneve?

Xavier: At this point I don't really know of any impact on in NVO3. That¡¯s
very high level.

Remy: It may be a good thing because people are not very clear about the
definition of TLVs, how to use and what can they do with TLVs. If we find some
interesting scenarios, we can define some TLVs for Geneve. I think it will be
helpful to extend the usage scope of Geneve.

Xavier: Thank you and that's one of the goals of coming here is to find people
interested in the community who would like to bring some expertise in data
centers, and see if they are interested or not...

Greg: In 5G we learn that they're considering three use cases. It's ultra
reliable low latency, extended mobile broadband and extensive machine to
machine communication. Do you see that for all these three scenarios, one
solution will be suitable?

Xavier: Actually I hope that not. A lot of work being done in 5g to support
edge computing as you know probably and that was a new study starting to
enhance the support for edge computing. So I think that right now 5G does not
really mandate any specific thing outside of 5G in terms of data centers. It
provides some mechanism to enable interconnection with external data networks.
So personally I don't think there is one solution that will be mandatory.

Greg: A little bit different angle. So where would you suggest to look for
requirements for these use cases or scenarios? I think that ultra reliable low
latency especially, since you mentioned multi-access edge computing to minimize
round-trip delay, might have some distinct set of requirements comparing to
enhance mobile broadband. Would you suggest any source of requirements?

Xavier: You may have an answer from somebody behind you.

Ulises: I think that one of the reasons why we think it is interesting here and
have the feedback from the community is that we're also looking at the 5GLAN
feature that is going to be developed in 3GPP. Based on the requirements I've
seen there, the case of the reliable communication in particular the use of
5GLAN like systems for industrial IOT, I think that  will be the use case that
from my perspective will be the modules for this type of 5GLAN cases. That
would be my input to your question.

Yizhou: I want to bring your attention to what we have already done in NVO3
working group called the split NVE or external NVE. Your NVE which is an
external device from the end device is a bit different from our current case
because we are more focusing on the wired part so there is a VLAN mapping
between the so called VNI and VLAN ID. I'm probably want to consider for the
5GLAN case what kind of mapping information from the PTU session since you
don't have VNI information there. That's one possibility that's how NVO3 can
help in your scenario.

Xavier: Thank you, maybe we can talk shortly after session.

Matthew: Who has read the draft? (not many) Those have read the draft, who
thinks this is in scope of NVO3 first of all? As our Charter is very much
focused around kind of traditional fixed data centers in one geographical site,
not DC interconnection, but inside of a physical data center. And a distributed
data center architecture like this is perhaps a little bit new.

Xavier: Will you advise on whether we should continue this work right now?

Matthew: I'd suggest that you need to get some more feedback on the list and
you get some more people to read the draft. I think there is kind of scoping
issue and charter issue, will talk that to AD.

5. Base YANG Data Model for NVO3 Protocols
draft-zhang-nvo3-yang-cfg-05
Remy presenting...

Matthew: General comment from me I think it needs to be very clear on the
scope. Because we've got another young model draft coming up next. To be very
clear on the scope of the individual YANG models that one is generic to the
overall architecture and the other one is specific to configure the parameters
of a particular encapsulations right?

Remy: Yes

6. YANG Data Model for NVO3 Protocol
draft-chen-nvo3-yang-00
Ran presenting...

Remy: I have a couple of comments. First of all just to make sure that this
YANG just cover Geneve and VXLAN-GPE right? Ran: Yes

Remy: So the second question is what is the mapping relationship between this
YANG model and NVO3 architecture? Because here I can't see the terminology that
I've been familiar with. For example I can not see the NVE here. Ran: We will
update later.

Remy: NVO3 instance and NVE, what's mapping relationship? Not obvious
Ran: will update

Remy: have NVE first, then... do not get the point from your model
Ran: I am defining in a different way from your draft

Some arguments between Ran & Remy on the mapping and sequences of some
particular parameters.

Ignas (OPS AD): I do care about manageability. Have a slightly broader
discussion because what I see happening here is talk about tiny fragments but
I'm not certain whether the working group has the broader view or the
manageability.

Matthew: We did have an operational requirements draft a long long time ago. We
don't have any really active doc. We don't have really any draft apart
framework at the moment on overall what you need to manage in an nvo3 network.

Ignas: So the problematic aspect that I would see is, first an NVO interface is
an interface, it's not a special type of interface. Therefore from a
manageability point, it should be put into the hierarchy as any other interface
and have its own parameters. The transport protocols below 2e2 client protocols
should be aligned with the overall manageability of other transport e2e client
protocols. NVO3 is no special if I want to try to use that for practical
purposes in a practical network. If it is radically different than IP or MPLS
encapsulated interface, something is just not right. Another aspect and that's
probably broader, what probably needs to be done is to revisit the use cases
draft, and try to talk to the user community, what problems they are trying to
solve and how they are trying to do that, and this will come as a set of
requirements how that should be managed. The fact that you have a YANG model,
it's good, but that is nowhere near enough. It's just a tool but it needs to
fit into the overall management hierarchy somehow.

7. BFD for Geneve
draft-xiao-bfd-geneve-00
Xiao Min presenting

Matthew: The question is do we need to separate modes for encapsulation of BFD
in here? Can we just rely on the fact that IP UDP packet or do we need
effectively a unique protocol type for BFD in the Geneve header? This kind of
precedent for this in MPLS and past, for example you can either run BFD on IP
UDP or you can explicitly identify in the G-ACh that you're carrying BFD. But
that was really for MPLS TP where you did not rely on IP forwarding. I think in
the case of Geneve it's an IP underlay. So do we actually have a need for this
to uniquely distinguish BFD? Any feedback on this? Has anybody read this draft
yet?

Greg: Co-author. It's a question for the working group and in my opinion it's a
broader scope question of oam in NVO3 and Geneve. Because how do we encapsulate
BFD in this case is a question for this draft and in general how to demultiplex
active OAM protocols in NVO protocols, in Geneve in particular. So I think that
since Geneve specification is stable and ready to be passed to IESG, I think
that we're at a time where we can start looking at question.

Matthew: yeah, feedback?

Sami: I do have some basic question first and maybe we can provide feedback
about whether we should include an IP header. When you are running BFD here,
are you testing the connectivity of the tunnel or VNI service?

Ming: Tunnel.

Sami: So what would be the VNI value?

Greg: As being mentioned in the document presentation, there is a lot of
similarity with the BFD for VXLAN. You probably know that BFD for VXLAN is
waiting for AD review, so it passed BFD working group last call and will follow
similar interpretation of VNI in this specification and it is the VXLAN. But
obviously if you have some suggestions, welcome.

Sami: Sure. I think the other comment is that when we did BFD for mpls-tp and
didn't include an IP header, it was mainly because we didn't have an IP network
on which we could be running BFD on. But I think the case here is different. We
already have an IP network.

Greg: The reason to question whether to include IP header because it's extra
header and the only purpose of this header is UDP port to demultiplex the
payload. Think of our ipv6 addressing what unnecessary overhead we're
inflicting just to carry our UDP port, so that's why we're suggesting to
consider use of ACH. BFD is supposed to be right weight. If we add ipv6 IP UDP
headers on top, like 40 bytes of BFD, so the header is larger than BFD, right?
The overhead is like hundred and twenty percent. So I think that it's a good
enough reason to at least to consider it.

Sami: I think the same comment applies that the associated channel was added
because you are running on a non-IP network. I understand overhead well¡­.

Greg: Associated channel was not only added because MPLS-TP. Associated channel
is just generalization of pseudowire VCCV. So it's basically taking the clue
from technology already existed. Because basically the same mode is run over
pseudowires. There was no IP encapsulation needed for the pseudowire BFD.

Sami: layer 2 only and not layer 3.  Meaning an associated channel was added
for pseudowires VCCV because pseudowire would carry layer 2 traffic that could
carry IP or non IP. But here the cases are we already have an IP network. If
you are worried about overhead, anyway Geneve header is an overhead.

Ming: Sami, when you say IP network you mean underlay network?

Sami: Correct. I think when VCCV was added or associated channel was added, for
pseudowire we are carrying only layer 2. L2 does not need to carry only layer 3
and it can carry other protocols, others an IP. This is why you need to have
BFD running with associated channel because the network may not have IP and so
on, right? But in here you have an underlay which is IP¡­

Ming: for the overlay, maybe no IP¡­

Sami: What you're saying is that I'm carrying a layer 2 overlay and now is that
layer 2 overlay may not be an IP overlay, then I should have an protocol for
BFD similar to the associated channel so I can run BFD on it as a control
message only. I think okay, I can buy that argument.

Tom Herbert: I'm looking at the Geneve header, there's a control bit or O bit
that says control packet. In this scenario what would that be set to? Is this a
control packet?

Greg: It's great question thank you. We don't know.

Tom: So let's assume that we do set the control bit. Then my question becomes,
the protocol type field, what does that mean when the control bit is set?

Greg: Another great question thank you.

Tom: Third part is, this is answered in GUE. If the control bit is set in GUE,
that protocol type field is now a control type field, it's a completely
different numbering space. So what I'm concerned about here is do you really
want to add an ethertype for control messages? It seems like a slippery slope
so you might want to consider something like.

Greg: Point to what has been done in SFC NSH. It does have O bit which in 
RFC8300 was defined as identifying oam packet. There is draft IETF-SFC
multi-layer-oam which we name as SFC active oam draft. We have defined with the
working group together how O bit with their protocol field identify
combinations of OAM whether in header extensions. Because they can have an NSH
fixed length extension or variable length extension header and oam in the
payload. So it defines the situation that oam information data or commands are
in a header part or in the payload part or there is no oam at all. Actually
there was a discussion in Bangkok and Adrian provided case that led us to a
point to situation that has to be interpreted as erroneous situation that O Bit
is not set but next protocol field is oam so that has to be interpreted as
erroneous. I will encourage you to look at this. I know what GUE is doing. I'm
not completely agree with that because there was not all OAM goes to the
control plane, in particular BFD things are done usually in the hardware. So
thus changing two name spaces might be unnecessary burden on the hardware
support implementation. But I'm open to discuss it.

Tom: You made an important point there are two flavors of this. One is the
payload is the control packet and two we want to attach control information. So
it's not about OAM, it's about how do you deal with these two flavors. I have
arbitrary control information to attach or I have specific... in this case it
looks like the payload is the control data, which means...

Greg: no¡­this payload is what's supposed to be processed in the hardware¡­

Tom: so is the payload contain an IP packet

Greg: that's another thing that we just discussed..

Tom: What I mean is it being attached to a user IP packet?

Greg: No

Tom: Then I consider that a control packet. I'm not concerned about hardware
versus not Hardware. On the wire what does this packet look like? If I say this
is protocol type 800 and that those bits are some kind of control information,
that's not ipv6. So the protocol type and the control bit and the payload have
to work together, so that's unambiguous what the Geneve payload contains, and
since we know the transit devices are going to try to parse this, it has to be
on ambiguous for them not just the endpoints.

Sami: One last comment is if you are talking about ACH here and so on, did you
consider putting an MPLS label like GAL label and saying this is an MPLS
packet? Why not? They are using the same approach. Is the way we did it in
MPLS-TP is that you put a GAL label¡­

David: We need to talk about why we're doing BFD in the first place. What is
the thing on the far side whose liveness and ability to talk to us we'd like to
establish. And I believe what we're going after here is the chunk of the NVE
that knows how to decap Geneve. So the hardware is being referred to is the
hardware that chews on the Geneve header. ¡­¡­because what essentially it says
is the hardware chews on the Geneve header something in there says this is BFD
and the BFD payload comes next, and now you have BFD solving the problem you
want to solve, is the NVE capable chewing on Geneve or did something break
before it opened up that header?

Sami: I didn't get it. So you want BFD or you donot want BFD?

David: I want the BFD header to be as close to the thing whose liveness I'm
testing. The more headers you add in the middle, the more ways there are to
break BFD without breaking the forwarding engine. The further away I move BFD
from the chunk of hardware's liveness I care about, the more opportunities are
for BFD and the hardware to not to tell me the same thing.

Sami: GAL is only four bytes

David: find some way to code in the Geneve header this is BFD then the hardware
process of Geneve header grabs that BFD and says yes I'm here

Greg: That's possible just to use a next protocol, allocate BFD next protocol
and be done with it.

Sami: It's already defined ACH having being used for non IP header and you want
to use an ACH approach, so I didn't understand the argument why not use the ACH
approach as its defined already.

Greg: I think that what we can agree on that this is a separate topic for
discussion because it's broader than just BFD.

Matthew: yeah, to conclude, we need to describe comprehensively how the O bit
is used and how that should be interpreted in Geneve. In other technologies
like pseudowire, you define an exception mechanism whether that 0001b on a
header or ¡­ my interpretation of the O bit here is it's an exceptional
mechanism that says this is a control channel message, and no more than that.
But what the structure of that control channel is, whether it's something with
an ACH, whether it's an IP channel, is undefined at the moment.