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