Anoop wrote: 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.
I do not understand the concern here. IMO: this is the best way to make a common encapsulation protocol to meet all technical requirements, i.e. using options for the requirements are not in common. Then it is up to individual providers to mandate what options are required to be implemented for its application. If a vendor wants to support many applications, it can implement all options; if a vendor only want to support an application, it only implements the options that application requires. When doing the interworking, it would be per application bases, not per every feature the protocol specifies. Regards, Lucy From: [email protected] [mailto:[email protected]] On Behalf Of Anoop Ghanwani Sent: Thursday, October 06, 2016 5:11 PM To: Alia Atlas Cc: Lucy yong; Sam Aldrin; Bocci, Matthew (Nokia - GB); NVO3 Subject: Re: [nvo3] Discussion on encapsulation formats and next steps Hi Alia, Please see inline. Anoop On Thu, Oct 6, 2016 at 10:29 AM, Alia Atlas <[email protected]<mailto:[email protected]>> wrote: Anoop, On Thu, Oct 6, 2016 at 12:58 PM, Anoop Ghanwani <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<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]<mailto:[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]<mailto:[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]<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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ 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
