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 On Mon, Jul 25, 2016 at 9:08 AM, Lou Berger <[email protected]> wrote: > 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. > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
