Subject: Re: [nvo3] performance limitations with virtual switch as the nvo3 end point

From: Lizhong Jin <[email-masked]>
Date: Tue, 4 Sep 2012 21:35:21 +0800

If we could go with that direction (evolve encap and control plane
independently), the WG could narrow down to some specific design.
I raised similar question on the list (
http://www.ietf.org/mail-archive/web/nvo3/current/msg00574.html) before,
and the tenant identifier design is a key point. In current NVO3 framework
draft, section 3.1.3, the tenant identifier could be globally unique (e.g,
VLAN) or local vaue (e.g, MPLS). If the tenant identifier is an MPLS label,
different control plane interoperation will be much more complex, which
will make it hard to evolve encap and control plane independently.

Lizhong

>
> -----From Martin Casado <[email-masked]>, on Thu, 30 Aug
> 2012 10:14:34 -0700 -----
>
> To:
>
> Somesh Gupta <[email-masked]>
>
> CC:
>
> "smith, erik" <[email-masked]>, "[email-masked]" <[email-masked]>,
> David LE GOFF <[email-masked]>, "Ayandeh, Siamack" <siamack.
> [email-masked]>
>
> Subject:
>
> Re: [nvo3] performance limitations with virtual switch as the nvo3 end
point
>
> Absolutely agree.  Encaps will evolve with the problem space, the
> ecosysten of end points, and the deployment environments.
> Cleanly defining the abstractions between encap and control plane
> allow each to evolve independently.
> On Aug 30, 2012 9:37 AM, "Somesh Gupta" <[email-masked]> wrote:
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Somesh Gupta <[email-masked]>
Date: Tue, 4 Sep 2012 07:58:24 -0700

Lizhong,

The question of centralized configuration vs distributed protocol driven configuration
is an important one - that would include the question of identifier scope (I assume
that would be a correct paraphrasing of what you said?).

I am not sure whether the group will pick one or prioritize between the two - maybe
there would be a need for both?

The virtual networks in a single data center will be configured and managed centrally.
So we should acknowledge that reality.

Somesh

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Tuesday, September 04, 2012 6:35 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nvo3] performance limitations with virtual switch as the nvo3 end point

If we could go with that direction (evolve encap and control plane independently), the WG could narrow down to some specific design.
I raised similar question on the list (http://www.ietf.org/mail-archive/web/nvo3/current/msg00574.html) before, and the tenant identifier design is a key point. In current NVO3 framework draft, section 3.1.3, the tenant identifier could be globally unique (e.g, VLAN) or local vaue (e.g, MPLS). If the tenant identifier is an MPLS label, different control plane interoperation will be much more complex, which will make it hard to evolve encap and control plane independently.

Lizhong

>
> -----From Martin Casado <[email-masked]<mailto:[email-masked]>>, on Thu, 30 Aug
> Somesh Gupta <[email-masked]<mailto:[email-masked]>>
>
> CC:
>
> "smith, erik" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
> David LE GOFF <[email-masked]<mailto:[email-masked]>>, "Ayandeh, Siamack" <siamack.
> [email-masked]<mailto:[email-masked]>>
>
> Subject:
>
> Re: [nvo3] performance limitations with virtual switch as the nvo3 end point
>
> On Aug 30, 2012 9:37 AM, "Somesh Gupta" <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>