Subject: [nvo3] the role of a standard (was: Consensus call on moving forward with a single encap.)

From: "Elzur, Uri" <[email-masked]>
Date: Sun, 24 Jul 2016 09:18:57 +0000

Reading the threads here, it may be good to take a moment to discuss expectations out of a std process. To me, a “standard” is about an industry agreement, on a path forward, in a timely fashion, that paves the way (ushers in) the next wave of innovation. Let me try to parse it

-          Industry agreement: in singular (not in plural). The process is to produce ONE agreed upon solution that ideally gives no party any unfair advantage. It is conceivable, however, that leaders retain some of the first mover advantage. If the outcome is MULTITUDE of “standards”, and in this particular case, it may mean simply documentation of 3 separate commercial camps where vendors have created competing approaches, we may have missed the mark.

-          In a timely fashion: One can’t ignore the time aspect. When the std process is not moving fast enough, it jeopardizes the value of the “industry agreement”. In the last years, a significant productivity gains by the software development and open source, enables much faster evolution, one risks therefore, a catch up scenario, lost relevance and falling into documentation. The IETF process has to be updated to cope with the faster evolution, so that within a year of emerging open source direction (where relevant) the WG has narrowed down the options to one and is very close to being done. (yes, I know this is ideal…but this is what is needed)

-          Path forward: that is a suitable technical solution to a given set of problems with a limited set of forward looking mechanism based on experience ( the “limit” is really a judgment call to help with the goal of timeliness); Including however, a reasonable evolution of HW + SW. i.e. assuming HW (NICs in this case) is to be of stagnant limited functionality (i.e. XSUM like feature invented in 1996 – 20 years ago) as a base assumption, should not be the lead assumption. IETF has historically been more SW oriented, but data path encapsulation should not be SW only discussion! Also the emergence of programmable HW and modeling of HW to allow easier programming, means that the std may be relaxed in terms of rigid assumptions of HW functionality. (also not to ignore other aspects, in most cases, the std needs to be backwards compatible to not break existing solutions)

-          New innovation: a successful timely process, keeping pace with the industry, with less vendor specific options will do the trick here…

If we have similar expectations, it may be easier to converge on the complicated problem at hand. 3 options on the table for prolonged time, where the HW and SW have already made progress. So I for one, don’t think in THIS CASE, creating a 4th option is the way forward. We may be better served by picking one out of the existing ones

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

From: nvo3 [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, July 22, 2016 1:11 PM
To: Anoop Ghanwani <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>
Cc: NVO3 <[email-masked]>
Subject: Re: [nvo3] Consensus call on moving forward with a single encap.

+1.

Besides, IETF already has specified many encapsulations, is it really that bad having one extra?

Linda

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Friday, July 22, 2016 7:55 AM
To: Bocci, Matthew (Nokia - GB)
Cc: NVO3
Subject: Re: [nvo3] Consensus call on moving forward with a single encap.

On Thu, Jul 21, 2016 at 7:52 AM, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:

Please respond to this email on the NVO3 list by 29th July 2016:
- Given the IETF's mission, should NVO3 move forward on the standards track with a single encapsulation on the standards track?  If not, please explain your concern in detail.

While the world would be a better place with only one encapsulation, I think it's better to stick with the original path of allowing the 3 encapsulations as experimental.

The NVO3 charter says:
Based on these requirements the WG will select, extend, and/or
develop one or more data plane encapsulation format(s).

Based on the charter, the WG has gone through the process of accepting to work on 3 encapsulations.  What do we know now that we did not know back then?

If we were going to progress only a single encapsulation, I think there would have been more critical feedback and strong suggestions for changing that "winning" encapsulation to accommodate what the other encapsulations perceive as their relative strengths.  And we risk opening up that discussion now and delaying progress even more.

Otherwise, not having a standard has not been a hinderance for getting protocols deployed in the past, and I suspect that if the developers of these encapsulations care enough, we will see deployments of all of them regardless of whether or not we progress them within the working group.

Thanks,
Anoop

---

From: Alia Atlas <[email-masked]>
Date: Sun, 24 Jul 2016 09:54:16 -0400

Uri,

Thank you very much for your thoughts on the standards process.

We do need to understand significant technical objections to whatever
existing solution might be stated from.

Unfortunately,  the solutions haven't responded to much input or changed
from the WG yet.

Regards,
Alia

On Jul 24, 2016 5:19 AM, "Elzur, Uri" <[email-masked]> wrote:

> Reading the threads here, it may be good to take a moment to discuss
> expectations out of a std process. To me, a “standard” is about an industry
> agreement, on a path forward, in a timely fashion, that paves the way
> (ushers in) the next wave of innovation. Let me try to parse it
>
>
>
> -          Industry agreement: in singular (not in plural). The process
> is to produce ONE agreed upon solution that ideally gives no party any
> unfair advantage. It is conceivable, however, that leaders retain some of
> the first mover advantage. If the outcome is MULTITUDE of “standards”, and
> in this particular case, it may mean simply documentation of 3 separate
> commercial camps where vendors have created competing approaches, we may
> have missed the mark.
>
> -          In a timely fashion: One can’t ignore the time aspect. When
> the std process is not moving fast enough, it jeopardizes the value of the
> “industry agreement”. In the last years, a significant productivity gains
> by the software development and open source, enables much faster evolution,
> one risks therefore, a catch up scenario, lost relevance and falling into
> documentation. The IETF process has to be updated to cope with the faster
> evolution, so that within a year of emerging open source direction (where
> relevant) the WG has narrowed down the options to one and is very close to
> being done. (yes, I know this is ideal…but this is what is needed)
>
> -          Path forward: that is a suitable technical solution to a given
> set of problems with a limited set of forward looking mechanism based on
> experience ( the “limit” is really a judgment call to help with the goal of
> timeliness); Including however, a reasonable evolution of HW + SW. i.e.
> assuming HW (NICs in this case) is to be of stagnant limited functionality
> (i.e. XSUM like feature invented in 1996 – 20 years ago) as a base
> assumption, should not be the lead assumption. IETF has historically been
> more SW oriented, but data path encapsulation should not be SW only
> discussion! Also the emergence of programmable HW and modeling of HW to
> allow easier programming, means that the std may be relaxed in terms of
> rigid assumptions of HW functionality. (also not to ignore other aspects,
> in most cases, the std needs to be backwards compatible to not break
> existing solutions)
>
> -          New innovation: a successful timely process, keeping pace with
> the industry, with less vendor specific options will do the trick here…
>
>
>
> If we have similar expectations, it may be easier to converge on the
> complicated problem at hand. 3 options on the table for prolonged time,
> where the HW and SW have already made progress. So I for one, don’t think
> in THIS CASE, creating a 4th option is the way forward. We may be better
> served by picking one out of the existing ones
>
>
>
> Thx
>
>
>
> Uri (“Oo-Ree”)
>
> C: 949-378-7568
>
>
>
> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Linda Dunbar
> *Sent:* Friday, July 22, 2016 1:11 PM
> *To:* Anoop Ghanwani <[email-masked]>; Bocci, Matthew (Nokia - GB)
> <[email-masked]>
> *Cc:* NVO3 <[email-masked]>
> *Subject:* Re: [nvo3] Consensus call on moving forward with a single
> encap.
>
>
>
> +1.
>
>
>
> *From:* nvo3 [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Anoop Ghanwani
> *Sent:* Friday, July 22, 2016 7:55 AM
> *To:* Bocci, Matthew (Nokia - GB)
> *Cc:* NVO3
> *Subject:* Re: [nvo3] Consensus call on moving forward with a single
> encap.
>
>
>
>
>
>
>
> On Thu, Jul 21, 2016 at 7:52 AM, Bocci, Matthew (Nokia - GB) <
> [email-masked]> wrote:
>
>
> - Given the IETF's mission, should NVO3 move forward on the standards
> track with a single encapsulation on the standards track?  If not, please
> explain your concern in detail.
>
>
>
> While the world would be a better place with only one encapsulation, I
> think it's better to stick with the original path of allowing the 3
> encapsulations as experimental.
>
>
>
> The NVO3 charter says:
>
> >>>
>
> Based on the charter, the WG has gone through the process of accepting to
> work on 3 encapsulations.  What do we know now that we did not know back
> then?
>
>
>
> If we were going to progress only a single encapsulation, I think there
> would have been more critical feedback and strong suggestions for changing
> that "winning" encapsulation to accommodate what the other encapsulations
> perceive as their relative strengths.  And we risk opening up that
> discussion now and delaying progress even more.
>
>
>
> Otherwise, not having a standard has not been a hinderance for getting
> protocols deployed in the past, and I suspect that if the developers of
> these encapsulations care enough, we will see deployments of all of them
> regardless of whether or not we progress them within the working group.
>
>
>
> Thanks,
>
> Anoop
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>

---

From: Fabio Maino <[email-masked]>
Date: Sun, 24 Jul 2016 19:19:55 -0700

I think Uri makes an important point when he says that adding a 4th 
encapsulation will compound the problem rather than solving it, 
especially considering where the HW/SW implementations are today.

IMO this WG should focus on designing a control plane that allows to 
discover and select the appropriate encapsulation, based on receiver's 
capability.

Once that is done the overall architecture will be able to deal with 
multiple encapsulations, and more than one can be moved to standard track.

This kind of work will also help with backward compatibility with 
encapsulations (such as VXLAN, for example) that will be around for 
quite some time.

Fabio

On 7/24/16 6:54 AM, Alia Atlas wrote:
> Unfortunately,  the solutions haven't responded to much input or 
> changed from the WG yet.
>
> Regards,
> Alia
>
>
> On Jul 24, 2016 5:19 AM, "Elzur, Uri" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Reading the threads here, it may be good to take a moment to
>     discuss expectations out of a std process. To me, a “standard” is
>     about an industry agreement, on a path forward, in a timely
>     fashion, that paves the way (ushers in) the next wave of
>     innovation. Let me try to parse it
>
>     -Industry agreement: in singular (not in plural). The process is
>     to produce ONE agreed upon solution that ideally gives no party
>     any unfair advantage. It is conceivable, however, that leaders
>     retain some of the first mover advantage. If the outcome is
>     MULTITUDE of “standards”, and in this particular case, it may mean
>     simply documentation of 3 separate commercial camps where vendors
>     have created competing approaches, we may have missed the mark.
>
>     -In a timely fashion: One can’t ignore the time aspect. When the
>     std process is not moving fast enough, it jeopardizes the value of
>     the “industry agreement”. In the last years, a significant
>     productivity gains by the software development and open source,
>     enables much faster evolution, one risks therefore, a catch up
>     scenario, lost relevance and falling into documentation. The IETF
>     process has to be updated to cope with the faster evolution, so
>     that within a year of emerging open source direction (where
>     relevant) the WG has narrowed down the options to one and is very
>     close to being done. (yes, I know this is ideal…but this is what
>     is needed)
>
>     -Path forward: that is a suitable technical solution to a given
>     set of problems with a limited set of forward looking mechanism
>     based on experience ( the “limit” is really a judgment call to
>     help with the goal of timeliness); Including however, a reasonable
>     evolution of HW + SW. i.e. assuming HW (NICs in this case) is to
>     be of stagnant limited functionality (i.e. XSUM like feature
>     invented in 1996 – 20 years ago) as a base assumption, should not
>     be the lead assumption. IETF has historically been more SW
>     oriented, but data path encapsulation should not be SW only
>     discussion! Also the emergence of programmable HW and modeling of
>     HW to allow easier programming, means that the std may be relaxed
>     in terms of rigid assumptions of HW functionality. (also not to
>     ignore other aspects, in most cases, the std needs to be backwards
>     compatible to not break existing solutions)
>
>     -New innovation: a successful timely process, keeping pace with
>     If we have similar expectations, it may be easier to converge on
>     the complicated problem at hand. 3 options on the table for
>     prolonged time, where the HW and SW have already made progress. So
>     I for one, don’t think in THIS CASE, creating a 4^th option is the
>     way forward. We may be better served by picking one out of the
>     existing ones
>
>     Thx
>
>     Uri (“Oo-Ree”)
>
>     C: 949-378-7568 <tel:949-378-7568>
>
>     *From:*nvo3 [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Linda Dunbar
>     *To:* Anoop Ghanwani <[email-masked]
>     <mailto:[email-masked]>>; Bocci, Matthew (Nokia - GB)
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc:* NVO3 <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: [nvo3] Consensus call on moving forward with a
>     single encap.
>
>     +1.
>
>     *From:*nvo3 [mailto:[email-masked]] *On Behalf Of *Anoop
>     Ghanwani
>     *Subject:* Re: [nvo3] Consensus call on moving forward with a
>     single encap.
>
>     On Thu, Jul 21, 2016 at 7:52 AM, Bocci, Matthew (Nokia - GB)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     - Given the IETF's mission, should NVO3 move forward on the
>     standards track with a single encapsulation on the standards
>     track?  If not, please explain your concern in detail.
>
>     While the world would be a better place with only one
>     encapsulation, I think it's better to stick with the original path
>     of allowing the 3 encapsulations as experimental.
>
>     The NVO3 charter says:
>
>     >>>
>
>     Based on the charter, the WG has gone through the process of
>     accepting to work on 3 encapsulations.  What do we know now that
>     we did not know back then?
>
>     If we were going to progress only a single encapsulation, I think
>     there would have been more critical feedback and strong
>     suggestions for changing that "winning" encapsulation to
>     accommodate what the other encapsulations perceive as their
>     relative strengths.  And we risk opening up that discussion now
>     and delaying progress even more.
>
>     Otherwise, not having a standard has not been a hinderance for
>     getting protocols deployed in the past, and I suspect that if the
>     developers of these encapsulations care enough, we will see
>     deployments of all of them regardless of whether or not we
>     progress them within the working group.
>
>     Thanks,
>
>     Anoop
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Alia Atlas <[email-masked]>
Date: Sun, 24 Jul 2016 22:27:50 -0400

Hi Fabio,

Why do you believe that there is actual interest to work on or compromise
on a control plane?
I have seen no such evidence.  I can certainly agree that having a control
plane able to deal
with multiple encapsulations for backwards compatibility would be useful;
it does increase
complexity of the solution.

Having multiple encapsulations multiplies the complexity for everything on
top.

Regards,
Alia

On Sun, Jul 24, 2016 at 10:19 PM, Fabio Maino <[email-masked]> wrote:

> encapsulation will compound the problem rather than solving it, especially
> considering where the HW/SW implementations are today.
>
> encapsulations (such as VXLAN, for example) that will be around for quite
> some time.
>
> Fabio
>
>
>
>
>
>> -          Path forward: that is a suitable technical solution to a
>> given set of problems with a limited set of forward looking mechanism based
>> on experience ( the “limit” is really a judgment call to help with the goal
>> of timeliness); Including however, a reasonable evolution of HW + SW. i.e.
>> -          New innovation: a successful timely process, keeping pace
>> with the industry, with less vendor specific options will do the trick here…
>>
>>
>>
>> *To:* Anoop Ghanwani <[email-masked]>; Bocci, Matthew (Nokia -
>> GB) <[email-masked]>
> nvo3 mailing [email-masked]://www.ietf.org/mailman/listinfo/nvo3
>
>
>

---

From: Fabio Maino <[email-masked]>
Date: Sun, 24 Jul 2016 20:06:12 -0700

Hi Alia,
reality is that existing implementations do support multiple 
encapsulations already. To avoid adding complexity to the control plane 
then we mandate to add complexity to the data plane?

If work on or compromise on a control plane is out scope for NVO3, maybe 
the architecture should assume that the control plane (whichever it is) 
will take care of selecting the appropriate encapsulation. The control 
plane I know better (LISP) has a way to do this, so I assume the others 
will do as well.

Then it might be reasonable to publish the encapsulations as 
experimental, and let the deployments speak.

Fabio

On 7/24/16 7:27 PM, Alia Atlas wrote:
> Hi Fabio,
>
> Why do you believe that there is actual interest to work on or 
> compromise on a control plane?
> I have seen no such evidence.  I can certainly agree that having a 
> control plane able to deal
> with multiple encapsulations for backwards compatibility would be 
> useful; it does increase
> Having multiple encapsulations multiplies the complexity for 
> everything on top.
>
> Regards,
> Alia
>
> On Sun, Jul 24, 2016 at 10:19 PM, Fabio Maino <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I think Uri makes an important point when he says that adding a
>     4th encapsulation will compound the problem rather than solving
>     it, especially considering where the HW/SW implementations are today.
>
>     IMO this WG should focus on designing a control plane that allows
>     to discover and select the appropriate encapsulation, based on
>     receiver's capability.
>
>     Once that is done the overall architecture will be able to deal
>     with multiple encapsulations, and more than one can be moved to
>     standard track.
>
>     encapsulations (such as VXLAN, for example) that will be around
>     for quite some time.
>
>     Fabio
>
>
>
>
>
>>     We do need to understand significant technical objections to
>>     whatever existing solution might be stated from.
>>
>>         discuss expectations out of a std process. To me, a
>>         “standard” is about an industry agreement, on a path forward,
>>         in a timely fashion, that paves the way (ushers in) the next
>>         wave of innovation. Let me try to parse it
>>
>>         -Industry agreement: in singular (not in plural). The process
>>         is to produce ONE agreed upon solution that ideally gives no
>>         party any unfair advantage. It is conceivable, however, that
>>         leaders retain some of the first mover advantage. If the
>>         outcome is MULTITUDE of “standards”, and in this particular
>>         case, it may mean simply documentation of 3 separate
>>         commercial camps where vendors have created competing
>>         approaches, we may have missed the mark.
>>
>>         -In a timely fashion: One can’t ignore the time aspect. When
>>         the std process is not moving fast enough, it jeopardizes the
>>         value of the “industry agreement”. In the last years, a
>>         significant productivity gains by the software development
>>         and open source, enables much faster evolution, one risks
>>         therefore, a catch up scenario, lost relevance and falling
>>         into documentation. The IETF process has to be updated to
>>         cope with the faster evolution, so that within a year of
>>         emerging open source direction (where relevant) the WG has
>>         narrowed down the options to one and is very close to being
>>         done. (yes, I know this is ideal…but this is what is needed)
>>
>>         -Path forward: that is a suitable technical solution to a
>>         given set of problems with a limited set of forward looking
>>         mechanism based on experience ( the “limit” is really a
>>         judgment call to help with the goal of timeliness); Including
>>         however, a reasonable evolution of HW + SW. i.e. assuming HW
>>         (NICs in this case) is to be of stagnant limited
>>         functionality (i.e. XSUM like feature invented in 1996 – 20
>>         years ago) as a base assumption, should not be the lead
>>         assumption. IETF has historically been more SW oriented, but
>>         data path encapsulation should not be SW only discussion!
>>         Also the emergence of programmable HW and modeling of HW to
>>         allow easier programming, means that the std may be relaxed
>>         in terms of rigid assumptions of HW functionality. (also not
>>         to ignore other aspects, in most cases, the std needs to be
>>         backwards compatible to not break existing solutions)
>>
>>         -New innovation: a successful timely process, keeping pace
>>         If we have similar expectations, it may be easier to converge
>>         on the complicated problem at hand. 3 options on the table
>>         for prolonged time, where the HW and SW have already made
>>         progress. So I for one, don’t think in THIS CASE, creating a
>>         4^th option is the way forward. We may be better served by
>>         picking one out of the existing ones
>>
>>         Thx
>>
>>         Uri (“Oo-Ree”)
>>
>>         *From:*nvo3 [mailto:[email-masked]] *On Behalf Of
>>         *Anoop Ghanwani
>>         encapsulation, I think it's better to stick with the original
>>         path of allowing the 3 encapsulations as experimental.
>>
>>         The NVO3 charter says:
>>
>>         >>>
>>
>>         accepting to work on 3 encapsulations.  What do we know now
>>         that we did not know back then?
>>
>>         If we were going to progress only a single encapsulation, I
>>         think there would have been more critical feedback and strong
>>         relative strengths.  And we risk opening up that discussion
>>         now and delaying progress even more.
>>
>>         Otherwise, not having a standard has not been a hinderance
>>         for getting protocols deployed in the past, and I suspect
>>         that if the developers of these encapsulations care enough,
>>         we will see deployments of all of them regardless of whether
>>         or not we progress them within the working group.
>>
>>         Thanks,
>>
>>         Anoop
>>
>>

---

From: Anoop Ghanwani <[email-masked]>
Date: Sun, 24 Jul 2016 21:37:18 -0700

3 options on the table for prolonged time, where the HW and SW have already
made progress.

I think this is a key point.  There are already implementations that have
been built to handle one or more of these encapsulations.

Not to minimize the importance of the IETF, but to the average person in
the field, there is little difference between an individual draft
submission hosted at ietf.org, and a standards track RFC.  To most
(non-IETF) people, VXLAN is already a standard blessed by the IETF, as is
OTV.

I'm not seeing the benefit of progressing only a single encap at this
stage.  It's too late in the game.

Anoop

---

From: Lou Berger <[email-masked]>
Date: Mon, 25 Jul 2016 09:08:43 -0400

If I understand Fabio's position correctly, I agree. 

My interest in NVO3 is strictly limited to the control plane. In our
(open source) BGP-based implementation, we too are agnostic on
encapsulation and allow compatible endpoints to communicate. 

I personally see value in NVO3 allowing for any encapsulation - at least
at the architecture and control plane levels --  independent of the
current data plane (encap) discussion.

Lou

On 7/24/2016 11:06 PM, Fabio Maino wrote:
> encapsulations already. To avoid adding complexity to the control
> plane then we mandate to add complexity to the data plane?
>
> If work on or compromise on a control plane is out scope for NVO3,
> maybe the architecture should assume that the control plane (whichever
> it is) will take care of selecting the appropriate encapsulation. The
> control plane I know better (LISP) has a way to do this, so I assume
> the others will do as well.
>
>>>         “standard” is about an industry agreement, on a path
>>>         forward, in a timely fashion, that paves the way (ushers in)
>>>         the next wave of innovation. Let me try to parse it
>>>
>>>          
>>>
>>>         -          Industry agreement: in singular (not in plural).
>>>         The process is to produce ONE agreed upon solution that
>>>         ideally gives no party any unfair advantage. It is
>>>         conceivable, however, that leaders retain some of the first
>>>         mover advantage. If the outcome is MULTITUDE of “standards”,
>>>         and in this particular case, it may mean simply
>>>         documentation of 3 separate commercial camps where vendors
>>>         -          In a timely fashion: One can’t ignore the time
>>>         aspect. When the std process is not moving fast enough, it
>>>         jeopardizes the value of the “industry agreement”. In the
>>>         last years, a significant productivity gains by the software
>>>         development and open source, enables much faster evolution,
>>>         one risks therefore, a catch up scenario, lost relevance and
>>>         falling into documentation. The IETF process has to be
>>>         updated to cope with the faster evolution, so that within a
>>>         year of emerging open source direction (where relevant) the
>>>         WG has narrowed down the options to one and is very close to
>>>         -          Path forward: that is a suitable technical
>>>         solution to a given set of problems with a limited set of
>>>         forward looking mechanism based on experience ( the “limit”
>>>         is really a judgment call to help with the goal of
>>>         timeliness); Including however, a reasonable evolution of HW
>>>         + SW. i.e. assuming HW (NICs in this case) is to be of
>>>         stagnant limited functionality (i.e. XSUM like feature
>>>         invented in 1996 – 20 years ago) as a base assumption,
>>>         should not be the lead assumption. IETF has historically
>>>         been more SW oriented, but data path encapsulation should
>>>         not be SW only discussion! Also the emergence of
>>>         programmable HW and modeling of HW to allow easier
>>>         programming, means that the std may be relaxed in terms of
>>>         rigid assumptions of HW functionality. (also not to ignore
>>>         other aspects, in most cases, the std needs to be backwards
>>>         -          New innovation: a successful timely process,
>>>         keeping pace with the industry, with less vendor specific
>>>         options will do the trick here…
>>>
>>>          
>>>
>>>         If we have similar expectations, it may be easier to
>>>         converge on the complicated problem at hand. 3 options on
>>>         the table for prolonged time, where the HW and SW have
>>>         already made progress. So I for one, don’t think in THIS
>>>         CASE, creating a 4^th option is the way forward. We may be
>>>         better served by picking one out of the existing ones
>>>
>>>          
>>>
>>>         Thx
>>>
>>>          
>>>
>>>         Uri (“Oo-Ree”)
>>>
>>>         *Subject:* Re: [nvo3] Consensus call on moving forward with
>>>         a single encap.
>>>
>>>          
>>>
>>>         +1.
>>>
>>>          
>>>
>>>         *Subject:* Re: [nvo3] Consensus call on moving forward with
>>>         a single encap.
>>>
>>>          
>>>
>>>          
>>>
>>>          
>>>
>>>         wrote:
>>>         encapsulation, I think it's better to stick with the
>>>         original path of allowing the 3 encapsulations as
>>>         experimental.  
>>>
>>>          
>>>
>>>         The NVO3 charter says:
>>>
>>>         >>> 
>>>
>>>         think there would have been more critical feedback and
>>>         strong suggestions for changing that "winning" encapsulation
>>>         to accommodate what the other encapsulations perceive as
>>>         their relative strengths.  And we risk opening up that
> This body part will be downloaded on demand.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 25 Jul 2016 09:34:39 -0400

Hi Fabio,

Thanks for the discussion.  I think that it is really important to share
our different perspectives
so that we can end up someplace beneficial for the industry.

I am encouraging very active discussion on the control plane - including
having some virtual
interims to educate folks on all the different options out there.  So far,
there has been very little
discussion on what is being used or what might be brought in as potential
starting points.  Of course,
work has actively progressed on a BGP control-plane based solution in BESS,
since that discussion
was removed from NVO3 - but there was very far from any agreement that the
BGP-based approach was the way to go.  Perhaps there are changes in
perception as BGP is increasingly common in data-centers.

Work on a control plane solution is absolutely in scope for NVO3 - but I
have not seen it happening and
I have strong concerns about whether this group can come to consensus on
anything implementable.

As far as publishing existing encapsulations as Experimental, I do not see
any experiments that would cause us to reevaluate and think that
Informational is more accurate.  In either case, it does not provide a
solid standards-track basis for additional work.

Regards,
Alia

On Sun, Jul 24, 2016 at 11:06 PM, Fabio Maino <[email-masked]> wrote:

> Then it might be reasonable to publish the encapsulations as experimental,
> and let the deployments speak.
>
> Fabio
>
>
>
>
>
>
>>> in THIS CASE, creating a 4th option is the way forward. We may be
>>> Based on the charter, the WG has gone through the process of accepting
>>> to work on 3 encapsulations.  What do we know now that we did not know back
>>> then?
>>>
>>>
>>>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 25 Jul 2016 09:38:44 -0400

Hi Lou,

I agree that we have to accept the complexity of the control plane handling
multiple
encapsulations given the advanced state of proprietary solutions in
deployment.

On the encapsulations side, I do think that it is not too late - even if
the impact of
making a decision for a single standard may be 2-5 years out.  There
continue to
be more greenfield data-centers built and hardware refreshes of existing
ones.

Regards,
Alia

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 25 Jul 2016 14:21:24 +0000

Anoop,

You raise valid, and important points.  We cannot ignore the existing implementations, and quite frankly there is no reason to.  As we learned with VXLAN, implementation/deployment speak loudly.  There is no good reason to not select  the so-called option 1.  As I stated early, this is the pragmatic answer.

Paul

On Jul 25, 2016, at 12:37 AM, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>> wrote:

3 options on the table for prolonged time, where the HW and SW have already made progress.

I think this is a key point.  There are already implementations that have been built to handle one or more of these encapsulations.

Not to minimize the importance of the IETF, but to the average person in the field, there is little difference between an individual draft submission hosted at ietf.org<http://ietf.org/>, and a standards track RFC.  To most (non-IETF) people, VXLAN is already a standard blessed by the IETF, as is OTV.

I'm not seeing the benefit of progressing only a single encap at this stage.  It's too late in the game.

Anoop

On Sun, Jul 24, 2016 at 2:18 AM, Elzur, Uri <[email-masked]<mailto:[email-masked]>> wrote:
Reading the threads here, it may be good to take a moment to discuss expectations out of a std process. To me, a “standard” is about an industry agreement, on a path forward, in a timely fashion, that paves the way (ushers in) the next wave of innovation. Let me try to parse it

Thx

Uri (“Oo-Ree”)
C: 949-378-7568<tel:949-378-7568>

From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Linda Dunbar
Sent: Friday, July 22, 2016 1:11 PM
To: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>; Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Cc: NVO3 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Consensus call on moving forward with a single encap.

+1.

Linda

The NVO3 charter says:

Thanks,
Anoop

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Alia Atlas <[email-masked]>
Date: Mon, 25 Jul 2016 10:35:48 -0400

Paul,

Option 1 is giving up on the Standards process and waiting until the market
has
decided.

There are always pre-standard implementations and deployments.  Regrettably,
there are more than would have been the case had better discussion happened
earlier in NVO3.

Regards,
Alia

On Mon, Jul 25, 2016 at 10:21 AM, Paul Quinn (paulq) <[email-masked]>
wrote:

> Anoop,
>
> You raise valid, and important points.  We cannot ignore the existing
> implementations, and quite frankly there is no reason to.  As we learned
> with VXLAN, implementation/deployment speak loudly.  There is no good
> reason to not select  the so-called option 1.  As I stated early, this is
> the pragmatic answer.
>
> Paul
>
> On Jul 25, 2016, at 12:37 AM, Anoop Ghanwani <[email-masked]>
> wrote:
>
> >>>

---

From: Lou Berger <[email-masked]>
Date: Mon, 25 Jul 2016 11:35:37 -0400

Hi Alia,

> encapsulations given the advanced state of proprietary solutions in

We already have multiple standard encapsulation too.  See the ones covered 
by rfc5512 and 5566 as examples.

Lou

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 25 Jul 2016 10:51:54 -0700

Hi Alia,

On Mon, Jul 25, 2016 at 7:35 AM, Alia Atlas <[email-masked]> wrote:
>
>
> Option 1 is giving up on the Standards process and waiting until the
> market has
> decided.
>

I view things a little differently.  While it would have been good for the
standards process to produce a single encapsulation, and it has not
delivered that, it is still useful with respect to providing a forum to
discuss these encapsulations and make sure a given encapsulation doesn't do
something that is broken.  An example was the recent fix to Geneve to make
sure that it always does the right thing with ECN.  So there's still value
in the standardization process.

Anoop

---

From: Fabio Maino <[email-masked]>
Date: Mon, 25 Jul 2016 11:42:57 -0700

On 7/25/16 6:34 AM, Alia Atlas wrote:
> Hi Fabio,
>
> Thanks for the discussion.  I think that it is really important to 
> share our different perspectives
> I am encouraging very active discussion on the control plane - 
> including having some virtual
> interims to educate folks on all the different options out there.  So 
> far, there has been very little
> discussion on what is being used or what might be brought in as 
> potential starting points.  Of course,
> work has actively progressed on a BGP control-plane based solution in 
> BESS, since that discussion
> was removed from NVO3 - but there was very far from any agreement that 
> the BGP-based approach was the way to go. Perhaps there are changes in 

At that same time LISP was removed from NVO3 too. Since then there are 
various LISP based implementations deployed in data centers, and various 
drafts have been proposed to the LISP WG  (including work that addresses 
the issue of multiple encaps). With the new LISP WG charter, I believe 
we have an opportunity to formalize that work and get it adopted as a WG 
item. I would expect that work to progress in the LISP WG, though.

>
> Work on a control plane solution is absolutely in scope for NVO3 - but 
> I have not seen it happening and
> I have strong concerns about whether this group can come to consensus 
> on anything implementable.

maybe because that space is already taken by BESS and LISP, and there 
isn't enough traction to have a third one?

>
> As far as publishing existing encapsulations as Experimental, I do not 
> see any experiments that would cause us to reevaluate and think that 

Informational will be fine. We dealt half a decade with VXLAN and NVGRE 
as a draft, getting quickly to an informational RFC would be a good step 
forward.

Fabio

>
> Regards,
> Alia
>
> On Sun, Jul 24, 2016 at 11:06 PM, Fabio Maino <[email-masked] 
>     maybe the architecture should assume that the control plane
>     (whichever it is) will take care of selecting the appropriate
>     encapsulation. The control plane I know better (LISP) has a way to
>     do this, so I assume the others will do as well.
>
>>     I have seen no such evidence.  I can certainly agree that having
>>     a control plane able to deal
>>         I think Uri makes an important point when he says that adding
>>         a 4th encapsulation will compound the problem rather than
>>         solving it, especially considering where the HW/SW
>>         implementations are today.
>>
>>         IMO this WG should focus on designing a control plane that
>>         allows to discover and select the appropriate encapsulation,
>>         based on receiver's capability.
>>
>>         Once that is done the overall architecture will be able to
>>         deal with multiple encapsulations, and more than one can be
>>         moved to standard track.
>>
>>         This kind of work will also help with backward compatibility
>>         with encapsulations (such as VXLAN, for example) that will be
>>         around for quite some time.
>>
>>         Fabio
>>
>>
>>
>>
>>
>>>         Unfortunately,  the solutions haven't responded to much
>>>         input or changed from the WG yet.
>>>
>>>         Regards,
>>>         Alia
>>>
>>>
>>>             Reading the threads here, it may be good to take a
>>>             moment to discuss expectations out of a std process. To
>>>             me, a “standard” is about an industry agreement, on a
>>>             path forward, in a timely fashion, that paves the way
>>>             -Industry agreement: in singular (not in plural). The
>>>             process is to produce ONE agreed upon solution that
>>>             conceivable, however, that leaders retain some of the
>>>             first mover advantage. If the outcome is MULTITUDE of
>>>             “standards”, and in this particular case, it may mean
>>>             simply documentation of 3 separate commercial camps
>>>             where vendors have created competing approaches, we may
>>>             have missed the mark.
>>>
>>>             -In a timely fashion: One can’t ignore the time aspect.
>>>             When the std process is not moving fast enough, it
>>>             jeopardizes the value of the “industry agreement”. In
>>>             the last years, a significant productivity gains by the
>>>             software development and open source, enables much
>>>             faster evolution, one risks therefore, a catch up
>>>             scenario, lost relevance and falling into documentation.
>>>             The IETF process has to be updated to cope with the
>>>             faster evolution, so that within a year of emerging open
>>>             source direction (where relevant) the WG has narrowed
>>>             down the options to one and is very close to being done.
>>>             (yes, I know this is ideal…but this is what is needed)
>>>
>>>             -Path forward: that is a suitable technical solution to
>>>             a given set of problems with a limited set of forward
>>>             looking mechanism based on experience ( the “limit” is
>>>             really a judgment call to help with the goal of
>>>             timeliness); Including however, a reasonable evolution
>>>             of HW + SW. i.e. assuming HW (NICs in this case) is to
>>>             be of stagnant limited functionality (i.e. XSUM like
>>>             feature invented in 1996 – 20 years ago) as a base
>>>             assumption, should not be the lead assumption. IETF has
>>>             historically been more SW oriented, but data path
>>>             encapsulation should not be SW only discussion! Also the
>>>             emergence of programmable HW and modeling of HW to allow
>>>             easier programming, means that the std may be relaxed in
>>>             terms of rigid assumptions of HW functionality. (also
>>>             not to ignore other aspects, in most cases, the std
>>>             needs to be backwards compatible to not break existing
>>>             solutions)
>>>
>>>             -New innovation: a successful timely process, keeping
>>>             pace with the industry, with less vendor specific
>>>             converge on the complicated problem at hand. 3 options
>>>             on the table for prolonged time, where the HW and SW
>>>             have already made progress. So I for one, don’t think in
>>>             THIS CASE, creating a 4^th option is the way forward. We
>>>             may be better served by picking one out of the existing ones
>>>
>>>             Thx
>>>
>>>             Uri (“Oo-Ree”)
>>>
>>>             <mailto:[email-masked]>>; Bocci, Matthew (Nokia -
>>>             GB) <[email-masked]
>>>             <mailto:[email-masked]>>
>>>             *Subject:* Re: [nvo3] Consensus call on moving forward
>>>             with a single encap.
>>>
>>>             +1.
>>>
>>>             *Subject:* Re: [nvo3] Consensus call on moving forward
>>>             with a single encap.
>>>
>>>             On Thu, Jul 21, 2016 at 7:52 AM, Bocci, Matthew (Nokia -
>>>             GB) <[email-masked]
>>>             <mailto:[email-masked]>> wrote:
>>>
>>>
>>>             - Given the IETF's mission, should NVO3 move forward on
>>>             the standards track with a single encapsulation on the
>>>             standards track?  If not, please explain your concern in
>>>             detail.
>>>
>>>             Based on the charter, the WG has gone through the
>>>             process of accepting to work on 3 encapsulations.  What
>>>             do we know now that we did not know back then?
>>>
>>>             If we were going to progress only a single
>>>             encapsulation, I think there would have been more
>>>             critical feedback and strong suggestions for changing
>>>             that "winning" encapsulation to accommodate what the
>>>             other encapsulations perceive as their relative
>>>             strengths. And we risk opening up that discussion now
>>>             Otherwise, not having a standard has not been a
>>>             hinderance for getting protocols deployed in the past,
>>>             and I suspect that if the developers of these
>>>             encapsulations care enough, we will see deployments of
>>>             all of them regardless of whether or not we progress
>>>             them within the working group.
>>>
>>>             Thanks,
>>>
>>>             Anoop
>>>
>>>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 26 Jul 2016 09:40:39 +0000

Alia,

> On Jul 25, 2016, at 10:35 AM, Alia Atlas <[email-masked]> wrote:
> 
> Paul,
> 
> Option 1 is giving up on the Standards process and waiting until the market has
> decided.  
> 

Perhaps another way to look at this is: in the real world multiple options exist to solve / address different requirements.  This isn't a bad thing, and we, as a community recognize that. 

Further, given the implementation realities of the protocols, it is disheartening to see the value of running code diminished/ing at the IETF.

Paul

---

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Jul 2016 07:18:18 -0400

Paul,

Alternately,  it is disheartening to see an expectation that solutions
coming in will simply be rubber-stamped after enough time with no
improvement.

It's rough consensus & running code, after all.

Regards,
Alia

On Jul 26, 2016 5:40 AM, "Paul Quinn (paulq)" <[email-masked]> wrote:

> Perhaps another way to look at this is: in the real world multiple options
> exist to solve / address different requirements.  This isn't a bad thing,
> and we, as a community recognize that.
>
> Further, given the implementation realities of the protocols, it is
> disheartening to see the value of running code diminished/ing at the IETF.
>
> Paul
>
>
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 26 Jul 2016 16:07:03 +0200

Folks,

made
I don't like this discussion, it reminds mean about dog fighting. Two dogs that could well together, for example pulling a sleigh are made to fight each other. Standards will never work unless we have the market that will eventually decide, the market can ever decide unless we have working standard to guide. 

/Loa

Sent from my iPhone

> On 26 juli 2016, at 13:18, Alia Atlas <[email-masked]> wrote:
> 
> Paul,
> 
> Alternately,  it is disheartening to see an expectation that solutions coming in will simply be rubber-stamped after enough time with no improvement.
>