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 protected]<mailto:[email protected]>> 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 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 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<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] https://www.ietf.org/mailman/listinfo/nvo3
