Minutes IETF101: nvo3
minutes-101-nvo3-00

IETF101 NVO3 WG agenda

Network Virtualization Overlays WG

Wednesday Afternoon session I - 15:20-16:50 - Blenheim

Matthew: Welcome to NVO3 down in the dungeons.
Matthew: Note well applies.

1. Administrativia.                                                            
    WG Chairs.         5 min

Matthew: Blue sheets circulating. Note takers. This is a normal meeting, no
roundtables. Please keep to your time slots. Alia is stepping as RTG AD. Thank
you Alia for your guidance and support and encouragement. Martin is taking over
as a new responsible AD, and good luck. Ignas has been a secretary for a while,
he is stepping down. We will be looking for a new WG secretary. If you are
interested in this role please come and see WG chairs after the meeting.

Agenda bashing.

Milestones.

2.        WG status update.                                                    
            WG Chairs.         10 min

Document status.
Split NVE liaison to IEEE. Appreciate if you could take a look at the liaison
and review it. See chairs for access credentials. LC plans for Geneve and DT
encapsulation document. There is an ongoing poll for security requirements
document. VMM protocol draft might be about the time to go into WG LC. Jorge:
We have EVPN applicability draft that you have requested. We should issue WG
adoption call soon. Matthew: Yes. Sam Aldrin: We will start the process. Jorge:
Sounds good.

Matthew: Incoming liaison from IEEE P802.1Qcy. Feedback by 15 May for this
draft document. Pat Thaler: I will be retiring, but will send the message to
the list with the names of the editors who will be managing this that people
can send the feedback to the correct contacts. We appreciate feedback before we
progress the document. Sponsor ballot is equivalent to LC in the IETF and it is
getting close to be done. Pat: Last time it helped to get some people who
committed to the review, if you could ask for people. Mat: If you would like to
volunteer either raise your hand now or see the chairs at the end. Pat: This
document is the control plane for the split NVE.

3.        draft-mglt-nvo3-geneve-security-requirements-03
        a) Ilango Ganga
        b) Daniel Migault
         Discussion on outstanding issues and comments                         
               20 min

Matthew: Ilango is going to do a remote presentation on his comments to the
document, and Daniel is going to respond as an editor of the security document.

Ilango presenting.

Daniel presenting. Responses.
Matthew: The old NVO3 security requirements document was written several years
ago and since has expired. This one needs to go independently from the old
security requirements document, the old one may never be published. What you
need for Geneve should be in this requirements document.

Matthew: We should avoid getting a misref from that document.
Sam: Do you plan to address the comments from Ilango in the next version?
Daniel: Yes.
Sam: What is the timeframe?
Daniel: Mid-April.
Matthew: Maybe the way forward is to publish a new document. Not saying that
the document has to be perfect, it just puts the document in to the hands of
the WG to represent the consensus of the WG. Daniel: The next version is going
to be -02 and not -00.

4.        draft-ooamdt-rtgwg-ooam-header-03                                Greg
Mirsky        10 min

Greg presenting.

Asking for WG adoption.
Matthew: A bit of history on this. We did run a WG adoption poll for this
document. At that time we had very few participants proposing and opposing the
adoption, it was difficult to judge the consensus given the lack of
participation on the list. It would be very good to sense whether people have
read this document and express their opinion. There are other OAM drafts too,
we cannot sit and wait. Frank Brockners: Would help the document if you added
the applicability section that said how that particular header would be slotted
in with Geneve, GRE, and the likes. What you have now work well for protocols
that have a pointer of next header of 8 bits. That would not work for 16 bit
protocol pointers. Showing how that fits in a general way would give more
appeal for people to care about it. Greg: Are you suggesting that different
encapsulations have different length of the next protocol field? Frank: It
depends where you want to go with this. If you have GRE, next type will be
ethertype. I wonder where it does apply, how does that apply, and adding that
to the document would be of great help. Greg: I will look into the document,
but our original goal was to use ion new encapsulations like BIER, Geneve, SFC.
Whether that is applicable to GRE we need to discuss. Frank. Having
applicability and deployment section would be good. Greg: In BIER, Geneve, and
NSH it looks not different. Sam: []. ?/Cisco: Curious to know - this seems to
be an inband OAM type. How would this relate to IOAM work in IPPM? Greg: I
would stress that inband behavior of OAM is the function of the encapsulation
layer. If it draws only from the encapsulation layer and not from the payload
then any type of OAM will be inband. In order to ensure that active OAM is
inband with the data flow it puts certain restrictions on how the following
decision should be drawn. One of the examples that we have is an example how
this type of encapsulation can be used for IOAM. The format of the header is
something that we can discuss. ?/Cisco: Can you explain how the next protocol
is supposed to be used? Do you need to look at the first part of the header?
Greg: Yes. If next protocol is 0 it means you have only OAM control packet. If
you have nonzero it means that there is something following after the control
packet. ?/Cisco: I will take this offline. Greg: Next protocol registry is
something that we can discuss. Ilango: The OAM proposal that you have is
applicable at different layers, it could be on the overlay layer, it could be
on the service layer. Both could coexist, and the document does not have enough
applicability information for this case. Greg: I would personally think that
the same packet for the OAM for different layers. Ilango: Not necessarily. NSH
can be transported on multiple different transports. If you go through multiple
encapsulations before reaching the service node. OAM as part of the NSH header
is independent from OAM in the overlay layer. Greg: It would be interesting and
helpful to get some operational considerations where one packet is OAM for NSH
and overlay transport at the same time. How to identify where the fault
happened. It is much easier if it is done on the on the different layers.
Ilango: Can you clarify that in the further version of the document? Greg: This
can be applied on both layers but independently. Parviz: Back to Frank’s
question on applicability - you are going to change behavior of SFC nodes? Is
it going to impact the behavior of the SF node, or is it transparent? Greg: If
we talk about active OAM, we have multilayer OAM individual document in SFC WG,
the scope is SFF. Parviz: Forwarding behavior? Greg: Forwarding behavior is
based on SFF, not SF. Parviz: The behavior of the forwarding node is captured?
Greg: The expected behavior - the document introduces echo request and reply,
and SFF can reply to the sender out of band as requested. Sam: Clarification
question. Are you going to pursue this in other WGs? Are you going to pursue to
get a common solution? Greg: If the WG in the current work in the header -
there is a dependency between OOAM DT and this work in header. If both
documents get adopted I will pursue a common solution, if not I will continue
with SFC. Matthew: Show of hands who have read the draft? 10 hands. Matthew: Of
those who have read the draft, how many think of common header? 1 hand.
Matthew: Of those who have read who do not think it is a good idea? None.
Matthew: Please read the draft. Alia: I would like to reiterate - I am very
happy to see the discussion happening, this is something that WG was working
for 3-4 years. We need this. VXLAN has been deployed for a very long time, and
Geneve is coming. Let’s get this done.

5.        draft-ao-nvo3-multi-encap-interconnect-00                Ting Ao     
   10 min

Ting presenting.

Discussion.

Kyle Larose/Sandvine: Curious what motivated you to start to work on this? This
seems to be similar to Network Slicing. There is a gateway function there. The
other document that I am reading is much higher layer. Is this appropriate to
COMS BoF tomorrow? Ting: This is for dataplane. Zachy Haramaty/Mellanox: The
TNV can be combined, what is the reason for this? Logically it is a separate
entity even if vendor would combine it? Ting: []. Zachy: I still think that TNV
as a component does not need to connect, it is a separate logical component.
Greg: Can you roll back to the reference model. Zachy: TNV in the middle can be
connected to a TS. Greg: It is not a requirement. Zachy: That is a different
logical entity. Greg: That is why we give a different name. Frank Brockners:
Where do you want to take this work? Right now it is an articulation of the
problem domain. I have this uber thing that provides for mapping device. Do you
want to specify protocols, what is the next step? Ting: Do you mean the
protocol between TNV and []? Frank: You articulated on the architecture. Today
I have VXLAN getting in and Gneeve leaving, that is set up. What you
articulating is that someone needs to set up the control protocols. Are you
intending to standardize the control protocols? Greg: Yes. Frank is right. This
is a problem statement at this time. We are looking whether this is a problem
to be solved. What is the conclusion - adoption of this document will be an
agreement that this is a problem that needs to be solved. Not necessarily this
will be a document that provides a protocol or a standard way of a solution.
There needs to be some normalization of negotiation of what protocol is capable
of, what needs to be translated. Yes, there will be some negotiation of the
control plane in order to work on the data plane layer. Matthew: That is a
problem statement. We have one standard dataplane encapsulation. Interworking
between how standard encapsulation and a set of those that are not standard
ones. Greg: That is why we are not going to the solution but first say that if
WG agrees that this is a problem that is worth to be working on. Mathew: We
have architecture RFC, and this is an extension that can apply to it.

6.        draft-xiang-nvo3-geneve-packet-spray-00                 Yolanda Yu   
    10 min

Yolanda presenting.

Kyle: That was pretty cool. Why did you put source UDP port? Was it the same
for all the flows that you would get distribution within the mesh? Kyle: You
used Geneve? When you build Geneve header and you out in UDP header, what value
did you use for source port? Yolanda: It was random. We are considering to
involve node aware parameter. Kyle: It would be nice to have some guidance on
this draft - if all packets take one point and there is a congestion there it
is different if you would use different source point input. Zachy: Name of the
document - packet spraying is a unique case, the document talks about packet
reordering. Greg: That is not necessary. Packet reordering may happen, it is
not the goal. Zachy: The document defines the framework for packet handling.
Greg: My understanding of the document - because of spraying reordering may
happen and this is how we recommend to handle the situation. This is a proposal
for mitigating this. Zachy: There is a chapter 5.3, I think this is a generic
infrastructure. Yolanda: I got a comment via email that this should be a
separate draft. There is no encapsulation for TCP over Geneve directly. We will
post another draft about that. Matthew: question from Meetecho: [audio
unusable].

7.        Working Group next steps open mic                               
Chairs                10 min

Matthew: Next steps in WG.
OAM is a topic that needs to be covered.
EVPN applicability draft.
That leaves centralized control plane/management plane.
We need YANG model for Geneve, and a generic YANG model for configuring various
elements in the NVO3 architecture. We may want to have a YANG DT team for NVO3.
Matthew: Anyone interested in developing YANG model? None. Matthew: Have a
think about it. This is more in the management plane. We have not focused on a
true centralized management plane yet. Alia: What are you all interested in
working on? Just Geneve? Do we need any other chunks? What are you looking for,
what are the things that are missing? Obviously you here are watching and
interested what do you see as gaps? Matthew: Any comments? Is there anything
that needs to be done for management plane? There is work in LSVR on
centralized control plane? Would you like to see any work in that area done in
NVO3? Please raise your hand if you would like NVO3 to work on a more
centralized dynamic management plane? No hands. Martin, incoming RTG AD: Seeing
an overwhelming number of responses, I would ask a different question - should
we close NVO3 when we have done Geneve? Please raise your hands. Greg: Let’s
define what is done. Does it mean that Geneve specification achieves standard,
or we have done OAM as well, and done YANG model? To me to say yes first I need
to understand what done means. Sam: For YANG, no-one in the room raised hands.
Greg: Give us some time to sleep on it. Jumping the gun may not be the best
thing. Probably I would appreciate if we discussed really more seriously what
done means, what scope of the work is a complete set of functionality that we
can release to the world and say that we are done. ?: One document discussed
potential new options for Geneve header. YANG model for the configuration would
be a very useful thing. I am speaking in favor of doing something for the
centralized model. Sam: We have a good presentation from Frank, I am not sure
whether the authors would like to pursue that work. Daniel: When you say Geneve
is completed, do you include security mechanisms too? Matthew: Yes. Do we need
to do anything more in the control and management plane? Frank: There are many
aspects to OAM, some of the work is done in IPPM. It would make sense to
continue with big items to make a complete protocol solution. Maybe call it
Geneve maintenance. I also advocate for YANG models. That would be useful. Jeff
Tantsura: I would recommend to have a YANG DT. We had routing YANG DT, they
delivered great models. Matthew: Drop us email if you would like to serve on
YANG DT. Jeff: YANG expertise outside of NETMOD is sparse, potentially those
who worked on routing. Martin: May I suggest that you relay those questions on
the list to reach a broader audience? Matthew: Yes.

Matthew: End of meeting.