Minutes IETF102: nvo3
minutes-102-nvo3-00

IETF102 NVO3 WG agenda

Network Virtualization Overlays WG

Wednesday Afternoon session I - 13:30-15:00 - Viger

Chari: Matthew Bocci
Secretary and minute taker: Li Yizhou

Matthew: Note well applies.

1. WG status update.ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊWG Chairs, 10 min

Agenda Bashing.

Milestones: dropped control plane requirement and solution milestones due to
lack of progress and may move some of them back. Added security requirement and
solutions milestones. 6 RFCs including 1 new RFC since from last IETF. Document
status: new revision of Geneve. Security discussion today. Hopefully LC after
IETF meeting.Ê Security requirement document, a lot of discussions, no
sufficient consensus to adopt it yet.Ê Hopefully run another adoption poll with
the latest revision Daniel is going to talk about. EVPN applicability draft
currently under adoption call. Read draft. vmm draft. Started WG LC, not
closed. A particular review from TCPM. Can author come to the mic and let us
know their plan? Behcet Sarikaya: can address the comments next week.Ê Matthew
Bocci: please read the draft. Will try another WG LC after OPS area review
comments has been addressed and probably a review of TCPM.

Next IETF and IEEE meetings are back to back. A proposal for a potential joint
IETF and IEEE 802 workshop on data center technologies in Bangkok.Ê

Paul Congdon: IEEE 802 plenary meeting is immediately following the IETF
meeting in Bangkok at the same hotel and so we wanted to try to take advantage
of that opportunity to see if we could get together some of the thought leaders
around data center technologies. IEEE 802 just recently approved a project
around congestion management and it's intended to work with higher layer
congestion management in the IETF as well. So we think that there would be some
fruitful discussions in that area. There's also some strong interest in the
IEEE where of course all the switch vendors are and ASIC vendors around. How we
how we interconnect other data center technologies such as the overlay networks
as well, so the interplay between layer 2 and layer 3 and would be a great
opportunity to have such discussions. Again, congestion being one of the
interesting areas, a lot of the new proposals here in the IETF are using option
fields in the TCP header which would be inside the encapsulation. So it's not
clear how the fabric switches themselves would be able to see or do anything
about that so that would be interesting to know how we can communicate
indications of congestion and things like this to the edges of the network as
well in order to take appropriate action. So the proposal is that this would
take place on a Saturday immediately after the IETF, the IEEE has indicated
they have room space available so there would be no additional meeting fees or
anything like that.ÊBut the agenda is not fully set yet, it would probably be
announced to by the IAB or something in the IETF. Any questions about that?
Matthew Bocci: ok so I'll also post something to the NVO3 list about this. I
guess you're looking for feedback on potential topics that people would be
interested in. Paul: Correct we're looking for feedback on topics as I
mentioned the kind of current thoughts as it would be around congestion
management but we're open to other topics as well. Matthew Bocci: That brings
us on to our session presentations. The Geneva security requirements draft.

2.draft-mglt-nvo3-geneve-security-requirements-03ÊÊÊÊÊ Daniel Migault, 10
minÊÊÊÊÊÊÊ Daniel: presenting...

Ilango Ganga:ÊWe have had the extensive discussions with the security
requirements authors. But I just wanted to point out that the transit nodes was
as an important point where the security requirement document made certain
assumptions that is not supported by NVE architecture. There are several
requirements that are associated with this. We have given detailed feedback to
them saying that these are unsupported and we shouldn't have those
requirements. That's number one.ÊThe second one is regarding the optimization
versus requirement. We discussed that one as well. There are two things. One is
multiple flows. We don't believe that multiple flows is more of a nice-to-have
and is an optimization and it is not an absolute requirement to secure the
communication between the two NVE pairs. That's one point and the second one is
on whether the tenant can encrypt the data or whether the tenant encrypts the
data or not if an operator deems necessary that the communication between the
NVE pairs needs to be encrypted and they will encrypt it that is irrespective
of what happens here with the payload. So we believe that's also an
optimization and not a requirement. We have submitted detailed comments to the
authors of the requirements and that's not been addressed in the current
version. So with that my opinion is it is still not ready for adoption. We
still need to fix the architectural issues as well as some of these
optimization requirements before it's ready for adoption.

Matthew Bocci: You're planning on doing a new versionÊof draft right?
ÊÊ
Daniel: We're working on the new version.ÊÊ The assumption we had before were
reallyÊbad. So it's more to see the direction where we have to go. To
me,Êoptimization can be discussed. Multiplexing is not a big thing. The
transitÊnode issue seems to me more drastic because as Ilango mentioned a lot
of theÊrequirements were coming from these. So if there is actually no transit
nodesÊas the way we understood, those requirements are going to be
completelyÊdifferent. And even the analysis. If we kind of fix on that, it's
easier to have a more stable version. ÊÊ Matthew Bocci: Given that this was
going throughÊan adoption call, it would be good to have more discussion on the
list aboutÊ it rather than in private. Maybe form a formal design team around
this. If Geneve could try to have more of the discussions on the list if
possible that would be good.Ê

3.draft-ietf-nvo3-geneve-07.txtÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ Ilango Ganga
(remote), 10 minÊÊ Ilango: presenting remotely...

Tal Mizrahi (Marvell): The one before last bullet says options or the ordering
must not be changed by transit devices. Actually the sentence says two
different things. First of all I would suggest to split it into two sentences.
One talks about the ordering and one talks about changing or not changing the
option. Regarding changing the option, you mentioned IOM, so maybe I miss what
you said, but how does this work with IOM if you can't change the option? What
are the transit devices supposed to do in terms of IOM? Ilango: The datagram
has the meaning only at the endpoints. If you look at RFC7605, that makes it
very clear that the port number association is also established by the
endpoints. So even though the transit devices may be able to interpret, that
doesn't guarantee any security that the association will always be on this port
number. It's the same thing with Geneve. You don't want it to be able to go and
change the content of the packet. That would cause security with respect to
what the communication that is going on between the endpoints. This is like you
are establishing a tunnel between an end point to an end point, and end points
are the ones that are establishing the tunnels and maintaining it. You don't
want the contents of that tunnel to be modified by the intermediate devices.
That was not an intent of Geneve architecture and we just wanted to make it
clear. Tal: So just to make sure I understand we're saying that we're not going
to support IOM and transit devices? Ilango: If you're going to modify the
packet, then what it means is that's an endpoints responsibility. Then you need
to be implementing an endpoint in order to make changes to the packet. Daniel:
Transit nodes cannot insert, delete. Only thing can do is read an option?
Ilango: That's correct.

Ilango: continue with the presentation on "security considerations section"...
Tal: I completely agree with this slide. But how does slide 5 work with the
fact that the confidentiality, integrity and authentication are must
requirements. I mean if we need to do a threat analysis, and based on that
threat analysis we need to decide which requirements are applicable and which
ones are not, why are we requiring as a must to implement confidentiality,
integrity and authentication? Ilango:Ê It's a must in that particular scenario.
It is not a must all the time. For example let's say in a multi-tenancy data
center, the requirement is to protect the data between two NVE pairs and that's
a requirement. In that case the data center operator must enable it in order to
protect the data. If you go and read through the BCP 72 guideline, it is very
clear that we need to identify the threat and also we need to clearly specify
what is a must and what is a should or what is a must not. That needs to be
very clearly explained. If you go back to look at RFC 8300, that recently went
through this process. It was very clear that we have to provide such
requirements. That's exactly what we try to follow in updating the security
consideration section here. Tal: So the way I'm reading the current version of
the draft, maybe I'm not reading it right, is that you must implement
confidentiality, you must implement integrity, and you must implement
authentication. Ilango: We can add qualifying statement that's what I said in
the next page. It's possible to add qualifying statement to make sure that it
is applicable only in such scenario, provided the operator has done or there is
a risk assessment and based on that they intend to enable it. Tal: I think we
have to rephrase it because right now it says something which is very difficult
to follow. I think if we're saying you must implement confidentiality, and
we're not defining an encryption algorithm and we're not defining a protocol.
First of all no one will implement it, second of all there is no way to
interoperate. So it won't work. I would suggest to be very careful about using
the word must in capital letters. Suggest to remove it or to phrase it very
carefully in a way that will be clear that we're not actually expecting people
to implement it as a must, but only to use it in certain scenarios. Ilango: I
think we still have to include the must statements in there because we need to
clearly specify that. You can also refer back to the recently completed RFC
process. I also monitored some of the exchanges that went through during that
draft review process. We will have to clearly specify the risk and we'll also
clearly specify what those requirements are. But it is possible for us to add
qualifying statements in such a way that requirement is not applicable to all
scenarios. It's only required in a specific scenario where that threat is
deemed necessary by that operator. Matthew Bocci: Try to clarify Tal's
comments: There's no point in having a must if you don't have a mechanism to
back up that must right now. It's quite common in security considerations to
give examples of protocols that can satisfy that requirement. So if there's
specific protocols that you have in mind to provide these, then you can just
lift those as examples. Rather than leaving it completely open-ended. Tal: The
way we read the text right now is it says as an instruction to the implementer.
You must implement these things. And as an implementer I'm reading this and I'm
saying I can't comply to Geneve because I can't implement confidentiality and I
don't know what to implement. So we can't leave it like this. Matthew Bocci:
There are other ways to phrase it. Perhaps less prescriptive but satisfy that
the kind of purpose of the security considerations section. Speaking as a
co-author of other RFCs, from what we have done, you have to start the state
what the threat is, and then say there are mechanisms available. Enlist some
mechanisms to mitigate against that threat. Tal: Just as a suggestion what we
did for example in the tic-tock. We had security requirements so what we did
was we define the security requirements for a security mechanism. That is if
you're implementing a security mechanism in a system that requires this
mechanism based on threat analysis, these are the requirements, some of them
are must and some of them are should and so on. But that's if you're
implementing the mechanism. So it's not a must to the implementer. It's a must
to whoever is using or deploying security mechanism. That's what I suggest to
do here. Ilango: Point well-taken. We'll try to maybe rephrase it in such a way
that it is very clear what we intend to do here. Matthew Bocci: I think one of
the things that we intend to do with this document is once we see a new version
of it, we will start WG last call to this, and ask for a security area review.
So what I suggest you do is to write down what makes sense for an implementer
of Geneve here, because this is supposed to be specifying the Geneva Protocol.
And hopefully we can get some advice back from the security area or some
guidance on whether or not what is written in there is adequate. Somehow we
have to come to a compromise here as to what makes sense for a protocol spec
while having sufficient text in there to also guide the fact that if you need
to meet these security requirements in certain deployments, obviously you must
implement these other mechanisms. Ilango: Shall we send the draft to ask for
security review or after we make rephrase of some of these sentences and then
send it for a security review? Matthew Bocci: First rephrase it in a way that
makes sense for an implementer. It sounds like we don't yet have consensus on
the current text. So let's get some consensus in this working group first and
then send it for wider review. Ilango: All right. Daniel: I think it's a good
path to go through. Because having strong security requirements that are not
implementable I don't think is going to be helpful for the review Daniel: What
is the timeline to submit it for security area review or IESG? Matthew Bocci:
Let's get some consensus. If you could maybe work with Tal and the authors to
propose some text for this section, try to get consensus on the NVO3 list
first, so in the next couple of weeks. It's only a couple of sentences. Then we
will revise the draft and go for a security area review first and then a
working group last call based on any feedback from that. So I definitely like
to get this sent to Martin before Bangkok.

4.draft-fmm-nvo3-pm-alt-mark-02ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ Guiseppe Fioccola, 10 min
Tal presenting....
Daniel: Clarifying question. The marking and the reading of the marking being
performed at the NVE or any node in the network?Ê Tal: At NVE. The idea is that
the NVEs are assigning that marking bit and the terminating NVEs are using that
marking bit. Ilango: Follow-up to Daniel's question. So basically what you're
saying is the NVE is the one that is marking this bit and NVE is the one that's
consuming this bit as well. Tal: Yes Matthew Bocci: Hands up if you have read
this draft. About Three?Ê Ilango: If that is the case then why won't they use
the options in order to do this because that was the intent of having
extensibility rather than using the base header? You can have the option to
indicate this information and you're not limited by in the number of bits. A
lot more space in order to do it or provide metadata between the NVEs.Ê Tal:
Right, you can use the options. But the idea is that since this approach only
requires a single bit or two bits, very small number of bits, it's a bit of a
waste to use an option for this. If we can spare a bit for or two for this in
the Geneva header, we can just be more efficient and still get that
functionality. Ilango: I believe that this is exactly the reason why we have
extensibility and also not all the deployments will need this. So it will be
better to have an option. And then you are not limited by one or two bits. If
you want one or two bit that's fine but if you want to use more, that allows
you use the extensibility feature of Geneve in order to do this. That's my
opinion. Greg Mirsky: So strictly speaking there is no consumption of the
marking field. And I probably have a different opinion from TalÕs that
effectively the test point that acts on the value of the marking field can be
anywhere in the tunnel. It's not necessarily the edge NVE. The benefit of using
fixed position of the marking field is that simplification of the operation of
the test point. Because then it makes its well-known position in a packet
rather than you need to parse their variable length portion of the header to
identify where the field is. Ilango: Is that a question to Tal? Greg Mirsky:
No, it's my answer to your suggestion to use a variable length extensible part
of the header for the marketing field because that will make it hardware
support of it less efficient. Again I want to point that this method is even
though it's classified as a hybrid method similar to other hybrid methods, it
does not transport data in a packet. The data being calculated locally at the
test point and then can be exported out of band. So which makes it even more
efficient because you don't need to transport each and every timestamp of the
marked packet.Ê Ilango: I still believe that you can use the options for this
purpose. Because most of the Geneva endpoints that are implementing will also
be able to implement options. The efficiency is not an issue. So I don't
believe that efficiency is an issue whether you're interpreting an option or
whether you are interpreting bits in an option. Greg Mirsky: I agree with you
everything can be done differently there is not one way to slice the bread. But
in terms of performance monitoring, being able to identify the packet as close
as possible when it's being received, it's almost critical. Because if for
example the timestamp is not taken during the physical reception of the packet,
then you are measuring something else. Basically you are measuring internal
queuing delays and internal processing rather than propagation delay. That
becomes a variable so their quality accuracy of measurements suffers. We can
discuss it at length but I want to assure you that it is important. Matthew
Bocci: Greg, I think I had similar comments. If you're adding options in a
performance monitoring, you're making the packets bigger. You don't want the
fact that you've added these additional option fields or headers to impact your
OAM measurements which are supposed to represent the user traffic behavior.
Greg Mirsky: The alternate marking method works on the user traffic. And the
idea of using pre-allocated field in a fixed size header or at least fixed size
portion of the header makes it almost as best measurement because there is no
increase in the size. As Tal pointed out the size of the flag is so small, so
adding option will be significant overhead to the actual size of their marking
field. Matthew Bocci: Right, we're saying the same thing.

5.draft-mirsky-rtgwg-oam-identify-00ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ Greg Mirsky, 10 min
Greg presenting...
Matthew Bocci: I guess one of the questions really is where to discuss the
draft if it should be on the routing. Is it only specific to the NVO3 or within
the context of the routing area working group?Ê Greg: Jeff asked that because
he was aware that I'll have presentations at NVO3 and then SFC. So he asked to
summarize their discussion. I think that again if somebody wants to have it in
one group. But the discussion should include all these groups. And actually I
think that because there is consideration for GUE. We need to involve the group
that works on GUE as well to make them aware of our discussion and our
arguments. Martin: According to you, what is the set of competencies needed for
that document? Is it NVO3? Greg: I definitely wanted to have impact on SFC. I
want them to think about it and to discuss it. Matthew Bocci: So given that the
document is about surveys on the mechanisms that are in place at the moment,
and the various OAM and the various overlay encapsulations, and that some of
those encapsulations are quite well advanced, and of those implementations of
them, what do you see the value of the document? Do you see that if the
document is going to change encapsulations or are you hoping to change
encapsulation existed today?Ê Greg: No. I try to make my recommendation as
least intrusive as possible. For example we have probably the most advanced
would be SFC NSH. For an SFC NSH, we haven't made much progress on OAM
framework and it is still being worked on. We may redefine the interpretation
of O bit in an NSH header and we just then define the value for next protocol
to identify active OAM. So I don't think that would be a very big change and I
would see it as being backward compatible. But it's worth discussion because
people might have some ideas. Matthew Bocci: If I could encourage folks in this
working group to read the draft and probably provide feedback on the routing
area from an NVO3 perspective, I think that would be the way to do it.