Anoop,
On Wed, Oct 5, 2016 at 9:15 PM, Anoop Ghanwani <an...@alumni.duke.edu> wrote: > Sam, > > Sam, > > How are the encapsulations supposed to address technical concerns of the > nature "too hard to implement", especially when implementations already > exist? > >From various conversations, the sentiment of 'too hard to implement' is not shared by everyone, that includes silicon vendors supporting different encap types. There were discussions over the mailing list about some of those points as well. I'd look it from different perspective i.e. don't pick a solution and fit in the requirements, rather, pick a solution which could meet the requirements. Hard, simple, easy etc is a subjective matter and depends on whom you ask. That is the reason why the request for technical objections were requested. Having implemented protocols, different versions and changes is a PITA. But that is the nature of moving things. > One can always add extensions to those proposals to address the other > concerns (e.g. VNI not secure, insufficient extensibility, etc.). Whether > those are added now or in the future is immaterial. > Immaterial? That is not how networks are deployed/operated, may be in the lab. > If all 3 encaps are willing to address the concern, then we end up with 6 > encaps. Which will we pick then? > RFC7282 -sam > > I was responding to this statement from the original email. > >>> > We would like to hear opinions and confirmation or disagreement on > interest in creating a DP encapsulation that addresses the various > technical concerns. > >>> > I still think we are better off with the 3 encapsulations as is, then we > would be if had 4 or 6 encapsulations. > Anoop > > On Wed, Oct 5, 2016 at 7:01 PM, Sam Aldrin <aldrin.i...@gmail.com> wrote: > >> Anoop, >> >> Comments inline, as individual contributor. >> >> On Wed, Oct 5, 2016 at 3:23 PM, Anoop Ghanwani <an...@alumni.duke.edu> >> wrote: >> >>> Sam, >>> >>> We can't live with VXLAN because of lack of extensibility--that is one >>> thing all 3 proposals agree on. >>> >>> Let's look at how we got here: >>> >>> The NVO3 charter explicitly mentioned that picking (or working on) a >>> single encap is a non-goal. Now the WG has done all the work and arrived >>> at 3 encaps (even 3 is a convergence; there were even more). It would have >>> been hard to get convergence to a single encap even back then. Now, after >>> all this work, not just in the IETF but actual implementations, I think >>> it's next to impossible to get convergence. I would be absolutely thrilled >>> if I were proven wrong. >>> >>> Also, just because the NVO3 WG comes up with an encapsulation does not >>> mean that there won't be NVO3-like implementations using e.g. L2TPv3 or >>> LISP encapsulations (and those encapsulations are IETF standards). >>> >> >> On the contrary, RFC stamping three proposals doesn't solve those issues >> either. >> >>> >>> These are the possibilities I see for the WG and also how I see them >>> playing out: >>> >>> 1. Publish 3 RFCs -- path of least resistance. All 3 encaps go through >>> IETF rigor (security review, etc.). >>> >> Why waste WG's time, when technical objections cannot be addressed? >> >> 2. Work on a single encap -- probably a year or two before we have a >>> standard? In the meantime the 3 drafts continue to get deployed even >>> though they expire. The new encap may or may not see the light of day. >>> Best case it ends up as 4th encap. Chances are the earlier encaps will >>> continue to evolve on their own, each becoming a defacto standard. >>> >> Take the scenario, as you suggested, WG reviews the documents and >> suggests certain changes to format. Does that create new protocol? Do >> you/authors have objections to incorporate those changes? How different is >> that situation from the 4th encap as you say? >> >> OR are you saying, WG should just do the nit checking and make them RFC >> without making changes to encap format. If so, why bother to go through WG >> process? >> >> >>> 3. Do nothing. Let the drafts expire. So why did we do all this work? >>> >> Not every draft is bound to become a standard or every effort should be >> reflected as RFC. >> If there is a need for 3 standard encaps, I am ok, but with a big caveat. >> As a user, would like to see technical justification for the existence of >> 3 encap types, as opposed to business justification you mentioned in >> previous email. >> >> >>> I picked #1. If we pick #2 or #3, if the authors want to publish them >>> as individual submissions, they are free to do so and get RFC numbers >>> anyway. >>> >> Sure. That is the option everyone has. VXLAN went through that process >> and created problem statement for new encap types. >> >>> >>> What are the options that you see and what would be your recommendation >>> for the way forward? >>> >> Plan is as suggested in the original email. Hopefully, we could derive an >> agreement and move forward. >> >> -sam >> >>> >>> Anoop >>> >>> On Wed, Oct 5, 2016 at 10:29 AM, Sam Aldrin <aldrin.i...@gmail.com> >>> wrote: >>> >>>> Anoop, >>>> >>>> As I said in one my earlier emails, if new encap proposals are not >>>> converging on resolving issues, why don't we just live with existing encaps >>>> like VXLAN etc? Why would making these RFC'es is important by standards >>>> body, when it is about business rather than technical ones? >>>> >>>> Backward compatibility, extensibility, security, etc., issues are very >>>> important and the degree vary depending on whom you ask, for ex: operator >>>> to vendor, software to hardware. That is whole new discussion and beyond >>>> this thread, but those are the reasons for not reaching rough consensus. >>>> (Ref: mailing list and summary) >>>> >>>> I personally do not think WG should just *stamp RFC for drafts because >>>> of business reasons. >>>> >>>> -sam >>>> >>>> On Wed, Oct 5, 2016 at 9:54 AM, Anoop Ghanwani <an...@alumni.duke.edu> >>>> wrote: >>>> >>>>> Sam, >>>>> >>>>> My lack of interest in a new encap is because I think it's too late to >>>>> converge them. At this point, there are business issues (as opposed to >>>>> technical ones) that would limit the effectiveness of a new encap. At >>>>> best >>>>> it's a no-op, at worst it creates even more confusion in the market while >>>>> the other encaps continue with their deployment. >>>>> >>>>> The best that the IETF can do is at this point is to document these >>>>> and make sure the encaps are not breaking something else. >>>>> >>>>> IMO, none of the objections raised are showstoppers. Any encap can be >>>>> modified to do anything we want it to do, with the exception of backwards >>>>> compatibility. The need, efficacy, and the price of backwards >>>>> compatibility can be argued, so that advantage is not a slam dunk either. >>>>> >>>>> Anoop >>>>> >>>>> On Tue, Oct 4, 2016 at 9:49 PM, Sam Aldrin <aldrin.i...@gmail.com> >>>>> wrote: >>>>> >>>>>> Anoop, >>>>>> >>>>>> <WG chair hat off> >>>>>> Couple of questions, if I may ask >>>>>> 1. How do you plan to address technical objections raised? >>>>>> 2. Not interested because it is too late and would rather live with >>>>>> any deficiencies in the DP proposals? >>>>>> </WG chair hat off> >>>>>> >>>>>> -sam >>>>>> On Tue, Oct 4, 2016 at 11:48 AM, Anoop Ghanwani < >>>>>> an...@alumni.duke.edu> wrote: >>>>>> >>>>>>> On Tue, Oct 4, 2016 at 2:24 AM, Bocci, Matthew (Nokia - GB) < >>>>>>> matthew.bo...@nokia.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Unfortunately, no rough consensus emerged from the list discussion. >>>>>>>> >>>>>>>> The chairs and our AD have also been trying to form a design team >>>>>>>> to take forward the encapsulation discussion and see if there is >>>>>>>> potential >>>>>>>> to design a common encapsulation. However, there has been insufficient >>>>>>>> interest in this initiative. We would like to hear opinions and >>>>>>>> confirmation or disagreement on interest in creating a DP encapsulation >>>>>>>> that addresses the various technical concerns. >>>>>>>> >>>>>>>> >>>>>>> I have little interest in yet another encap. >>>>>>> >>>>>>> Anoop >>>>>>> >>>>>>> _______________________________________________ >>>>>>> nvo3 mailing list >>>>>>> nvo3@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>> >>>> >>> >> >
_______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
