Working group,
Draft minutes of both days of NVO3 meetings are available for review.
Please take a look and send any corrections if minutes do not capture
clearly or completely what you intended to say.
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
lets 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. Lets 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 havent 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 havent 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: Lets 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]
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
