Huh? On Fri, 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
