Anoop, On Thu, Oct 6, 2016 at 12:58 PM, Anoop Ghanwani <an...@alumni.duke.edu> 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? 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? > 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 <akat...@gmail.com> 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 <lucy.y...@huawei.com> 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:nvo3-boun...@ietf.org] *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 <an...@alumni.duke.edu> >>> 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 <aldrin.i...@gmail.com> >>> 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 <an...@alumni.duke.edu> >>> 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 <aldrin.i...@gmail.com> >>> 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 <an...@alumni.duke.edu> >>> wrote: >>> >>> On Tue, Oct 4, 2016 at 2:24 AM, Bocci, Matthew (Nokia - GB) < >>> matthew.bo...@nokia.com> 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 >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> >> >
_______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
