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
