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>
