Minutes IETF97: nvo3
minutes-97-nvo3-00

NVO3 meeting minutes

Wednesday November 16th, 13:30-15:00, 90 minutes
-----

Meeting starting.

1. Welcome, Agenda Bashing, Status Update
WG Chairs (15 min)

Note well applies.

2. IEEE 802.1Qcn (VDP extension for NVO3) status update
https://datatracker.ietf.org/doc/draft-ietf-nvo3-hpvr2nve-cp-req/
Pat Thaler (5 min)

Pat presenting.

[discussion]

No questions and comments.

Matthew: Is anyone interested in reviewing this draft? Benson is interested.
Matthew: Will send a request to the list.

3. VXLAN YANG Data Model
https://datatracker.ietf.org/doc/draft-chen-nvo3-vxlan-yang/
Fangwei Hu (10 min)

Fangwei presenting.

[discussion]

Greg Mirsky: You have container for EVPN - should that be part of EVPN model
and then you augment VXLAN and use this container? It is just a question?
Fangwei: I agree with you, will discuss with the EVPN team on this. Lycy Young:
Where do you specify the maximum MTU, and also tunnel security parameters?
Suppose I am using IPsec. Fangwei: You mean the way how to configure the MTU
for the tunnel? Lucy: Configure or discover, does not matter. Fangwei: I will
consider your suggestion.

Matthew: Please a show of hands who have read this draft? A few people.

4. BFD for VXLAN
https://datatracker.ietf.org/doc/draft-spallagatti-bfd-vxlan/
Greg Mirsky (10 min)

Greg presenting.

[discussion]

Matthew: Who has read this version of the document? Version 4. A few people.
Matthew: Would be good to get more review on the list. Please read and send
comments. Sam: Have you presented this in BFD WG too? Greg: BFD is not meeting
this time. We have announced on the mailing list.

5. Round table discussions
(50 min)

Matthew: Moving to roundtable discussion sessions.

Alia: Injecting energy into the room. :-)
Alia: We have OAM, data plane and control plane discussions. All of you have
your own views on architecture and how it works, and please get into groups and
encourage the discussion.

[End of minutes for Wednesday meeting]

Thursday November 17th, 13:30-15:00, 90 minutes
-----

Meeting starting.
Note well applies.

1. OAM Header for use in Overlay Networks
https://datatracker.ietf.org/doc/draft-ooamdt-rtgwg-ooam-header/
Greg Mirsky (10 min)

Greg presenting.

[discussion]

Matthew: The question is whether this work gets adopted here or in RTGWG.
Greg: Yes. We also have two other documents in this set, use cases and gap
analysis. Greg: In BIER we do have working group document already, if there is
an agreement that these documents are something that we want to progress, we
will work with BIER to make it more generic. There are multiple BIER specifics
in BIER documents that are not applicable to scenarios seen here. Greg:
Appreciate comments for common work on common overlay technologies. Lycy Young:
The next version protocol - it could be used for inband OAM too? Greg: I would
call it in-situ OAM and active OAM. Active OAM can be inband as well. In our
discussion yesterday we talked about that. It can be inband and share the fate
of the flow that it is monitoring. Greg: I would not refer to it as out of band
OAM. We want to interpret defect detection and performance management - we want
to correlate it with the data flow. Lucy: You have format and reserved fields -
why are they separate? Greg: We originally took everything into flags, but
added in reserved field for future extensibility. If there is a strong opinion
against reserved field – let’s discuss it. It is possible to redefine and merge
reserved flags. Reserved flags can be dedicated to something. Frank Brockners:
How would this fit that into something like VXLAN-GPE? Greg: This is an update
on version 0. OAM header follows immediately the packet header. In OAM header
you can identify the next type of payload that follows the OAM control packet.
Lucy: That would change the processing of the payload. Greg: We are open to
discussion. You are right, in a case of active OAM it usually gets punted up.
It may be a bump in the wire or something more complex, depends on
implementation. In-situ OAM proposal is interesting and therefore this approach
can work for both. Matthew: Who has read the draft? Please could more people
read it? Greg: May I ask to keep all the groups - RTGWG and NVO3 - in the
discussion loop? Matthew: Best would be to send comments to RTGWG instead of
cross-posting.

2. On-demand Continuity Check (CC) and Connectivity Verification (CV) for
Overlay Networks
https://datatracker.ietf.org/doc/draft-ooamdt-rtgwg-demand-cc-cv/ Greg Mirsky
(10 min)

Greg presenting.

[discussion]

Matthew: Would be useful to get more feedback on this in the context of the
transcending traceroute draft. Erik Nordmark: It works on a basis of regular
traceroute packets, and tunnel operates in uniform mode, and not pipe mode.
ICMP errors get propagated back to the edge routers. Sam: Do you envision it to
support point to multipoint? Greg: We looked into it for BIER use cases which
are point to multipoint. Matthew: Show of hands who has read the draft? A few
more this time. Please send comments to the list. Sam: How do you propose this
for different OAM that has different encapsulations? Greg: One of the
objections was to make it transport independent. We have many instruments that
are MPLS specific. In IPv6 it is not clear how this would work. We can develop
comprehensive functionality and operators could choose what they need. Sam: Are
you expecting both to be supported? Greg: Yes, it could work across multiple
scenarios and multiple encapsulations.

3. Report back on round table discussions
WG Chairs (70 min)

Control plane - Benson presenting.

Alia Atlas: L3SM has just finished and closing. There is an interesting YANG
model on service description on topologies and attachments. It is a model of
interaction for a customer and provider. It would be interesting to make a
model to describe the pieces that are needed to set up this instance if
service. Pat Thaler: One of the things that the control plane would need to
deal with is migration and getting the changed information that the other NVEs
need when migration happens. Lucy: The northbound  - whether we call it
operational data model? It is not necessary a service model as that one deals
with customer interfaces. This is nortbound interface. Alia: The point was that
it is not at the level of operational model, but Benson was talking about the
higher layer abstractions and not trying to make a technology binding. Benson:
it is to understand where the work needs to be done, maybe L2SM/L3SM example
fit, maybe not. Lucy: In the industry we call it a controller and therefore I
call it northbound. Benson: We try to distinguish between management and
control plane and identify their separate functions. It is about the
reachability, what needs to be exchanged. Without talking much about the
implementation details - you may think about the tunnel implementation and a
FIB as one or separate entities. How we model that is the discussion here.
Lucy: Control plane is NVA to NVE, what I talk about is nortbound of NVA. Alia:
There are many things that could be interesting, the question is who is
interested on working on then and getting the work moving forward. There are
many technologies in these contexts and control plane work has been neglected.
Greg Mirsky: I would think that the liveness detection bullet may be a function
of OAM. Benson: I agree. We talked about two types of liveness detection
yesterday - NVE-NVE and NVE-NVA. Greg: We first had that functionality as part
of routing protocols, but then we found that they cannot provide aggressive
enough detection. Let’s see what the requirements are and see whether that can
be part of control plane or OAM. Nabil: We need to first find out the things
that we need to do on the interface between NVE and NVA. It seems to be a blur
between what is management and control interface. Nabil: What Lucy is raising
is somewhat different, it is more about the interface between the entities
here. First we need to cover the NVE-NVA part, and then later talk about
northbound. Nabil: We talked about configuring OAM endpoint via management,
then we have liveness between NVE and NVA. That is not necessary a control
plane. NVE could rely from management plane for push to the control plane. The
reachability is in the context between NVE and NVA. How you configure the OAM
functionality is not necessary the OAM itself, it is rather how to communicate
and how to configure it. Benson: OAM definition and how it behaves happens in
the control plane. We need to talk about the triggers. There may be
connectivity between NVEs. Nabil: NVA needs to enable to trigger the OAM
between NVEs. The enabling is important here, not necessary the OAM itself. If
you have a very static environment you could configure the routing context and
that could be done in the management plane. Reachability information that is
dynamic in the nature could be pushed from the controller. Nabil: There may be
very highly dynamic environment with a high rate of change then you may need to
push the reachability information and the associated policies. That may be part
of the service model, and maybe it needs to be discussed whether that needs to
be communicated via management interface. Benson: I like the idea of having
working group talking and understanding the static routing equivalent. It is
complex to operate but simple to implement. Parviz Yegani: I need some
clarification on relationship between service model, the control functions, and
the NVA. In the context of SDN controller - if you put a controller layer
synonymous to NVA, is that the intention here that you want to use NVA to
capture the functionality of the controller layer? Benson: The way that we
imagined that was exactly that - the word controller may carry some baggage
though. We discussed yesterday whether we should think of NVA as only a
controller. Parviz: In the industry if you look - that train has already
passed. If IETF want to bring single control and orchestration layer into one
layer then I am not certain whether that is relevant. Dynamic service and
dynamic device configuration - there are two separate aspects Benson: You are
raising a good point. If you think of NVE as a device, the FIB associated with
the tenant - that relates to the configuration. Parviz: I disagree. The CRUD
operations belong to orchestration. The controller is not in the business of
doing lifecycle management. When you have service configuration aspects - where
are they? We are doing service and device configuration aspects and that is
part of ONOS, ODL, OpenStack, and that is happening elsewhere. The interaction
between the NVA and NVE if there is a need to define a new protocol that is the
task for the IETF. There are too many of southbound interfaces already. Benson:
My opinion that there are too many of them and I cannot see how we could
interoperate. Alia: Sometimes I have a bigger picture because many people come
in and bang on my head. Alia: We need to get the interoperability - bring some
of it here and discuss. This morning we had an open source routing meeting.
Please think how we can interact better, what parts are standard, what are
stable. Parviz: I want to see the management function moved to orchestration
layer. Ali: Write a draft. Parviz: Also to expand on the service model. The
service model is different from a dynamic service configuration of the service.
Parviz: Then we have a dynamic configuration of the device. We need to
understand that those 3 entities exist. Ali Sajassi: Seems that we have some
confusion on the scope of work. What should be in scope is management and
control for setting up the overlay. How do you configure and extended VLAN
across the network that spans datacenters, core network. Configuring that
extended VLAN requires configuration. The scope should not be above the NVA -
no northbound. Benson: That also matches our charter. Greg: Another topic to
discuss would be to get the proper terminology on what we consider to be static
network. Once we have a proactive OAM and once it notifies the network then it
is no longer static. Lucy: A comment on management and control - SDN controller
imposes management and some of the control plane constructs. That is not
necessary aligned with that model. Benson: These are just labels that I
assigned to some buckets and in those buckets I put different things. We can
use different names. Certainly service model term may imply different things to
different people. Lucy: We can define same interfaces to management interfaces
from different controllers. Jeff Tantsura: We could look at TEAS and I2RS,
those have very clear interfaces to expose the business logic. Benson: That was
a helpful discussion.

Data plane roundtable.
Pat presenting.

David Black: Did the security discussion distinguish between the security of
the header and integrity of the header? Pat: It as about the security and there
were some discussions on the header checksum. Pat: I did get the feeling that
we started getting some more closure on the extensions and it is more on how we
take those extensions that they are friendly to the hardware. We were building
good consensus on that. Sam/Google: what was the next step? How do we take it
forward? Pat: We need a length and a way to say that some extensions need to
come first, there was a string consensus to put any tunnel extensions in front.
At this point it would be good to get some discussion on the list on the exact
nature of the extensions. Another area that we need to build consensus is to
see how much flexibility do we need of the extensions. We need to support
vendor dependent extensions. What size, how many - that is an open question to
standardize. What extensions do we want to standardize. Sam: Question to
working group at large - do you think that most of the things that you would
like to see covered here? What is missing? Nabil: I haven’t followed all the
dataplane discussions. Today we are talking about extensions, but do we have
something that we can extend already? Rather than trying to move this way, why
not look from the dataplane requirements perspective. What is the minimal
amount of things to be done beyond VXLAN as that is deployed? What other
extensions need to be standardized? Matthew: That is the point to work out what
that minimum set of extensions is. Pat: This is a list of extensions that we
have consolidated. There are drafts that cover parts of them. We haven’t had as
much discussion on the details of the extensions and that is good to bring in
those discussions. Nabil: Do we have an NVO3 dataplane protocol? Alia: We have
a design team that expressed the consensus of the WG to standardize the single
dataplane encapsulation. Design team is working on the extensions of the
current encapsulation. One source of confusion is trying to understand what
kind of functionality is needed Nabil: The work on dataplane is happening. And
at the same time we are talking about the extensions to that dataplane. Pat:
Dataplane extensions include things how many extension you can carry, and we
need to finish talking about that before we finish the dataplane work. We need
to build consensus on what dataplane needs to do to carry those extensions. We
need not to underdesign and overdesign here. Nabil: The protocol whatever we
design allows to carry extensions, but define the extensions later. Make sure
that the protocol is flexible enough to carry those extensions. Alia: We need
to understand the details about the extensions. That drives the details on what
we need to have in the extensions. Lucy:If we design an encapsulation protocol
we need that protocol to be extendable. Matthew: Thank you.

OAM roundtable discussion
Greg presenting.

Lucy: Why do you need another mailing list?
Greg: I expect that after this meeting will be a lot of discussion. We are not
requiring to do that. Matthew: Let’s keep on the WG mailing list for now. Tal:
On alternative marking - we may allocate a few bits for the OAM encapsulation
or other OAM related purposes. Greg: We will discuss and provide a proper
justification. For now we identify it as a field that does not affect the
forwarding decision and handling of the packet. David Black: On PMTUD - does it
involve the DF bit? Greg: Before the meeting there was an agenda to align to
some scenarios on pathMTU discovery, and one of them is heterogeneous tunnels.
David: MTU discovery needs to be solved. It seems that OAM packets between the
tunnel endpoints may provide some insight. David: genarea tunnels draft may be
good to reference.

Matthew: Thank you all for making this excellent roundtable session and
discussion. Let us know if you found this as a useful experiment.

[End of minutes for Thursday]