Based on what Manish is saying, it looks like the intent of saying "logically centralized," is probably better conveyed by saying: - NVO3 will work on a protocol for NVA-to-NVE communication to address the case where the NVA is not co-located with the NVE - NVO3 will not address how NVAs communicate among themselves. - If an implementation chooses to have the NVA co-located with every NVE, then they won't need this protocol.
Anoop On Fri, Aug 29, 2014 at 1:24 AM, Manish Kumar (manishkr) <[email protected] > wrote: > Hi Anoop, > > I agree a clarification could definitely help! As far as the > implementations go, I don't know whether it would be appropriate to name > them but I can vouch for at least one (and multiple others claim > interoperability with that) that has been around for a decade, if not more, > and does have millions of network nodes deployed (including instances of > 25k+ in single networks) although primarily in L3 space so far. The > mechanism (NVA co-resident with every NVE) is an integral part of the same > although it also uses the other mechanism (NVA-NVE not co-resident) and > allows for a centralised model as well. The last one obviously doesn't > scale as well though unless you use a brute force means of having to keep > increasing the capacity of the central authority/NVA. > > Cheers, > Manish > > From: Anoop Ghanwani <[email protected]> > Date: Friday, 29 August 2014 10:38 AM > To: Benson Schliesser <[email protected]> > Cc: Manish Kumar <[email protected]>, Osama Zia <[email protected]>, > Thomas Nadeau <[email protected]>, "[email protected]" <[email protected]>, > Sharon Barkai <[email protected]> > > Subject: Re: [nvo3] Second Draft Charter Update for Discussion > > >>> > 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
