Hi Sharon, Benson, Thanks for quick clarifications! It helps although I don't think I'm on the same page yet :). Let me attempt getting there!
Im totally with Sharon's point about the WG not entering into specifying how the network state is distributed (for a distributed model; or for that matter how it is aggregated for a centralised model) but rather focus on the behaviour of interfaces and the functional expectation from the various pieces. Using the existing IP underlay is just one way to distribute that information though and we perhaps may not choose to even go into those semantics though. However, it shouldn't imply that the NVA architecture be logically centralized – it could be centralized, distributed or a mix of both (even within the same network) using whichever model suits better. I feel 'a fully distributed control plane is not in NVO3 WG’s scope' could be still better:) as it at least leaves the scope for a mixed model open between the two extremes of a logically centralised and fully distributed control planes (more so the NVA part of the function). Nevertheless, forcing a 'logically centralised control plane' (specifically the NVA) seems limiting at the start and also increases chances for fragmented and/or overlapping solutions. I thought of this as a good place to integrate these various models into a common architecture based on interfaces and behavioural expectations irrespective of whether network state is either centralized or distributed and how it's aggregated or distributed. Each model could obviously leverage works done in other WGs. Also, just to highlight, the management plane could still be centralised (which is where this need is felt IMO). My two cents! Cheers, Manish From: Benson Schliesser <[email protected]<mailto:[email protected]>> Date: Friday, 29 August 2014 9:39 AM To: Manish Kumar <[email protected]<mailto:[email protected]>> Cc: Sharon Barkai <[email protected]<mailto:[email protected]>>, Thomas Nadeau <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Osama Zia <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Second Draft Charter Update for Discussion Hi, Manish. Your question about centralized vs distributed control planes is actually very important, and something that I’ve discussed offline quite a bit. So let me see if I can answer it here, for your benefit as well as the rest of the WG. I think Sharon described this accurately. To elaborate: In a logically centralized NVA architecture, we could envision multiple interfaces including NVE-NVA, intra-NVA (clustering), and inter-NVA (federation). In a fully distributed control plane, however, we might imagine having only a single NVE-to-NVE control interface. In the proposed charter text, we have said that a fully distributed control plane is not in NVO3 WG’s scope. This is not making a statement about whether that approach is valid, invalid, good, bad, etc, but rather is intended to focus our current work on the centralized architecture. Likewise, we have said that the intra-NVA (clustering) interface is not in scope. Again, this is not making a statement about whether it is necessary, good, bad, etc - because it obviously is necessary - but rather is intended to focus our work. Further, it seems likely that such an interface will not benefit from open specification and/or standardization in the near future, as implementors may use various mechanisms of their own choosing within their implementation. Of course, work on things like clustering, fully distributed control planes, etc, might be done in other WGs now. And/or the NVO3 WG might recharter to address them in the future. But our proposed charter text doesn’t take these into account at this time, just for the sake of focus. I hope this helps answer your question. Cheers, -Benson On Aug 28, 2014, at 2:20 PM, Sharon Barkai <[email protected]<mailto:[email protected]>> wrote: Must say I also struggled with the term logically centralized because for all practical purposes people will distribute the NVA, but then realized the point was - we could distribute the NVA based on the fact that there is fully functional IP underlay network that can be used for that. It is there by definition. And so this workgroup should not specify how to implement distributed software on an existing IP network, it should specify what this software does using which interfaces. If then people insist on using BGP, PNNI, IN to distribute states it's their call, other people may use simpler and more functional means. --szb On Aug 28, 2014, at 9:26, "Thomas D. Nadeau" <[email protected]<mailto:[email protected]>> wrote: On Aug 28, 2014:12:21 PM, at 12:21 PM, Manish Kumar (manishkr) <[email protected]<mailto:[email protected]>> wrote: Hi Benson, The same text ("A logically centralized control plane for network virtualization") was bothering me for days as well! However, having been out of touch with developments in the working group for the past few months, I thought I better do the homework to check if this has already been covered in some discussions earlier. I also see the intent of keeping out BGP and or MPLS (L2VPN/L3VPN) based solutions because work for the same is going on (or would be done) in other working groups. The final solution, as you say, could very well involve centralised and/or distributed components. Even the updated framework document talks about a balance needed - "Domain and/or deployment specific constraints define the balance between centralized and distributed approaches". Given these, as well as based on other limitations of a centralised model, I still don't understand the rationale behind the text - "A logically centralized control plane for network virtualization" in the charter update. Excluding BGP and/or MPLS based solutions for the reason above makes sense but not distributed models summarily. Am I missing something here ? I think you are. Logically centralized covers physically centralized and only allows you to have more resiliency/scale/performance than a single instance. I would also think that no one in a production environment would install a single centralized instance anyways, so we need logically centralized to cover real-world scenarios. --Tom Thanks, Manish From: Benson Schliesser <[email protected]<mailto:[email protected]>> Date: Tuesday, 26 August 2014 5:18 AM To: Osama Zia <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Second Draft Charter Update for Discussion Hi, Osama. On Mon, Aug 25, 2014 at 4:30 PM, Osama Zia <[email protected]<mailto:[email protected]>> wrote: 1. I am getting the impression that NVO3 WG will only look at logically centralized control plane. All decentralized solutions such as BGP based should be looked separately. Is this correct? Yes. To elaborate: Existing and new solutions that are based on BGP to provide network virtualization would be developed in the (to-be-formed) BESS working group. This would be the case for all BGP-based solutions, regardless of whether they have a control plane architecture that is distributed or centralized. It is possible that NVO3 solutions could leverage BGP and/or that BGP-based solutions could leverage NVO3 work. In these cases we would work cross-WG to make sure that the solution is documented completely and accurately, with work happening in the most appropriate place(s). For example one could imagine combining a NVO3-developed data plane encap, a NVO3-developed TS-NVE control plane, and a BESS-developed NVA control plane. (There are many other possible combinations here; I'm not trying to be exhaustive, just illustrate the idea.) Similar to what I've described above, NVO3 solutions might leverage distributed protocols in various ways, resulting in cross-WG work with other WGs. For example, it is possible that the centralized NVE-NVA control plane protocol is responsible for certain mapping functions whilst other functions are provided by distributed protocols, such as liveness detection via IGP-provided link state etc. (Again, not trying to be exhaustive, just illustrating the idea.) 2. The statement says that "The NVO3 WG will develop solutions for network virtualization based on the following architectural tenets". However, the control plane requirements and data plane requirements are optional. Shouldn't architecture be based on certain requirements? Requirements are certainly helpful, and as an NVO3 chair I do intend to encourage their development. But one of the goals of this recharter is to begin working on solutions in parallel, rather than in serial, with requirements. Indeed, the purpose of working on requirements is to assist the WG in developing solutions (requirements on their own have little value). And so with this new charter text we have given ourselves the flexibility to manage the production of requirements in whatever way is best for the WG. Cheers, -Benson _______________________________________________ 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
