“The problem with standards is that there are many standards”. I forgot who coined the phrase but its an old phrase.
Sad but true, Dino > On Oct 7, 2016, at 9:23 AM, Behcet Sarikaya <[email protected]> wrote: > > Anoop wrote on Oct. 4 > > I have little interest in yet another encap. > > > Now Anoop is arguing for another encap or encaps. > I don't understand why this change of heart happened? > Of course we have freedom to change mind. > > Behcet > > On Thu, Oct 6, 2016 at 5:11 PM, Anoop Ghanwani <[email protected]> wrote: >> Hi Alia, >> >> Please see inline. >> >> Anoop >> >> On Thu, Oct 6, 2016 at 10:29 AM, Alia Atlas <[email protected]> wrote: >>> >>> Anoop, >>> >>> On Thu, Oct 6, 2016 at 12:58 PM, Anoop Ghanwani <[email protected]> >>> wrote: >>>> >>>> Alia, >>>> >>>> The obvious way to handle multiple DCs with different encap is to use a >>>> gateway. The simplest gateway would terminate one encap domain and start >>>> another. OAM, etc. would work within a domain. To work across domains, >>>> OAM >>>> would have to be run at a higher layer. This is not too much different >>>> than, e.g., mapping from 802.1ah/PBB to MPLS. >>> >>> >>> So the least common functionality is all that could be assumed? No >>> extensions or additional information would be easy to translate. OAM - even >>> for things like Path MTU discovery(that matter more if going across a public >>> Internet between data-centers) - would not work? What higher layer would >>> you see the OAM working at? Do you have a proposed solution or even >>> brainstormy ideas? >> >> >> Yes, least common functionality would have to be assumed. Even if we come >> up with encap 4, it will have so many options that most implementations with >> implement only a subset of them. So we will be stuck with the same issue >> even with a single encap. So, the important point here is that single encap >> with 10 options doesn't mean all implementations implement all 10 options. >> >> OAM will work in the same way that it works today when translating between >> PBB and MPLS/VPLS. We have OAM running within PBB, OAM running within MPLS, >> and OAM running end to end. >> >>> >>> >>>> Running multiple encaps within a single DC would be done under >>>> supervision of the NVA. The NVA would keep track of which NVEs are capable >>>> of a given encap and make sure that a given encap is used only when both >>>> the >>>> source and destination NVEs can support it. >>> >>> >>> Your answer assumes that there is no need for the underlay network to >>> understand the encapsulation. It also ignores any issues around multicast. >>> >>> Can we explore both of them? >>> >> >> The underlay network (aside from the gateways) should not need to understand >> encapsulation. There will always be hacky solutions that are encap aware >> that claim to do more than the standard underlay, but IMO they won't be the >> norm. >> >> Multicast is an interesting one. First there are several ways to solve >> multicast. Since encap is per source/dest, it won't be an issue for either >> head end replication or replication via a multicast service node. The only >> case where it might be a problem with multicast in the underlay and only if >> there is a non-intersecting set of encapsulations between the receivers. >> There are several solutions like have multiple groups or using a >> gateway...of course this is just off the top of my head. Again, complexity, >> but not an insurmountable problem, and I'm probably trivializing it >> somewhat. >> >>> >>> >>>> >>>> It adds complexity but the problems are not insurmountable. >>> >>> >>> I hear you - so let's talk about what the problems are and the theoretical >>> benefits? >>> >>> >>>> >>>> Anoop >>>> >>>> On Thu, Oct 6, 2016 at 7:10 AM, Alia Atlas <[email protected]> wrote: >>>>> >>>>> A concern is what is lost by having multiple encapsulation? Do we >>>>> require that a NVE understands the >>>>> encapsulation to send to a receiver beyond a physical gateway? Do we >>>>> lose the ability to do traceroute >>>>> well (or with enough information) if transit devices don't understand >>>>> the particular encapsulation? What >>>>> are the effects if going between multiple data-centers? >>>>> >>>>> What are the implications if there are different limitations on the >>>>> number of bytes available for TLVs in >>>>> an encapsulation - based upon the implementation? I've heard that this >>>>> is the case for Geneve. >>>>> >>>>> Is there an assumption that transit and gateway nodes don't need to >>>>> understand the overlay encapsulation? >>>>> Are the same extensions critical for all parts of a path or only for the >>>>> NVEs? >>>>> >>>>> I've seen very little thought or discussion given to these issues. It's >>>>> fine to say the control plane can >>>>> handle different encapsulations but what does it mean for the >>>>> architecture? >>>>> >>>>> Does committing to encapsulation A for a data-center mean that >>>>> data-center needs a flag-day to go to >>>>> using encapsulation B anywhere? Can data-centers using different >>>>> encapsulations successfully communicate >>>>> inside a VNI? How do these answers change if the assumption moves from >>>>> virtual machines and a hypervisor >>>>> to also handling bare metal servers? >>>>> >>>>> This is the conversation that I would like to see. >>>>> >>>>> Regards, >>>>> Alia >>>>> >>>>> >>>>> On Thu, Oct 6, 2016 at 8:20 AM, Lucy yong <[email protected]> wrote: >>>>>> >>>>>> Sam wrote: 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. >>>>>> >>>>>> >>>>>> >>>>>> IMO: This is not a valid statement to judge the existence of 3 encaps >>>>>> types. From any single user perspective, he/she only needs one >>>>>> encapsulation >>>>>> type. However, in this area, there are many and many users (or say >>>>>> different >>>>>> DC applications, e.g. cloud, Big data, IoT, etc), which apparently have >>>>>> different technical requirements. >>>>>> >>>>>> >>>>>> >>>>>> Suggestion: If WG goal is to define one encapsulation protocol to serve >>>>>> all, we need to have a generic protocol structure with flexibility and >>>>>> extensibility to meet different technical requirements; then pick one and >>>>>> work on it. If WG accepts three protocols to meet different technical >>>>>> requirements; WG publishes all three and requires each of them specify >>>>>> the >>>>>> protocol applicability with current specified features. >>>>>> >>>>>> >>>>>> >>>>>> Lucy >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: nvo3 [mailto:[email protected]] On Behalf Of Sam Aldrin >>>>>> Sent: Wednesday, October 05, 2016 9:02 PM >>>>>> To: Anoop Ghanwani >>>>>> Cc: Bocci, Matthew (Nokia - GB); NVO3 >>>>>> Subject: Re: [nvo3] Discussion on encapsulation formats and next steps >>>>>> >>>>>> >>>>>> >>>>>> Anoop, >>>>>> >>>>>> >>>>>> >>>>>> Comments inline, as individual contributor. >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Oct 5, 2016 at 3:23 PM, Anoop Ghanwani <[email protected]> >>>>>> 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 <[email protected]> >>>>>> 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 <[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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> nvo3 mailing list >>>>>> [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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
