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
