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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
