Subject: Re: [nvo3] Understanding "Centralized NVA" in the Charter

From: Benson Schliesser <[email-masked]>
Date: Mon, 1 Sep 2014 15:19:28 -0400

Hi, Linda and other contributors -

Thanks, I think you might be on to something here that could help the
charter text. But there is an issue that isn't quite clear yet.

First, I don't think we can assume the use of a NVA is incompatible with
self discovery. There is some kind of essential authoritative role that the
NVA is responsible for, but it is conceivable that it might learn about
things through various mechanisms.

So what might be helpful is if we could describe the presence of a NVA in
more abstract terms. We need to distinguish between an architecture with a
fully distributed control plane (eg, routing) and one with a NVA.

Thoughts on how to do this?

Cheers,
-Benson
On Aug 31, 2014 9:21 AM, "Linda Dunbar" <[email-masked]> wrote:

>
>
> It is really less about “Centralized NVA” because NVA can be distributed
> (that is why you need NVA-NVA protocols), but more about an entity with
>  “Authoritative Information coming from   databases or configurations”
> instead from network protocol self discovery.
>
>
>
> This entity (NVA) can be centralized or distributed.
>
>
>
> Linda
>
>
>
> *From:* nvo3 [mailto:[email-masked]] *On Behalf Of *Benson
> Schliesser
> *Sent:* Friday, August 29, 2014 8:54 PM
> *To:* [email-masked]
> *Subject:* [nvo3] Understanding "Centralized NVA" in the Charter
>
>
>
> 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-masked]>
> 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-masked]>
> *Date: *Friday, 29 August 2014 9:39 AM
> *To: *Manish Kumar <[email-masked]>
> *Cc: *Sharon Barkai <[email-masked]>, Thomas Nadeau <
> [email-masked]>, "[email-masked]" <[email-masked]>, Osama Zia <
> [email-masked]>
> *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
>
>
>
>
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 1 Sep 2014 13:32:35 -0700

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-masked]

>  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-masked]>
> Date: Friday, 29 August 2014 10:38 AM
> To: Benson Schliesser <[email-masked]>
> Cc: Manish Kumar <[email-masked]>, Osama Zia <[email-masked]>,
> Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>,
> Sharon Barkai <[email-masked]>
>
> 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-masked]> wrote:
>
>> is actually very important, and something that I've discussed offline quite
>> control plane is not in NVO3 WG's scope. This is not making a statement
>>  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.
>>
>> doesn't take these into account at this time, just for the sake of focus.
>>
>>  On Aug 28, 2014, at 2:20 PM, Sharon Barkai <[email-masked]>
>> 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-masked]>
>> wrote:
>>
>>
>>  On Aug 28, 2014:12:21 PM, at 12:21 PM, Manish Kumar (manishkr) <
>> [email-masked]> 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-masked]>
>> Date: Tuesday, 26 August 2014 5:18 AM
>> To: Osama Zia <[email-masked]>
>> Cc: "[email-masked]" <[email-masked]>
>> Subject: Re: [nvo3] Second Draft Charter Update for Discussion
>>
>>   Hi, Osama.
>>
>> On Mon, Aug 25, 2014 at 4:30 PM, Osama Zia <[email-masked]> 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-masked]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>>   _______________________________________________
>> nvo3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>

---

From: Benson Schliesser <[email-masked]>
Date: Mon, 1 Sep 2014 17:32:41 -0500

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-masked]>
wrote:

> On Fri, Aug 29, 2014 at 1:24 AM, Manish Kumar (manishkr) <
>>> 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.
>>>
>>>  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
>>>  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

---

From: Anoop Ghanwani <[email-masked]>
Date: Mon, 1 Sep 2014 15:46:58 -0700

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-masked]>
wrote:

> "The NVO3 WG will develop solutions for network virtualization based on
> ... A logically centralized control plane for network virtualization"
> ...
>> - 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
>>>> planes is actually very important, and something that I've discussed
>>>>  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.
>>>>