I think it will be useful for the design team to articulate clearly and
motivate those objections, and present it to the WG for formal
discussion BEFORE starting the new design. That should help consolidate
the requirements for the design of the new encap.
A separate technical document will help evaluate in depth the
objections raised, rather than rely on hundreds of emails and their
different interpretation.
I think I have seen quite a lot of disagreement around the objection
themselves.
For example, wrt GPE extensibility the summary reported that
"- GPE is insufficiently extensible. Numerous extensions and options
have been designed for GUE and Geneve. Note that these have not yet been
validated by the WG."
That assertion seems to ignore (as it has been pointed out multiple time
in the mailing list) what has been done with NSH, or other proposed
encodings for carrying metadata with VXLAN-GPE such as:
https://tools.ietf.org/html/draft-ietf-sfc-nsh-10
https://tools.ietf.org/html/draft-brockners-inband-oam-data
I would like the WG to articulate why, from a technical point of view,
proper layering can't be used to extend GPE (as recommended by the GPE
draft itself), as it is certainly possible (and done) in the two drafts
indicated above.
Same goes for the security objection to GPE.
I'm quite sure the authors of the other two proposals have similar view
on the objections raised to their proposals.
A separate document, in my opinion, would help understanding what needs
to be addressed before we start with the new design.
Thanks,
Fabio
On 10/24/16 12:51 PM, Anoop Ghanwani wrote:
Hi Alia,
Ideally I would rather not go there at all as expressed in the first
part of Fabio's note. Assuming we must go there, having a section
that documents why the WG thought we needed a new one would be good
enough for me.
Anoop
On Mon, Oct 24, 2016 at 11:46 AM, Alia Atlas <[email protected]
<mailto:[email protected]>> wrote:
Hi Anoop,
On Mon, Oct 24, 2016 at 2:43 PM, Anoop Ghanwani
<[email protected] <mailto:[email protected]>> wrote:
Alia,
I think it will provide an official reference which will be
helpful since all the encaps will be around a long time and we
can point people to that document when we are asked the
question "why did they develop yet another encap?".
So what you are asking for is a section in the overall draft that
talks about the motivations and improvements?
There's a trade-off of speed and getting a solution done versus
doing process work for a theoretical future that won't happen if
we don't get the technical work finished.
Regards,
Alia
Thanks,
Anoop
On Mon, Oct 24, 2016 at 11:30 AM, Alia Atlas
<[email protected] <mailto:[email protected]>> wrote:
Anoop & Fabiio,
On Mon, Oct 24, 2016 at 2:26 PM, Anoop Ghanwani
<[email protected] <mailto:[email protected]>> wrote:
Agree with Fabio (including the suggestion for an
interim deliverable on shortcomings). If the WG
doesn't agree on the shortcomings, chances are they
may not like the 4th encap.
What do you expect to be different from the summary of
technical objections that came out of the last
discussion? Are you looking for more detail?
I didn't see disagreement about the accuracy of the
technical objections.
Regards,
Alia
Anoop
On Thu, Oct 20, 2016 at 12:10 PM, Dino Farinacci
<[email protected] <mailto:[email protected]>> wrote:
I agree with Fabio.
Choosing a single encapsulation that is not 1 of
the 3, creates a 4th one that no one wants.
And guess what, you make all 3 authors unhappy
where none of them will endorse (or implement) the
4th one.
Dino
> On Oct 20, 2016, at 12:02 PM, Fabio Maino
<[email protected] <mailto:[email protected]>> wrote:
>
> (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 2nd 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] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/nvo3
<https://www.ietf.org/mailman/listinfo/nvo3>
>
>
> _______________________________________________
> nvo3 mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/nvo3
<https://www.ietf.org/mailman/listinfo/nvo3>
_______________________________________________
nvo3 mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
<https://www.ietf.org/mailman/listinfo/nvo3>
_______________________________________________
nvo3 mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
<https://www.ietf.org/mailman/listinfo/nvo3>
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
