Subject: RE: Response to some comments on IS-IS VPLS

From: <[email-masked]>
Date: Mon, 2 Apr 2012 06:36:19 -0400

James,

I believe the solution preference starts from this belief about data center architecture:

>> I believe that the data center is becoming more and more a
>> dynamic extension of a customer¹s network.

Under that assumption, for a carrier whose network is based on networking technologies like BGP, extending those technologies into a data center is a fine thing to do, and nothing in the nvo3 work is intended to stop that.

OTOH, for a non-carrier data center (e.g., enterprise), not only is the above statement rather incorrect, but the enterprise network may not be running BGP.  This can be particularly so for a data center that desires flexibility in choice among carriers, and hence operates under the principle that one of the jobs of the CPE box is to keep the carrier technology on the other side in order to limit lock-in.  The nvo3 work is targeted at the sort of use cases described in this paragraph.

This sort of spirited promotion of BGP comes across as an attempt to force a one-size-fits-all solution on those who do not currently use BGP.  I am **NOT** arguing that BGP can't be made to work; I am arguing that it's a poor fit for the use cases of interest.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 2 Apr 2012 12:15:04 +0000

David,

	Comments In-Line...

Thanks,
	Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, April 02, 2012 6:36 AM
To: UTTARO, JAMES
Cc: [email-masked]; [email-masked]
Subject: RE: Response to some comments on IS-IS VPLS

James,

OTOH, for a non-carrier data center (e.g., enterprise), not only is the above statement rather incorrect, but the enterprise network may not be running BGP.  This can be particularly so for a data center that desires flexibility in choice among carriers, and hence operates under the principle that one of the jobs of the CPE box is to keep the carrier technology on the other side in order to limit lock-in.  The nvo3 work is targeted at the sort of use cases described in this paragraph.
[Jim U>] So, a couple of items.. BGP is a general purpose tools that is used in a variety of applications where discovery, dynamic signaling etc.. is required.. So for a non-carrier data center I would think that the same reqs would be needed even if the scope is limited to that single non-carrier data center.. If one were to consider deploying a technology to realize the service needed it would seem prudent to consider all solution spaces and not get caught up in the perception or us vs. them mentality.. The other notion here is that using BGP somehow prevents isolation or limits selection of different providers, neither of these assumptions have been proven to be true in other applications that use BGP..

This sort of spirited promotion of BGP comes across as an attempt to force a one-size-fits-all solution on those who do not currently use BGP.  I am **NOT** arguing that BGP can't be made to work; I am arguing that it's a poor fit for the use cases of interest.
[Jim U>] I do not agree.. BGP permits the evolution of the services such that any and all data centers can participate in providing service, and anticipates use cases currently not considered such as multiple data centers across companies providing service for a given customer in a cooperative manner.. I do not see how the solutions or assumptions made in NVO3 capture this...

Thanks,
--David

---

From: Jon Hudson <[email-masked]>
Date: Mon, 2 Apr 2012 10:45:32 -0700

I agree with David.

It becomes an issue of in house knowledge and equipment budget vs whatever is already in place.

Many Enterprise IT shops have humans that would love to learn BGP (or MPLS etc) but just don't have a background in it. This makes them very vendor dependent for the expertise which makes some nervous. A week long BGP class does not an expert make. 

The second issue for some (which was brought up at the BoF) is that it's a certain class of devices that have BGP support. It may be that to support BGP new hardware needs to be acquired.

I see these two issues most often as barriers to a proposal like this.

J

On Apr 2, 2012, at 5:15 AM, "UTTARO, JAMES" <[email-masked]> wrote:

> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 2 Apr 2012 14:06:34 -0400

I agree with Jon and David. 
BGP is no small feat to take up.
Cost is another factor (capex and opex).

/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon Hudson
Sent: Monday, April 02, 2012 1:46 PM
To: UTTARO, JAMES
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nvo3] Response to some comments on IS-IS VPLS

I agree with David.

J

---

From: Alia Atlas <[email-masked]>
Date: Mon, 2 Apr 2012 14:30:55 -0400

As Jim said,

[Jim U>] So, a couple of items.. BGP is a general purpose tools that
is used in a variety of applications where discovery, dynamic
signaling etc.. is required..

For a data-center application, it isn't necessary to have available
and configure all of the policy-based complexity of BGP.   Instead,
the necessary subset could be clearly defined as a BGP profile.  The
type of configuration and information needed would, I suspect, be
quite similar for any application that is doing discovery, dynamic
signaling, pushing VNID membership information, etc.

So - which aspects of BGP are viewed as too complex for the Enterprise
IT space?  Are those the ones that would actually be needed for an
L2VPN/EVPN application?

As for which types of boxes support BGP vs. support an unspecified
as-yet-undefined new solution, any box that can have new code written
for a new solution could similarly have code written for the subset of
BGP that is needed here.

I certainly hear the trepidation about BGP complexity - but when all
of BGP (for all applications) is compared to undefined future solution
(where the complexity is always in the unconsidered/unspecified
details), I am not yet persuaded that a simplified BGP profile
wouldn't suffice.

That said, I think the concern over BGP is rather like the elephant in
the room that we hadn't been talking about.   Since this strongly
guides what types of solutions can be considered and how existing ones
might need to be modified, I'm glad that we're starting this
discussion.

Alia

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 2 Apr 2012 11:58:11 -0700

Interesting discussion!  (Thomas, see what one small sub-bullet can lead to :-))

See more inline. 

On Apr 2, 2012, at 3:46, "[email-masked]" <[email-masked]> wrote:

> OTOH, for a non-carrier data center (e.g., enterprise), not only is the above statement rather incorrect, but the enterprise network may not be running BGP.  

Step back a bit. The non-carrier DC is not being asked to run BGP. The _cloud_ operator, in order to scale their DC, of which the non-carrier DC is just a tenant, may want to run BGP.  Just as enterprises running OSPF get connectivity services from carriers running BGP. 

> This can be particularly so for a data center that desires flexibility in choice among carriers,

Actually, BGP is what carriers talk to each other, so I'm not sure how such a choice limits flexibility.

> and hence operates under the principle that one of the jobs of the CPE box is to keep the carrier technology on the other side in order to limit lock-in.  

The "other" side of a CPE box usually runs BGP. 

Kireeti

> The nvo3 work is targeted at the sort of use cases described in this paragraph.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 2 Apr 2012 19:51:43 +0000

David,

I think that maybe a good starting point would be to start to build a set of reqs that might meet both SP/DC reqs with an eye towards evolving into the future..Comments In-Line..

Thanks,
	Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, April 02, 2012 3:24 PM
To: UTTARO, JAMES
Cc: [email-masked]; [email-masked]
Subject: RE: Response to some comments on IS-IS VPLS

Jim,

> [Jim U>] So, a couple of items.. BGP is a general purpose tools that is used in a variety of
> applications where discovery, dynamic signaling etc.. is required.. So for a non-carrier data center I
> would think that the same reqs would be needed even if the scope is limited to that single non-carrier
> data center..

Ok, but data centers tend to use much simpler routing technology.  As Kireeti points out, many non-SP data centers use IGPs - OSPF with ECMP is a common example that one can expect to see in the IP network underlying the encapsulation.  Another interesting possibility for overlay address mapping is the sort of directory-based infrastructure now being used by LISP (I'll leave it to the LISP folks to explain what this is and how/why it may be interesting).
[Jim U>] Hmmm.. LISP like technology could be interesting..

> If one were to consider deploying a technology to realize the service needed it would
> seem prudent to consider all solution spaces and not get caught up in the perception or us vs. them
> mentality..

I'm sorry, but BGP's complexity (e.g., policy) by comparison to the IGPs typically used in non-carrier data centers is a matter of fact, not perception or opinion.  OTOH, Alia's suggestion that a cut-down BGP profile might be applicable is interesting, IMHO.
[Jim U>] Yes Alia makes a great selection here.. If we can determine the reqs there could be an opportunity to use a BGP Profile in the DC that could be easily extended

Thanks,
--David

> From: UTTARO, JAMES [mailto:[email-masked]]
> Sent: Monday, April 02, 2012 8:15 AM
> To: Black, David
> Under that assumption, for a carrier whose network is based on networking technologies like BGP,
> extending those technologies into a data center is a fine thing to do, and nothing in the nvo3 work is
> intended to stop that.
> 
> OTOH, for a non-carrier data center (e.g., enterprise), not only is the above statement rather
> incorrect, but the enterprise network may not be running BGP.  This can be particularly so for a data
> center that desires flexibility in choice among carriers, and hence operates under the principle that
> one of the jobs of the CPE box is to keep the carrier technology on the other side in order to limit
> lock-in.  The nvo3 work is targeted at the sort of use cases described in this paragraph.
> [Jim U>] So, a couple of items.. BGP is a general purpose tools that is used in a variety of
> applications where discovery, dynamic signaling etc.. is required.. So for a non-carrier data center I
> would think that the same reqs would be needed even if the scope is limited to that single non-carrier
> data center.. If one were to consider deploying a technology to realize the service needed it would
> seem prudent to consider all solution spaces and not get caught up in the perception or us vs. them
> mentality.. The other notion here is that using BGP somehow prevents isolation or limits selection of
> different providers, neither of these assumptions have been proven to be true in other applications
> that use BGP..
> 
> This sort of spirited promotion of BGP comes across as an attempt to force a one-size-fits-all
> solution on those who do not currently use BGP.  I am **NOT** arguing that BGP can't be made to work;
> I am arguing that it's a poor fit for the use cases of interest.
> [Jim U>] I do not agree.. BGP permits the evolution of the services such that any and all data centers
> can participate in providing service, and anticipates use cases currently not considered such as
> multiple data centers across companies providing service for a given customer in a cooperative
> manner.. I do not see how the solutions or assumptions made in NVO3 capture this...
> 
> Thanks,
> --David

---

From: <[email-masked]>
Date: Mon, 2 Apr 2012 15:23:54 -0400

Jim,

Thanks,
--David

---

From: <[email-masked]>
Date: Mon, 2 Apr 2012 15:34:16 -0400

Hi Kireeti,

We're in agreement, and thank you for your comments at the BOF.  Here are a few elaborations:

> incorrect, but the enterprise network may not be running BGP.
> 
> Step back a bit. The non-carrier DC is not being asked to run BGP.

Sure - you and I agree on this, but Jim wants to push BGP into non-carrier data centers ...
perhaps you can help convince him otherwise ...

> The _cloud_ operator, in order to
> scale their DC, of which the non-carrier DC is just a tenant, may want to run BGP.  Just as
> enterprises running OSPF get connectivity services from carriers running BGP.

I absolutely agree, and nvo3 is applicable to non-carrier DCs.

> choice limits flexibility.

If one extends the carrier's BGP instance into the data center, switching carriers
becomes more difficult by comparison to ...

> > and hence operates under the principle that one of the jobs of the CPE box is to keep the carrier
> technology on the other side in order to limit lock-in.
> 

... having the CPE box do its job in keeping the carrier's instance of BGP on the carrier's side ("other" side of the box) where the carrier's admins can manage it without having to bother the data center admins much.

Thanks,
--David

> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Monday, April 02, 2012 2:58 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Response to some comments on IS-IS VPLS
> 
> incorrect, but the enterprise network may not be running BGP.
> 
> Step back a bit. The non-carrier DC is not being asked to run BGP. The _cloud_ operator, in order to
> scale their DC, of which the non-carrier DC is just a tenant, may want to run BGP.  Just as
> enterprises running OSPF get connectivity services from carriers running BGP.
> 
> > and hence operates under the principle that one of the jobs of the CPE box is to keep the carrier
> technology on the other side in order to limit lock-in.
>

---

From: <[email-masked]>
Date: Mon, 2 Apr 2012 16:08:31 -0400

> I think that maybe a good starting point would be to start to build a set of reqs that might meet both
> SP/DC reqs with an eye towards evolving into the future..

Allow me to suggest draft-kreeger-nvo3-overlay-cp-00 as a starting point ...

Thanks,
--David

> Sent: Monday, April 02, 2012 3:52 PM
> To: Black, David
> I think that maybe a good starting point would be to start to build a set of reqs that might meet both
> SP/DC reqs with an eye towards evolving into the future..Comments In-Line..
> 
> Thanks,
> 	Jim Uttaro
> 
> Ok, but data centers tend to use much simpler routing technology.  As Kireeti points out, many non-SP
> data centers use IGPs - OSPF with ECMP is a common example that one can expect to see in the IP
> network underlying the encapsulation.  Another interesting possibility for overlay address mapping is
> the sort of directory-based infrastructure now being used by LISP (I'll leave it to the LISP folks to
> explain what this is and how/why it may be interesting).
> I'm sorry, but BGP's complexity (e.g., policy) by comparison to the IGPs typically used in non-carrier
> data centers is a matter of fact, not perception or opinion.  OTOH, Alia's suggestion that a cut-down
> BGP profile might be applicable is interesting, IMHO.
> [Jim U>] Yes Alia makes a great selection here.. If we can determine the reqs there could be an
> opportunity to use a BGP Profile in the DC that could be easily extended
> 
> Thanks,
> --David
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 2 Apr 2012 16:27:00 -0400

While it might be good to talk about the BGP-light/superlight/featherweight for intra-DC (enterprise) solution,
it is hard to explain away reluctance (of DC operators) based on valid concerns (discussed already on this thread).
 
I hope we do not consume the NVO3 with explain-to-me-why-bgp-is-not-good-enough again-and-again.

Thanks,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of UTTARO, JAMES
Sent: Monday, April 02, 2012 3:52 PM
To: [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] Response to some comments on IS-IS VPLS

David,

Thanks,
	Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, April 02, 2012 3:24 PM
To: UTTARO, JAMES
Cc: [email-masked]; [email-masked]
Subject: RE: Response to some comments on IS-IS VPLS

Jim,

Thanks,
--David

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 03 Apr 2012 00:32:30 +0200

<adjusting a bit the title>

> Alia's suggestion that a cut-down BGP profile might be applicable is
> interesting, IMHO.

Really ? Can you or Alia specify what is going to be cut out of BGP to 
make it BGP4DC ? Can you please put the scissors back to the drawer ???

Actually I think this discussion is rather amusing. Should we rather 
then tons of emails on BGP or not BGP focus a bit on service primitives 
any protocol should support ? Focus on what elements needs to be 
exchanged between hosts to provide tenant isolation both intra and 
inter-domain first ?

IETF historically were operating in principle let's define a protocol 
and let at least two vendors implement it. Then if they are lucky enough 
and not fighting each other the victory could be announced and the 
service inter-operates .. Hurraaaa time to invite customers with big 
wallets to purchase it.

I think that model while many got used to it is no longer that 
appealing. Should we rather standardize open set of primitives to 
exchange sufficient information on a NNI boundaries to allow flexible 
interconnect ?

Such primitives may be exchanged with BGP, but equally well they may be 
exchanged with other means - for example service bus two ASes would 
decided to use (provider - provider or provider - customer). In fact 
once we agree on the set of primitives there is no need to make one 
choice of transport for them everywhere. That should be local choice of 
given interconnect.

Regards,
R.

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 2 Apr 2012 17:52:42 -0700

Hi David,

> We're in agreement, and thank you for your comments at the BOF.  Here are

It's great that (we think) we're in agreement, but just in case ...

> > Step back a bit. The non-carrier DC is not being asked to run BGP.

There are two ways to interpret "non-carrier DC":
a) enterprises that have a DC but want to move to the clouds (i.e.,
customers);
b) non-carriers that *build* clouds (e.g., EC2).

It is a non-starter to ask those in (a) to run BGP (or to change any of
their practices in any significant way).

It is a definite possibility to ask the non-carrier cloud provider to adopt
BGP as the scaling mechanism.

(oh, oh -- the end of a beautiful friendship, just as it was getting going
... :-))

BGP is a well-tested protocol for scaling.  Yes, there are complexities,
some real, some perceived.  The question is, is it easier to simplify BGP
(along the lines that Alia said), or break loose and start again?

The answer for SP-cloud providers seems clear.  The answer for non-carrier
cloud providers is open.  I'm going to revisit this thread and see how many
non-carrier cloud providers actually spoke up.

> perhaps you can help convince him otherwise ...

I could try, but it would be like <insert blasphemy here>.

> I absolutely agree, and nvo3 is applicable to non-carrier DCs.

NVO3 is indeed applicable to both carrier and non-carrier cloud providers.

> > Actually, BGP is what carriers talk to each other, so I'm not sure how
> such a
> > choice limits flexibility.
>
> ... having the CPE box do its job in keeping the carrier's instance of BGP
> on the carrier's side ("other" side of the box) where the carrier's admins
> can manage it without having to bother the data center admins much.f
>

Got it.

Cheers,
Kireeti.

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 3 Apr 2012 08:06:42 -0400

On Apr 2, 2012:8:52 PM, at 8:52 PM, Kireeti Kompella wrote:

> a) enterprises that have a DC but want to move to the clouds (i.e., customers);

	There is a third that you are missing: simply enterprises that have a DC today - whether or not they have moved any services to a XaaS model or not is not that important per se.  These are simply DCs (some very late if you look at financial institutions).  Some of these fall into the categories being discussed around the hesitation around using different protocols.

	I actually like to divide up the space a little differently:

	Traditional telco service providers (i.e.: att, vz, etc…)
	"New" service providers (i.e.: google, salesforce.com, amazon, rackspace, etc…)
	Enterprise (large, med, small, and govt)

	If you look at things using that lens, I think the answers may differ from your conclusions because as you will find, there are differing levels of comfort for doing certain things, as well as different business constraints/drivers - or resistors.
 
> It is a non-starter to ask those in (a) to run BGP (or to change any of their practices in any significant way).
> 
> It is a definite possibility to ask the non-carrier cloud provider to adopt BGP as the scaling mechanism.

	That depends on what their needs and level of expertise are. We are making broad characterizations of enterprises that I think need to be more granular for them to make sense (see above). 

> (oh, oh -- the end of a beautiful friendship, just as it was getting going ... :-))
> 
> BGP is a well-tested protocol for scaling.  Yes, there are complexities, some real, some perceived.  The question is, is it easier to simplify BGP (along the lines that Alia said), or break loose and start again?
> 
> The answer for SP-cloud providers seems clear.  The answer for non-carrier cloud providers is open.  I'm going to revisit this thread and see how many non-carrier cloud providers actually spoke up.

	I agree. This is where we need to get enterprises to chime in on this topic. Unfortunately enterprises often do not participate at the IETF, so our mileage may vary here.

> NVO3 is indeed applicable to both carrier and non-carrier cloud providers.

	It is applicable wherever people decide to use it, which is still up for debate since it does not really exist yet in any deployable form as far as I know. *)   What is important is that people that *think* they want to use it to step up and say so as soon as possible!

	--Tom

> ... having the CPE box do its job in keeping the carrier's instance of BGP on the carrier's side ("other" side of the box) where the carrier's admins can manage it without having to bother the data center admins much.f
> 
> Got it.
> 
> Cheers,
> Kireeti.
>  
> Thanks,
> --David
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 3 Apr 2012 16:52:49 +0000

Comments In-Line

                Jim Uttaro

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, April 03, 2012 8:07 AM
To: Kireeti Kompella
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [nvo3] Response to some comments on IS-IS VPLS

Hi David,
On Mon, Apr 2, 2012 at 12:34 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kireeti,

            Traditional telco service providers (i.e.: att, vz, etc...)
            "New" service providers (i.e.: google, salesforce.com<http://salesforce.com>, amazon, rackspace, etc...)
            Enterprise (large, med, small, and govt)

            If you look at things using that lens, I think the answers may differ from your conclusions because as you will find, there are differing levels of comfort for doing certain things, as well as different business constraints/drivers - or resistors.
[Jim U>] Again I become lost.. You mention three categories.. I understand the comment in re business  constraints/drivers although I have not seen that documented anywhere as a rationale for technical solution... The notion of "differing levels of comfort" seems to be code for adherence to a certain technology.. This I do not understand... The best path forward is t document the current reqs/business drivers, and anticipate how the service will evolve.. If we do this we can have a discussion about the needs not the wants..

            I agree. This is where we need to get enterprises to chime in on this topic. Unfortunately enterprises often do not participate at the IETF, so our mileage may vary here.
[Jim U>] How do we do that?

[Jim U>] LOL..

            It is applicable wherever people decide to use it, which is still up for debate since it does not really exist yet in any deployable form as far as I know. *)   What is important is that people that *think* they want to use it to step up and say so as soon as possible!
[Jim U>] But what is equally important is to know what any solution does and does not solve...

            --Tom

Got it.

Cheers,
Kireeti.

Thanks,
--David

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 3 Apr 2012 11:45:53 -0700

On Apr 3, 2012, at 11:15, Chris Wright <[email-masked]> wrote:

> * Kireeti Kompella ([email-masked]) wrote:

<snip>

> I think you missed a large portion of the enterprise DC world.
> Enterprises that have a DC and are beginning to run their DC internally
> as a cloud, aka the private cloud.

Good point.

Which brings me back to the charter: is NVO3 aimed at _large_ virtualized DCs, or _any_ vDCs?

To Chris's point, if an enterprise builds/converts their DC into a private cloud of a thousand or two VMs, would that be in scope for NVO3?

I'm not looking for a threshold, rather whether scale is (should be) part of the charter?

Kireeti 

> thanks,
> -chris

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 03 Apr 2012 22:37:43 +0200

> To Chris's point, if an enterprise builds/converts their DC into a
> private cloud of a thousand or two VMs, would that be in scope for
> NVO3?

Why not ?

Oooo maybe BGP based solution would be a bit suboptimal for 2 or 22 VMs 
case ? Bad luck :(

Best,
R.

---

From: Larry Kreeger <[email-masked]>
Date: Tue, 03 Apr 2012 14:50:10 -0700

On 4/3/12 11:45 AM, "Kireeti Kompella" <[email-masked]> wrote:

> To Chris's point, if an enterprise builds/converts their DC into a private
> cloud of a thousand or two VMs, would that be in scope for NVO3?
> 

Kireeti,

IMO, the goal of the WG should be to address the needs of small/medium
enterprise private clouds all the way up to large cloud service providers.
In an earlier version of the proposed WG charter put out on the nvo3 list by
Thomas Narten on March 24th, he tried to address this with the following
text which was later removed to simplify/generalize the charter:

"A key area of work is the development of requirements for (and to find
solutions for) control plane functions that allow an ingress to the
overlay to map the "inner" (tenant VM) address into an "outer"
(underlying network) address in order to tunnel a packet to the
destination VM. Two different approaches will be pursued, targeting
two different deployment environments.

The first approach will document a data plane learning mechanism
similar to IEEE 802.1Q learning and would be appropriate for smaller
data centers where flooding of frames to unknown destinations is not
considered a major problem. This document is expected to be relatively
short, as IEEE 802.1Q learning is well-documented and understood.

The second approach will focus on a control plane aimed at large data
centers, capable of scaling to hundreds of thousands of nodes.  This
control plane will be the major work item for this WG. A key
requirement will be to avoid the need for flooding in the case where a
mapping from an inner source VM to a target tunnel end point address
is not present at the ingress to the overlay network. A second
requirement may be that the control plane must also be applicable to
geographically dispersed data centers supporting a single overlay. The
first work item is to develop requirements for this control protocol."

 - Larry

---

From: Larry Kreeger <[email-masked]>
Date: Tue, 03 Apr 2012 14:55:10 -0700

I agree that is very unlikely that any small/medium enterprises are
monitoring this list in order to chime in.  I think the closest we will be
able to get may be hypervisor vendors that talk with customers like these to
hear their requirements.

 - Larry

On 4/3/12 5:06 AM, "Thomas Nadeau" <[email-masked]> wrote:

> I agree. This is where we need to get enterprises to chime in on this topic.
> Unfortunately enterprises often do not participate at the IETF, so our mileage
> may vary here.

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 3 Apr 2012 15:33:51 -0700

Hi Larry,

> enterprise private clouds all the way up to large cloud service providers.

The question is, is there really a problem to solve in the small/medium private cloud space?  There is an existence proof that existing methodologies (layer 2) work adequately here.  So, a rationale for including these cases would be helpful.

Kireeti

---

From: Larry Kreeger <[email-masked]>
Date: Tue, 03 Apr 2012 20:25:10 -0700

Kireeti,

I think most of the reasons listed in the problem statement draft can apply
to small/medium enterprise private clouds.

However, one important rationale for a small/medium enterprise private cloud
to use an overlay is to support dynamic extension of the overlay to the
proper hypervisors on demand as the application load on the cloud changes
and VMs migrate across the compute infrastructure.

It is also possible that physical networks equipment can reach VLAN
exhaustion well below the 4K theoretical VLAN limit both in the absolute
number of VLANs supported and the number of virtual ports if they resort to
trunking a couple of thousand VLANs to every single server for operational
flexibility.

 - Larry

On 4/3/12 3:33 PM, "Kireeti Kompella" <[email-masked]> wrote:

> The question is, is there really a problem to solve in the small/medium
> private cloud space?  There is an existence proof that existing methodologies
> (layer 2) work adequately here.  So, a rationale for including these cases
> would be helpful.
> 
> Kireeti
>

---

From: Chris Wright <[email-masked]>
Date: Tue, 3 Apr 2012 12:36:12 -0700

> To Chris's point, if an enterprise builds/converts their DC into a private cloud of a thousand or two VMs, would that be in scope for NVO3?

Personally, I expect it would be in scope.

> I'm not looking for a threshold, rather whether scale is (should be) part of the charter?

Something like sizing of a virtual network ID is tough to discuss w/out
some concrete notion of expected scale on the upper end.  On the lower
end, it may be the flexibility of an overlay that is more important
than scaling.  So I think scale is at least relevant.

thanks,
-chris

---

From: Chris Wright <[email-masked]>
Date: Tue, 3 Apr 2012 11:15:25 -0700

thanks,
-chris

---

From: Thomas Narten <[email-masked]>
Date: Wed, 04 Apr 2012 17:11:39 -0400

Hi Kireeti.

> The question is, is there really a problem to solve in the
> small/medium private cloud space?  There is an existence proof that
> existing methodologies (layer 2) work adequately here.  So, a
> rationale for including these cases would be helpful.

What do you define as "small/medium"?

I agree that where existing L2 VLANs do the job, NVO3 won't be very
attractive.

But exactly where it is perceived that L2 no longer suffices, that
will vary and different folk will have different ideas. E.g.,
TRILL/SPB could expand the definition of how big you can use L2
techniques. But not everyone may want to go that route.

In an earlier version of the charter, we tried to describe two cases
that were "small" and "large". The first case would be where
"learning" was adequate for building mapping tables and the second
case was where some sort of backend "oracle" or "directory-based
system" supplied the mappings.

So I think there is room for two "sizes" of deployments, *both* of
which are interested in an NVO3 approach.

Thomas

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 5 Apr 2012 04:03:43 +0000

Hi Kireeti,

发件人: [email-masked] [mailto:[email-masked]] 代表 Kireeti Kompella
发送时间: 2012年4月3日 8:53
收件人: [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: [nvo3] Response to some comments on IS-IS VPLS

Hi David,

[XIAOHU] The question is hard to answer since different people may have different answers. That’s why IS-IS and OSPF based L1VPN approaches were proposed and accepted even when BGP-based L1VPN approach has already been there before.

Best regards,
Xiaohu

Got it.

Cheers,
Kireeti.

Thanks,
--David