Minutes for NVO3 at IETF-96
minutes-96-nvo3-2

IETF 96 - NVo3 Meeting Agenda

Wednesday 20th July-2016, 1400 - 1530 CEST. (90 min)

WG Chairs - Matthew Bocci, Sam Aldrin
Note Taker: Ignaz Bandanas
Jabber Scribe: Carlos Pignataro

Potsdam I conference room

Afternoon Session I

Meeting Minutes:
===============

Note well applies.

1.1 - WG Chairs - Welcome, Agenda Bashing, Status Update

       (15 min)

Agenda.
Personnel changes - Sam is a co-chair.
OAM topics will cover both OOAM and NVO3 OAM specifics.
Discussion on use cases document.
Alia Atlas: Use cases documents can be helpful at the beginning of the WG, the
question is whether they are useful several years later. If there is an
enthusiastic agreement in WG to progress that - it may be helpful to publish
it. Would suggest to shape use cases to the applicability - here is a use case
and how it maps to solution components. Lucy Young: Agree that this document
could have been completed long time ago. Very little progress over the years.
We continue to push back this work, this draft created the scope, maybe it
would indeed be better to move to applicability document. Erik Nordmark: There
are parts of content of the use cases document in other documents, it might
have already served its purpose.

1.2 - IEEE802.1Qcn update: VDP extension to support NVO3 (10 min)
  https://datatracker.ietf.org/doc/draft-ietf-nvo3-hpvr2nve-cp-req

  Presenter: Pat Thaler

[presentation]

The current draft will be liaised with IEEE 802 next week.
There is no YANG model - VDP was done before YANG time. May need to develop
YANG model, otherwise will end up extending the MIB.

Sam Aldrin: Will the YANG model be within IEEE, or IETF draft?
Pat: Possibly within IETF, especially if we get someone to draft it here.

[discussion]

No questions or comments.

1.3 - Identifier Locator Addressing (10 min)
   https://datatracker.ietf.org/doc/draft-herbert-nvo3-ila/

   Presenter: Tom Herbert

[presentation]

ILA overview, use cases. ILA being used in deployments at Facebook for task
addressing.

[Pierre Pfister presenting VPP hackathon results]
Implemented from scratch during the hackathon. Verified interoperability with
Linux implementation. ILA specification seems to be relatively clear, some more
clarification details would help though.

[discussion]

Erik Nordmark: A comment on 5G BOF - it was a side meeting, not a BOF.
Tom: I have worked a bit with Linda Dunbar on hyperscale addressing.

David Mozes/Mellanox: Can you clarify what is the issue with the checksum?
Pierre Pfister: there is a need to indicate whether the translation has set the
checksum to zero (?) Behcet Sarikaya: 5gangip was a lunch meeting, not a BoF.
There is a mailing list for it. Behcet: I have some concerns in a way that you
change ILA. Behcet: Not certain too what do you mean by the identifier-locator
BOF.

1.4 - Overlay OAM Design team update (10min)

   Presenter: Erik Nordmark

[presentation]

[discussion]

Sam Aldrin: Some of your proposals are in the context of overlay OAM, but
others apply to non-overlay environments too. What is the scope? Erik: Overlay
defines new ways of doing OAM. But if we do that, could we reuse those new OAM
mechanisms not for overlay too? It depends on the interworking of overlay and
underlay, there is an overlay protocol that has a concept of VNI and we need to
discover it. Sam: Are you proposing any architecture guidelines on what if
support is not available on platforms or networks? Greg Mirsky: What separates
what is in scope and what is not - for overlay OAM we are marking OAM as an
explicit payload type, and that will ensure that OAM payload is inband with
data. Greg: Query operations may be out of band and still get the valid data.
But for other operations it is essential that OAM is inband. Greg: In the gap
analysis document there is a section that mentions this specifically. OAM needs
to be recognized as a distinct payload type. Marking methods need to be used
that are not considered for the forwarding of the packets. Tom Herbert: OAM
ping format - is that with the format header? Does it have payload type? Why do
we need 16 bit version number? Carlos Pignataro/Cisco: My perspective is what
Greg was talking about is about encapsulation specific, but not overlay
specific OAM. Cross-layer correlation is an important area to cover. Jesse
Gross: Inband telemetry work has some overlap with this, it is a P4 document.
Erik: Could you send a pointer to that document. Dino: You said you need to
test the remote side. You need a control plane for this to be effective. Dino:
Another comment - how do I verify that this endpoint can communicate with
another endpoint - that will have scaling issues. Probing is not needed at the
encapsulation layer. Dino: We are doing probes to reach the other side, it
takes 4 drafts to describe this feature - this seems too much. Dino: You can
use ping and traceroute to find it out. This is a control plane feature, you
should stay away from data plane. Erik: You would not run BFD across N-squared
mesh of VNIs. But you may want to run directed proactive probes to specific
VNIs. Dino: You always know the addresses as you do encapsulation to them.

1.5 - In-band OAM for NVO3 (10 min)
   draft-brockners-inband-oam-requirements-00.txt
   draft-brockners-inband-oam-data-00.txt
   draft-brockners-inband-oam-transport-00.txt
   draft-brockners-proof-of-transit-00.txt

   Presenter: Frank Brockners

[presentation]

[same presentation as in RTGWG]

[discussion]

Greg Mirsky: You said this method can be used for ECMP - unfortunately not. You
will see only the paths that your traffic will be able to take. To see all
paths you need active OAM and discovery to explore all paths. Greg: Second
comment - test traffic could be detected and treated specially. You need to use
dynamic port ranges to send your traffic. Frank: On ECMP - we do things for
customer traffic, not the ECMP traffic. If customer traffic does not use that -
it is fine. Frank: If you want to monitor something - monitor that, and not
send an additional traffic. It is complementing existing solutions. Sam: Out of
time for discussions.

1.6 - Discussion (35min)

Matthew: Discussion on dataplane drafts. We have 3 WG drafts. GUE is moving to
intarea. The concern of the chairs is that we are not helping the community by
progressing all of them. We could publish all of them as informational and one
on standards track based on deployment experience. We could also move to
standards track and keeping others informational. Would like to hear the
opinion at the mike.

Alia Atlas: WG picked 3 different encapsulations that sat there for last 18
months. If people want to progress the work the WG needs to make the decision
what to progress. Alia: If WG cannot come to a conclusion we can add a
paragraph stating that WG had no consensus on the outcome. Alia: I would like
to hear opinions. Alia: Are there strong technical reasons why the WG cannot
make a decision? We need to do something specific that is needed for the
industry. Please speak up. Dino: I think you should close the WG. Erik
Nordmark: Historically there are deployments of VXLAN but that is an individual
stream document. There are requirements for picking yet one more bit in the
header for some new functionality. Erik: It is just an observation, I am not
saying that the 3 proposals are technically bad. Sam Aldrin as individual: If
we take drafts to informational, any work that we do in the control plane needs
to support all of them. We have to pick one that is deployed and base the
further work on it. VXLAN is deployed but is not a WG work item. Sam: If there
are reasons for other protocols to exist, we can always bring them back. Tom
Herbert: There is a reason why VXLAN is not on this list - there is no way to
extend it. You cannot change it to include protocol type. This brings to a
question of a least common denominator - if we do that to VXLAN, we need to
convey onto all other possible protocols. Tom Herbert: VXLAN is not extensible
into the future. There have been multiple attempts in this group to extend
VXLAN. We likely need to move beyond VXLAN, but to which one of the three -
they are not that different, they are fundamentally the same. Tom Herbert:
VXLAN is likely not going away. Thomas Morin/Orange: Many solutions are looked
at from implementation perspective in software. We also need to cover hardware
implementations. If VXLAN is not good going into the future, we need to
recommend one that is also implementable in hardware.

Alia: I would like to get some sense of the room of how many people think we
should pick only one? [quite many hands]. Alia: Who thinks it is not a correct
answer of the WG to pick one? [no hands] Alia: Great - we need to pick one. Tom
Herbert: Did you mean pick one encapsulation, or one of the options from the
slides?

Matthew: The first question was pick one.
Alia: I would like to see significant technical objection against
encapsulations.

Matthew: Who has significant objection against VXLAN-GPE?
Erik Nordmark: The extensibility pieces in GPE are somewhat limited. There are
options that might be doable on the endpoint only, not on the hardware side. We
still need that extensibility more generally. Jesse Gross: It is not feasible
to use VXLAN-GPE. no name stated: VXLAN-GPE can encapsulate NSH. Andrew
Dolganow: Can I ask that people state technical objectives, and not general
statements? Tom Herbert: VXLAN-GPE - how do we insert security cookie? I have
got no answer. How do I add a bit to do remote checksum offload? Did not get
answer. Encapsulation design team has gone through many of those issues
multiple times. I haven’t seen responses to those issues. There were no
technical discussions on those topics. We are not going to make a decision now
in 5 minutes. Alia: The reason IETF does consensus is to ensure not that there
are no technical problems, but that we know them and are able to address them.
I need to know what the technical problems are. Tom Herbert: We are not having
technical issues being raised on the list. Alia: We will be taking conversation
to the list. Lucy Young: If we are picking one encapsulation, does that mean
that other cannot be published as experimental, provided that there are
implementations in the industry? Matthew: That is possible, they would be
informational. Alia: Are there more substantial objections on VXLAN-GPE?
Matthew: Next encapsulation is GUE. Who has significant technical objections?
Dino: I believe protocols do not need to be extensible. Example - LISP header
is fixed, and we added crypto after the RFC came out. Adding new TLVs will
require changes to hardware, and you may also change the port number at the
same time. Jesse Gross: I disagree with that statement. There are possible ways
to deal with it in backwards compatible manner. Dino: Interoperability is
needed on data plane. Tom Herbert: TLVs are nondeterministically ordered. I am
not convinced that we need to do TLVs in the hardware, I am worried about
needing to support TLVs. Pat Thaler: Even skipping TLVs is not free, we have
pressure to reduce the handling time or processing, and skipping does not help
with that. Fixed format allows faster processing. This is what customers are
demanding. Matthew: Issues with Geneve? Dino: Same as with GUE. Alia: There is
also a reality of what is being implemented and deployed. Thank you for
initiating this discussion. I hope that the draft authors for VXLAN-GPE and GUE
now understand the concerns and would be able to respond. Tom Herbert: I would
like to suggest is a correlation between those protocols and what we put into
encapsulation DT considerations. Maybe draft authors could go line by line and
see how they implement the encapsulation considerations.

End of meeting, remaining topics on the agenda were not covered.

   - Data Plane encapsulation
   - OAM discussion
   - YANG modeling (Modeling work happening at IEEE)
   - Control plane discussion

1.7 - NVo3 Control Plane Protocol Using IS-IS (10min)
   https://tools.ietf.org/html/draft-xu-nvo3-isis-cp-02
   Presenter - Xuxiao Hu

1.8 - Tunnel stitching for NVO traffic (10min)
   https://tools.ietf.org/html/draft-yong-nvo3-tunnel-stitching-00
   Presenter - Lucy Yong