Looks like very good phrasing. Eg in environments where there is no consistent topo-hierarchical addressing like overlays, where any EID can show up anywhere you either -
1) make the NVE-NVA indirection explicit as suggested and decouple the location of information from it's producers and consumers 2) do the indirection implicitly or hidden with "reflectors" and such, make hard to evolve and extend because you are presumably specifying a peer to peer protocol 3) have no reason to expect to be more scalable then transparent bridging As was stated, once you make the NVE-NVA indirection and interface explicit then there is no problem implementing the intra-NVA clustering or inter-NVA federation peer-to-peer over the underlay as most no-sqls do. To illustrate, a non decoupled topo-data exchange of just 500 blade servers (assume one large non fragmented cluster), that would have a minimum of 1000 NVEs aggregating 1000 VMs or 1000 contained OS images each, would need a B state updates just to get going. Where as a decoupled solution will need a maximum of this many updates over a lengthy periods of flat VM to VM communcation. --szb > On Aug 29, 2014, at 6:54 PM, Benson Schliesser <[email protected]> wrote: > > Hi, Manish and other contributors - > > (Changing the message Subject to better describe the topic.) > > Thanks, I think I understand the question you’re asking now. And it’s > possible that we need to revise the proposed charter text to be more clear. > But first, let’s explore the topic of NVA centralization, what it means and > doesn’t mean, etc. > > In my previous note I described three NVA interfaces: NVE-NVA, Intra-NVA > (Clustering), and Inter-NVA (Federation). I think that we have understanding > of these interfaces and rough consensus about what’s in scope here. However, > there is a broader question about what the NVA does, and whether a > centralized NVA obviates the need for all control plane functionality at the > NVE-NVE interface. Matthew and I have discussed this and we agree that the > NVO3 scope needs to be somewhat flexible in this regard. > > For example, I can imagine a solution that uses a NVE-NVA control plane for > overlay-underlay mapping, combined with a NVE-NVE control plane for liveness > detection. (This is just a simple example, and is not meant to be > prescriptive nor exhaustive of the various ways that functionality might be > split up between these interfaces.) As a counter-example, we do not want to > work on solutions where effectively all of the control plane is implemented > as a NVE-NVE protocol, such as a traditional routing protocol. (As I said > previously, this isn’t a criticism of such approaches, but rather a choice on > how to focus the NVO3 work.) > > Having said that, it isn’t perfectly clear to me how to improve the proposed > charter text. It already says that solutions must have a logically > centralized NVA. And it isn’t prescriptive about what functionality a NVA > provides. So, is that adequate to allow the flexibility the WG needs? Or is > there some concise way to characterize the balance between > centralized-distributed control plane functionality? I’m hesitant to add too > much detail, too much text in the charter - I’d really like to keep it > concise. But I also understand the point of confusion here, and I’m open to > suggestions on how to fix it. > > Feedback from the WG would be appreciated. > > Cheers, > -Benson > > >> On Aug 29, 2014, at 4:01 AM, Manish Kumar (manishkr) <[email protected]> >> wrote: >> >> 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]> >> Date: Friday, 29 August 2014 9:39 AM >> To: Manish Kumar <[email protected]> >> Cc: Sharon Barkai <[email protected]>, Thomas Nadeau >> <[email protected]>, "[email protected]" <[email protected]>, Osama Zia >> <[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 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
