Minutes interim-2016-nvo3-01: Wed 15:00
minutes-interim-2016-nvo3-01-201610261500-00

NVO3 Interim meeting – 26 October 2016
Attendees:

T.Sridhar (tsridhar@vmware.com)
giuseppe fioccola (giuseppe.fioccola@telecomitalia.it)
Michael Smith (michsmit@cisco.com)
Ignas Bagdonas (ibagdona.ietf@gmail.com)
Tal Mizrahi (talmi@marvell.com)
Tom Herbert (tom@herbertland.com)
Alberto Rodriguez-Natal (albrodr2@cisco.com)
Kiran (kiranmak@gmail.com)
Alia Atlas (akatlas@gmail.com)
David Melman (davidme@marvell.com)
Sandy (sandy.breeze@eu.clara.net)
Jon Hudson (jon.hudson@gmail.com)
Sam Aldrin (aldrin.ietf@gmail.com)
Matthew Bocci (matthew.bocci@nokia.com)
Sowmini (sowmini.varadhan@oracle.com)
Ilango (ilango.s.ganga@intel.com)
Fabio Maino (fmaino@cisco.com)
Greg Mirsky (gregimirsky@gmail.com)

Minutes:

Matthew Bocci: Meeting starting. Meeting is being recorded.
Matthew: The main focus in on developments of encapsulation formats, and
planning for Seoul meeting. Matthew: Note well applies. Matthew: agenda review.

------
Matthew: Review of the WG progress.
Greg Mirsky: I have thought that OAM is very close to dataplane. Do you think
that the solution will be closer? My recommendation to the DP design team is to
take OAM requirements from overlay OAM DT. Greg: It may have implications to
control plane solutions. Do you see that dataplane will have a separate
document for OAM? How will it relate to overlay OAM? Matthew: Yes, there will
be OAM implications on the dataplane from OAM. Sam Aldrin: WG needs to discuss
how we can come to a common understanding and a common direction with OAM
solutions. Greg: I see only OAM solutions here as deliverables. Do you see that
a separate OAM work item on OAM requirements will be done too? Matthew: We have
operational requirements document that covers OAM. Alia Atlas: Solutions
documents are more important than requirements. Requirements are less valuable
after the fact. But it is valuable as the work is being done.

------

Matthew: Progressing a single dataplane encapsulation.
Matthew: Since adoption of 3 dataplane drafts there has been little progress
done on them, and AD and chairs see that as a concern. There seems to be value
in standardizing a single encapsulation. Matthew: We asked a question in Berlin
and on the list whether to progress with a single encapsulation. The overall
consensus seemed to be that we need a single encapsulation. Matthew: Question
was asked on the list on what technical objections are there on the three
encapsulations. Matthew: Responses are rather well balanced. Matthew: Existing
3 drafts could stay as informational, and one common encapsulation progressed
as a standard. Fabio Maino: One of aspects of progressing on the existing
proposals is for DT to share publicly how they are dealing with the
requirements and how those requirements are influencing the design. Matthew: I
do not want to hold DT by requiring them to produce a requirements draft. We
have been through that exercise already. I would expect solutions document to
include applicability statement. Fabio: I would encourage the DT to share the
requirement work and what they are doing. We may contribute then. Matthew: DT
will address that. Tom Herbert: We had a dataplane encapsulation team and they
had looked into requirements extensively. Matthew: Yes, they produced a
requirements draft and dataplane DT will reference that. Sam Aldrin: Some of
the DT members were members of the previous team too. Fabio: Could you
articulate the first point in your charter? Matthew: DT should produce the
draft, the timing is controlled by them. Whether we can adopt it by the spring
IETF is another question. 6 months away does not seem too bad. Matthew: DT
charter text - with the strike out text removed. Are there any other comments
on the charter? Matthew: No comments. Kiran: Will encapsulation and control
plane work being done independently? Matthew: Yes those are separate work
items. Kiran: Aren’t there interdependencies? Matthew: Likely not that many.
Control plane needs to be extensible. Sam Aldrin: Once the DT comes up with
some proposal for WG review, we should be able to see what impact is on the
control plane. We do not see much impact. Kiran: If we want to add new feature
for control plane, data plane needs to allow for that flexibility. Matthew:
Your concern is that control plane may have implications on data plane? Kiran:L
Yes. Example of OAM and trace functionality - it may need special flags or
TLVs. Sam: We are not casting in stone that this is the dataplane and we have
to deal with it. By the time we have a proposal we will be able to review
whether it is applicable to control plane or not. This work can go in parallel.
Kiran: I wanted to be sure that control plane is not overlooked. Sam: DT
charter includes control plane. Matthew: Any other questions?

------

Matthew: Seoul meeting planning.
Matthew: Given the OAM and control plane importance we would like to focus on
those areas. Also we need to look at the more broad architecture in the context
of NVO3 - broader than the DC itself, but inter-DC, gateways, etc. Matthew: And
whether the solutions proposed take into account those architectural
requirements. Matthew: One option is to have a roundtable discussion in the
room on OAM and control plane. Matthew: Is that a good idea, or a non-starter?
Alia: We had discussions on OAM work before. But there is no followup of the
work that has started. There may be implications on how overall system works.
Alia: We could have a smaller group discussions on specific topics and then
combine the results of those separate discussions. Alia: We tried that on the
mailing list but with little success. Alia: Common understanding on control
plane and architectural work seems to be important. Tom Herbert: How would
logistics of such meeting would work? Alia: We could ask for flipcharts and
each table works on a separate topic. Then combine and present during the other
meeting. Matthew: Would anyone be interested in leading one of such topics?
Kiran: What would be examples of such topics? Could use cases be topics?
Matthew: Yes. Or OAM, and control plane implications. Alia: Requirements for
usability in different places in the network, what are the requirements on the
control plane. Depending on the interest and based on use cases we may build a
list of topics to develop a common understanding and expectations for the
transit node, whether it needs anything more than standard IP routing and
forwarding. Alia: How do you build this into a system. Kiran: All of this
requires some form of control plane. Do you really think that we can split
these features? Alia: There are aspects that we can talk separately. Take
assumptions about control plane and make progress. Alia: EVPN work could be
reused as an example. Kiran: That makes sense. Alia: It would be useful to have
a sense from you all on what topics would be useful to have and discuss. Kiran:
Most of the things that you have listed are good starting points. Matthew: We
will develop a list of topics and sent to the list for feedback.

------

Matthew: Are there any other issues that anyone would like to raise?
M: Thank you very much and see you in Seoul.

Meeting ended.