Don, VXLAN didn't go through WG route.
Agree that, existing one is broken. The whole effort (with 3 encaps out there) is to fix what is broken, with a degree of variance. Summary of issues describes why it is not just about fixing with few bits :-( -sam On Wed, Oct 5, 2016 at 11:04 AM, Fedyk, Don <[email protected]> wrote: > Hi Sam > > > > By publishing VXLAN informational RFC with 32 bits of reserved + Reserved > Flag bits the IETF invited this situation. It is inevitable we now need to > define the meaning of some of those bits (or even expand the header with > TLVs, sigh). The WG agreeing on the interpretation of some bits in VXLAN > can add clarity at this point IMHO. Also they are just > informational/experimental RFCs. > > > > (Agreeing with Anoop) > > Cheers, > > Don > > > > *From:* nvo3 [mailto:[email protected]] *On Behalf Of *Sam Aldrin > *Sent:* Wednesday, October 05, 2016 1:29 PM > *To:* Anoop Ghanwani <[email protected]> > *Cc:* Bocci, Matthew (Nokia - GB) <[email protected]>; NVO3 < > [email protected]> > *Subject:* Re: [nvo3] Discussion on encapsulation formats and next steps > > > > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > wrote: > > On Tue, Oct 4, 2016 at 2:24 AM, Bocci, Matthew (Nokia - GB) < > [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
