Skip to main content

Minutes IETF98: nvo3
minutes-98-nvo3-00

Meeting Minutes Network Virtualization Overlays (nvo3) WG
Date and time 2017-03-28 19:50
Title Minutes IETF98: nvo3
State Active
Other versions plain text
Last updated 2017-05-01

minutes-98-nvo3-00
IETF98 NVO3 WG agenda

Overall format of NVO3 WG meeting will continue with roundtable discussions
experiment started in Seoul. Session 1 will have WG status update and
discussion of a few drafts, then the audience is asked to pick a roundtable of
their choice and participate in the focused discussions there. Session 2 will
focus on providing the results of roundtable discussions to the rest of the
working group.

Session 1 (1.5 hours)
TUESDAY, March 28, 2017
1450-1620  Afternoon Session II
Vevey 1/2               RTG         nvo3                Network Virtualization
Overlays WG

1. Administrativia. 5 min. WG Chairs.
Matthew Bocci: Meeting starting. Note well applies. Sam is not at Chicago
meeting.

2. WG status update. 5 min. WG Chairs.
Matthew giving overview of WG status.

There was a virtual interim meeting held earlier, focused entirely on the
encapsulation document.

One new RFC since last meeting.

Tom Herbert: We have a DT draft that needs to get an adoption. It seems that we
are assuming that Geneve is an answer. Will there be a separate adoption call
for the design team draft? Matthew: The direction of the design team is in the
Geneve direction, and Geneve is already a WG document.

3. Data Plane Design Team and draft-geneve update. 10 min. Sami Boutros
draft-dt-nvo3-encap-01

Sami Boutros presenting on Encapsulation DT recommendations.
Greg Mirsky: Let’s overcome the term “Inband OAM”. Inband OAM is packet sharing
the same path as data packet. Inband OAM is what is being proposed as hybrid
type 1 where we mix some telemetry and probe information with the flow.
Underlay can send the OAM packet in a different way compared to the original
packet. In the inband OAM there is congruency of OAM and data packets. Sami
Boutros: You have mentioned that previously, we are aware and the slides do not
reflect the terminology yet. Greg: We would like to address this during the
roundtable.

draft-ietf-nvo3-geneve-04
Ilango Ganga presenting on Geneve.

Tom Herbert: I think this was in response to the comments on sequential
processing of TLVs. I am also worried on the denial of service. On paper this
seems to be working, wonder how well this could work in reality. Suppose you
have two implementations that cannot agree on the order of the options,
therefore we do not have interoperability. We need a better example of how
ordering of TLVs works. Or use natural ordering of the TLVs, for hardware
builders specifying the ordering of the TLVs seems to be of value. Ilango: It
is hard to specify all options in advance as they will be evolving, new ones
may appear in future and you need to accommodate those. Tom Herbert: Order of
processing is not the same as order in the packet. If I have a security option,
I know that I need to process it first. Pat Thaler: Even if you have a strict
order, you still need to parse the TLVs to find the length. There may be TLVs
that are of interest for the transit nodes, others will be of interest to the
end nodes, and that requires different processing. If you put a new one that is
of interest to the transit nodes you may want to put it in the beginning of the
list as that it is easier to process for the transit node. You need to look at
the ordering on how you use them. David Mozes: I agree with that statement.

4. VXLAN extensions for signaling between CP and UP of vBRAS, 5 min. Lu Huang
draft-huang-nvo3-vxlan-extension-for-vbras-00
Lu Huang presenting.

Tom Herbert: If you go back through NVO3 archives you will see multiple
instances of extending VXLAN in various ways. And the conclusion every time was
that it is not good for backwards compatibility. You might better go with GPE
or NSH metadata. Matthew Bocci: It might be good to discuss with SFC WG to see
whether using NSH based approach would be a better option. Matthew: Show of
hands who has read the draft? Less than 10 people.

5. Overlay OAM, 5 min. Greg Mirsky
draft-ooamdt-rtgwg-ooam-header
draft-ooamdt-rtgwg-demand-cc-cv
Matthew: Skipping due to the lack of time. Will have an adoption call on the
list for both of those drafts.

6. Moving to roundtables, topics, and expectations. 5 min. WG chairs and topic
leaders. Matthew explaining logistics of the roundtables.

7. Roundtable discussions. 50 min.

=====

Session 2 (1 hour)
THURSDAY, March 30, 2017
1740-1840  Afternoon Session III
Zurich E/F              RTG         nvo3                Network Virtualization
Overlays WG

Matthew Bocci: Meeting starting. Note well applies.

1. Administrativia. 5 min. WG Chairs.

Matthew: Today we have reports for the roundtable sessions held on Tuesday.

2. Roundtable presentations. 45 min. Roundtable topic leaders.

Data plane roundtable.
Sami Boutros presenting on behalf of data plane group.
Greg Mirsky: I have missed to ask for one more aspect on OAM - it is an
alternative marking method. It can enable us passive performance measurement on
a packet flow. It uses 1 or 2 bits in the header, we have a proposal in BIER
WG, that document can explain how to do that, It would be good to have 2 bits
in the NVO3 header. We can do the measurement of packet loss, delay, and
jitter. The work is done in the IPPM WG, the base document is getting closer to
the LC. There is one document that demonstrates how that can be done in the
BIER overlay. Tal Mizrahi: That is a good point. If we can repurpose the O bit
that would be good. Sami Boutros: Please send any references, we will consider
in the next revision. Ilango Ganga: A common OAM bit - one of the reasons for
the hardware that does not parse the options, it is helpful to have that
indicator rather than putting it along the data. Greg Mirsky: Having OAM bit
and the protocol field creates ambiguity. I am not saying that we need to
remove the OAM bit, but let’s give an unambiguous definition what an OAM packet
is. Ilango: We define a new protocol for OAM, define a new ethertype, and then
bring it here. That protocol needs to have a provisioning for the next protocol
field and that adds additional complexity. Greg: I have sacrificed my 10
minutes in the first meeting for the sake of community. The slides in the
materials have exactly same details there. David Mozes: Your answer is the
problem. If you add an ethertype this is solved. Greg: Let’s use the clear
terminology first. Data path has its own protocol id. If we are using hybrid
OAM. Dave Mozes: This is a problem because we cannot skip options with the
length. Greg: OAM header has length that has a length of OAM message. David:
What is the length of the packet then? Greg: That will be described by the NVO3
packet header. Erik Nordmark: If you look at the different formats, OAM may be
a pure OAM packet that has an OAM protocol type, instead of payload being IP it
is OAM. Another option that packet may not have any special payload but just
the OAM bit set. It has attached the OAM information that is flowing through
the network. What design team discussed was on potentially using extensions for
carrying that indication. The other option is putting regular OAM payload that
is followed by the regular payload. Greg: The bits that I mentioned - they go
on to the clear packet. David: The reason for choosing Geneve vs GUE was based
on middlebox awareness. If you do not parse the option you skip. If we take a
bit, it needs to be parsed. Greg: One of the things why it is proposed this way
is that we have BIER that uses it this way, and we tried to create common OAM
for multiple overlays. Bits in the header are used as a mark. That is the
reason why we have OAM header. It creates associated channel. You have multiple
OAM functions and you need the way to identify them. George Swallow: Comment
for clarification - bits in the header are for a common use. That seems to be a
simple mechanism to take this or that action. Pat Thaler: We should use the
inbuilt mechanism and not use the extension header. Sami: We will discuss all
of that as DT progresses. Erik: If you want to take a look into the payload,
the way to skip past that is the same whether you use one or other mechanism.
Sami: We should not create a difference here. Tal: Seems that there are two
separate questions. Do you want to have OAM in a shim or separate header, and
whether you need an OAM bit. Matthew Bocci: Is the plan to update the DT draft?
Sami: Yes. We will update and bring to the list.

Control plane roundtable.
Benson presenting on behalf of control plane group.
Alia Atlas: Please do review the IEEE VDP document. We asked IEEE to please
extend this protocol, we need to review it otherwise it will be more difficult
to ask in the future to extend protocols. Do we need it at all if we do not
review it? Pat: We would like people to read the whole document, but if you
have a limited time, the most of the feedback would be appreciated on whether
we have included the right data in the extensions of the TLVs. That document is
only a few pages. You can either email us our comments or send comment to the
list. We also have a spreadsheet that we normally take comments on and use that
to put comments into our comment tool. Pat: Chairs have the password to access
that document. Alia: I am looking at the charter and we had put out of scope
NVA-NVE because WG was not comfortable working on that at the time. While we
are open for documents that describe how to use those protocols, I would be
fascinated in any discussion on what we can do in that distributed control
plane space. Alia: Maybe an applicability statement document would be needed.
As an example, how do you apply EVPN and plug the rest. Mathew: Show of hands
please in the interest of applicability draft? 4 hands. Erik Nordmark: There
was an observation if the control plane had a mechanisms to specify which
extensions to support. That would need to be added into EVPN or any other
control plane. Benson: Good point.

Security roundtable.
Jon Hudson presenting on behalf of security group.
Tal: IPsec AH has been deprecated.
Ignas: That was a discussion topic at the roundtable.
Jon: Tal, if you did not say that, how many people in the room would know that?
Matthew: Any other comments on this roundtable outcome? We have an expired
draft on security considerations. That needs to be resurrected and take the
requirements from there and translate to the solutions.

3. WG plans. 10 min. WG Chairs.

Matthew: Next steps in the WG. We will do the adoption call on the DT data
plane draft. Today we would like to do a consensus call on the outcome of the
DT. We will also do a consensus call on the list. Greg: I just recently
realized from the mailing list that GUE is also progressing. What I am asking -
is there a way that teams the work in NVO3 and INT-AREA to collaborate that the
decisions made are consistent? I am talking about entropy, alternative marking
and other things that benefit everybody. Alia: The point of having a single
dataplane encapsulation is that everything else builds on top of it. There are
interest for other purposes to use GUE. I would be happy to see less
encapsulations but the focus is that the work done on NVO3 is a recommendation
that Geneve is the recommendation and we plan to focus on Geneve going forward.
Tal: For clarification - do we still plan to target GPE as an informational?
Matthew: Once we are finished with the standards track document we will look at
that. Alia: Assuming that the authors are interested, it can be an
informational document. Tal: This is a WG document and authors are less
relevant. Alia: The question is whether there are people who want to do work.
It will not be published as informational before the standards one is published
as an RFC. Benson: I do not have a strong opinion on which protocol to pick.
One of the criteria can be implementations. There are implementations of all of
them, would be good to gather the feedback. Matthew: We had questions raised
like that before, authors came and said that there are implementations.
Implementation reports would help. We really need to pick one, as long as there
are interoperable implementations, and at this stage it would be difficult to
make a choice only on the implementation status. If it went to internet
standard we would need more implementation experience. Matthew: Can we have a
show of hands if you agree with DT conclusion to move on with Geneve? 15 hands.
Matthew: Disagree? No hands. Matthew: Can we have a show of hands if you do not
care and want to go to Bits and Bytes? :-) Matthew: We will raise the consensus
call on the list. Matthew: We have a milestone for August this year for
completion of this. One item is missing for OAM work progression. We will do an
adoption call for two OAM drafts. Matthew: We will likely forma an informal
design team on control plane applicability draft to make rapid progress.
Matthew: Meeting ended.