See inline. From: nvo3 [mailto:[email protected]] On Behalf Of Sam Aldrin Sent: Wednesday, October 05, 2016 1:11 PM To: Fedyk, Don Cc: Bocci, Matthew (Nokia - GB); Anoop Ghanwani; NVO3 Subject: Re: [nvo3] Discussion on encapsulation formats and next steps
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 :-( [Lucy] This is not just fixing with few bits. One VXLAN protocol deficiency is the ability to encapsulate IP packets. Lucy -sam On Wed, Oct 5, 2016 at 11:04 AM, Fedyk, Don <[email protected]<mailto:[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]<mailto:[email protected]>] On Behalf Of Sam Aldrin Sent: Wednesday, October 05, 2016 1:29 PM To: Anoop Ghanwani <[email protected]<mailto:[email protected]>> Cc: Bocci, Matthew (Nokia - GB) <[email protected]<mailto:[email protected]>>; NVO3 <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: On Tue, Oct 4, 2016 at 2:24 AM, Bocci, Matthew (Nokia - GB) <[email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
