Hi Benson, Perhaps the first time that the term "logically centralized" is introduced, you could add a clarification in parenthesis that says:
"(i.e. the NVA and NVE are not co-located and a protocol is required for communication between them)." Anoop On Mon, Sep 1, 2014 at 3:32 PM, Benson Schliesser <[email protected]> wrote: > Hi, Anoop. > > How is this (your suggested text) different from simply saying "logically > centralized"? > > I can see that you're focusing on the presence of a NVA, which is similar > to a suggestion from Linda and also similar to the text I originally sent > out on 8-Aug. That might be a good change if we can agree to specific > wording. > > But otherwise, I think I've already captured this discussion in the > proposed charter text. Here are some selected quotes to illustrate my point: > > "The NVO3 WG will develop solutions for network virtualization based on > ... A logically centralized control plane for network virtualization" > ... > "Such protocols are expected to fulfill > the communication requirements between an End Device and Network > Virtualization > Edge (NVE), and between an NVE and the Network Virtualization Authority > (NVA). > The internal mechanisms and protocols of a logically centralized NVA are > explicitly out of scope of the NVO3 WG. Architectural issues raised by > coexistence of multiple logically centralized control planes in the same > data > center may be considered by the WG. Inter-DC mechanisms are not in scope > of > the NVO3 WG at this time." > > Thanks, > -Benson > > > On Mon, Sep 1, 2014 at 3:32 PM, Anoop Ghanwani <[email protected]> > wrote: > >> 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
