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 ?
Thanks,
Manish
From: Benson Schliesser <[email protected]<mailto:[email protected]>>
Date: Tuesday, 26 August 2014 5:18 AM
To: Osama Zia <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[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
