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:
> 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
>> 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 protected]
>> <mailto:[email protected]>> 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.
>>
>> 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:
>>>
>>> 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 protected]
>>> <mailto:[email protected]>> 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 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 protected]
>>> <mailto:[email protected]>] *On Behalf Of *Linda Dunbar
>>> *Sent:* Friday, July 22, 2016 1:11 PM
>>> *To:* Anoop Ghanwani <[email protected]
>>> <mailto:[email protected]>>; Bocci, Matthew (Nokia - GB)
>>> <[email protected] <mailto:[email protected]>>
>>> *Cc:* NVO3 <[email protected] <mailto:[email protected]>>
>>> *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 protected]] *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 protected] <mailto:[email protected]>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> nvo3 mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>
>>>
>>>
>>> _______________________________________________
>>> nvo3 mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>
>
>
> This body part will be downloaded on demand.
