(for full disclosure I'm one of the authors of VXLAN-GPE)
Matt, Sam, Alia,
I've expressed multiple times and in multiple venues my adversity (and
the motivations) to set this group to design yet another encapsulation.
I won't repeat it here once again, but I want to re-assert that it's
still were I stand.
I've seen quite a few people in the mailing list here expressing similar
concerns, but I see that it has not changed the opinion of the chairs
and the AD on what they believe is the best way to move forward.
That said, here are my comments to the charter.
I think the design team first goal should be to clearly articulate the
shortcomings of the current encapsulations proposed to the WG. This
should be the very first deliverable of the design team. The actual
design work should start only once the WG has reached consensus on that
document. Especially considering that some of the encapsulations
proposed are being deployed, I think articulating the shortcomings will
help to make the best choice in term of (1) selecting which one will
need to be extended, and (2) designing the actual extensions.
Below are my proposals on how to modify the wording of the charter.
On 10/20/16 1:37 AM, Bocci, Matthew (Nokia - GB) wrote:
WG,
We would like to give you an update on the process in the WG for
progressing the issue of a data plane encapsulation. The chairs and
Alia believe that the best way forward is to progress a single
encapsulation format that addresses the technical concerns raised on
the list in the recent discussions. This would address the clear
overall consensus of the Berlin meeting and list for a single
encapsulation.
The strategy should be to take one of the three existing
encapsulations and enhance it to address these concerns. This would
become the standards track output of the WG. The existing three drafts
(GENEVE, GUE and VXLAN-GPE) should be forwarded to the IESG as
informational after the standards track draft specifying the single
encapsulation. This provides an opportunity for those encapsulations
to be documented and maintained.
The single encapsulation should be viewed as one that the WG and
industry can converge around for the future.
We have created a design team to progress work on a single
encapsulation that can form the basis or work going forward. The
design team members are: Michael Schmidt, Uri Elzur, Ilango Ganga,
Erik Nordmark, Rajeev Manur, Prankaj Garg. Many thanks to these
individuals for their help.
Please see below for a draft charter for the design team. Please
review the charter and send comments to the list by 2^nd November 2016.
Regards,
Matthew and Sam
====
NVO3 Encapsulation Design team 2016
Problem Statement
The NVO3 WG charter states that it may produce requirements for
network virtualization data planes based on encapsulation of virtual
network traffic over an IP-based underlay data plane. Such
requirements should consider OAM and security. Based on these
requirements the WG will select, extend, and/or develop one or more
data plane encapsulation format(s).
This has led to drafts describing three encapsulations being adopted
by the working group:
- draft-ietf-nvo3-geneve-03
- draft-ietf-nvo3-gue-04
- draft-ietf-nvo3-vxlan-gpe-02
Discussion on the list and in face-to-face meetings has identified a
number of technical problems with each of these encapsulations.
Furthermore, there was clear consensus at the IETF meeting in Berlin
that it is undesirable for the working group to progress more than one
data plane encapsulation. Although consensus could not be reached on
the list, the overall consensus was for a single encapsulation
(RFC2418, Section 3.3). Nonetheless there has been resistance to
converging on a single encapsulation format, although doing so would
provide the best benefit to the industry.
The portion of the last sentence that follows the comma ("although doing
so would provide the best benefit to the industry") doesn't seem to be
adding anything to the charter. I'd suggest it could be removed.
Design Team Goals
The design team should clearly articulate in a draft which are the
shortcomings of the proposed encapsulations, and where they fall short
in addressing the NVO3 architectural requirements.
Once the 'shortcomings' draft has reached consensus of the WG,
The design team should take one of the proposed encapsulations and
enhance it to address the technical concerns.
Backwards compatibility with the chosen encapsulation and the simple
evolution of deployed networks as well as applicability to all
locations in the NVO3 architecture
, together with the design goals articulated in the 'shortcoming' draft,
are goals. The DT should specifically avoid a design that is
burdensome on hardware implementations, but should allow future
extensibility. The chosen design should also operate well with ICMP
and in ECMP environments. If further extensibility is required, then
it should be done in such a manner that it does not require the
consent of an entity outside of the IETF.
Timeline
The design team should
first produce the 'shortcomings' draft, get it adopted by the WG, and then
produce a first draft describing the proposal by end of January 2017.
Target adoption by the WG by March 2017 IETF.
(those two dates may need to be adjusted accordingly)
Thanks,
Fabio
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
