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
