>>> 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. >>>
I think it would be worthwhile to add these sentences (or some version of them) to the charter to clarify what is meant by a logically centralized (vs distributed) NVA architecture. I had expressed a similar concern earlier and it's only now become clear to me what a distributed control plane architecture is. I don't think we can have an NVE-to-NVE control plane...what you probably mean by that is that the NVA function is co-resident with every NVE. I am not aware of any implementation that does that, so I can see why it makes sense for the WG to exclude that from the charter. Anoop On Thu, Aug 28, 2014 at 9:09 PM, Benson Schliesser <[email protected]> wrote: > 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]> 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]> > wrote: > > > On Aug 28, 2014:12:21 PM, at 12:21 PM, Manish Kumar (manishkr) < > [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]> > Date: Tuesday, 26 August 2014 5:18 AM > To: Osama Zia <[email protected]> > Cc: "[email protected]" <[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]> 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] > 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
