Subject: [nvo3] When is an overlay not a VPN?

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 Apr 2012 16:44:04 +0100

Hi,

I am reviewing the nvo3 draft charter for the IESG telechat this week and I
stumbled on the distinction between "overlay" and "VPN".

Would someone like to risk two sentences of definition that allows me to see the
difference?

Thanks,
Adrian

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Apr 2012 12:03:45 -0400

Hi Adrian.

> Would someone like to risk two sentences of definition that allows
> me to see the difference?

OK, I'll bite. :-)

At a high-level, one can say they are similar. In terms of the service
they provide to the customer (the tenants) they proide a service that
looks like a private network, built over WAN or other links. With
tenants isolated from each other.

Note that one could say that conceptually, an L2 VLAN is also a
"VPN". It too provides a way of providing tentants a virtual network
(a specific VLAN) that is isolated from other tenants. 

I think the key difference is that when the term VPN is used, there is
an assumption it means the gluing together of tenants across a WAN
using "VPN" protocols such as VPLS. 

And while a VLAN is conceptually similar to a VPN, we tend to think of
a VLAN being different from a VPN because VLANs are local to a data
center. (Of course, VPN technology usually glues together VLANs, so
the description is imperfect.)

So, I think the 2 sentence difference is that the term VPN is
generally associated with a particular set of existing protocols and
deployment models. And in the case of the L2VPN/L3VPN work in
particular, a strong emphasis on provider managed/provisioned across
WAN links.

For overlays (in the NVO3 context), there is no service provider
involved at all (in most cases). And there is a sense that the tools
used to provide VPN services across a WAN are sub-optimal in a DC
environment and are just not the right starting point. And in
particular that an NVO3-based alternative offers a number of
compelling benefits to the pain that is being felt.

Hope that helps!

Thomas

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Apr 2012 17:15:38 +0100

On 11/04/2012 16:44, Adrian Farrel wrote:
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

I usually consider that an overlay to be VPN that the provider of the
underlying network is unaware of.

Stewart

---

From: "Stiliadis, Dimitrios (Dimitri)" <[email-masked]>
Date: Wed, 11 Apr 2012 11:17:43 -0500

I knew that this is going to be interesting .. I agree with most comments,
other than a couple .. see below:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas
> Narten
> Sent: Wednesday, April 11, 2012 9:04 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [nvo3] When is an overlay not a VPN?
> 
> Hi Adrian.
> 

A "DC operator" is a service provider for any practical purpose, in
the sense that the operator has "administrative" control over 
specific resources. The goal of the overlay and the operator 
is to isolate tenants and there is an explicit provider/tenant 
relationship. It is just that the operator chooses to 
utilize server virtualization techniques to achieve that, rather 
than rely on network only techniques. But this boundary is kind 
of blurry.

Even though one can also use NVO3 for creating overlays from within
the VMs (and we never talked about this use case), the model we 
are discussing here assumes a tenant/provider relationship.
Let me clarify this: In one use case NVO3 can be initiated inside the VMs. 
I can install a driver that does encapsulation (ie NVE is inside the VM), 
and I can create an overlay between my VMs. I can have VMs in different 
clouds, and I can make my applications thing that they are in the same 
LAN. This is one form of cloud bursting that people are discussing
about and it resolves several problems with crossing administrative
domains. In this case, there is indeed no tenant/provider relationship,
but I am not sure we have discussed it in detail.

Dimitri

---

From: David Allan I <[email-masked]>
Date: Wed, 11 Apr 2012 12:27:16 -0400

Hi Adrian:

Technically an overlay does not have to be a VPN, one can overlay one large any-to-any community of interest on another, but that only benefits state in the core if # of CE >> # of PE, and offers some isolation between core and client; each edge still requires a full forwarding table for the larger community. If one considers many smaller communities of interest then the opportunity to divide and conquer at the edge emerges as well.

If there was text, it would be to suggest an architectural shortcut had already been taken:

"An overlay approach is the preferred solution to VPNs for multi-tenacy, as it provides opportunities to limit the state in any one platform, and confines the provisioning of per-VPN connectivity policy to the edge devices"

I'm not sure how else to play it...
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, April 11, 2012 8:44 AM
To: [email-masked]
Subject: [nvo3] When is an overlay not a VPN?

Hi,

I am reviewing the nvo3 draft charter for the IESG telechat this week and I stumbled on the distinction between "overlay" and "VPN".

Would someone like to risk two sentences of definition that allows me to see the difference?

Thanks,
Adrian

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Apr 2012 12:34:56 -0400

Hi Dimtri.

"Stiliadis, Dimitrios (Dimitri)" <[email-masked]> writes:

> I knew that this is going to be interesting ..

Indeed! :-)

> than rely on network only techniques. But this boundary is kind 

Let me further clarify then. Yes, of course a DC operator has someone
operating the network. But I don't think of them as a "service
provider" in the conventional sense. There are plenty of big operators
today that are "service providers". There primary and/or historical
focus has been on providing connectivity between sites.

For many DCs, there is a very clear and firm boundary between the SP
part of the network and the internal network. The SP network attaches
to the DC network in a very controlled and localized place, Think of
the PE/CE boundary. The SP network (administrative, etc.) does NOT
extend into the DC itself.

Within the DC, it is a DC operator that runs the network (and
DC). They have a very different mind set from traditional SPs. They
have different problems to deal with, different things they are
optimizing, etc.

I do not think it is helpful to equate DC network operators with
traditional SPs.

> Let me clarify this: In one use case NVO3 can be initiated inside

Personally, I don't find this use case particularly interesting and I
don't believe it should be a focus of NVO3. It requires individual VMs
to be aware of NVO3 and somehow participate. I think that has huge
negative implications from a deployment perspective.

A fundamental selling point of NVO3 is that VMs (and legacy systems or
"traditional hosts") can be supported unmodified.

> but I am not sure we have discussed it in detail.

As a starting point for discussion, let me posit that this use case
should be out-of-scope for NVO3.

Do others feel differently?

Thomas

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 11 Apr 2012 12:45:50 -0400

> Would someone like to risk two sentences of definition that allows me to see the

Here is a cut, based on my experience in the field :

A VPN implies some sort of security (i.e., protection of the contents
of the packets in the VPN). An overlay network may not.

Regards
Marshall

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Wed, 11 Apr 2012 12:15:54 -0500

>From a general architecture point of view there are a lot of similarities in my opinion between VPNs and NVO3 - this does not qualify as one sentence describing the differences! :)

What is definitely new is the initiation/control of service/VPN auto-provisioning from the compute side and the push to get PE-like functions in the software-based VSwitch. These VSwitches have also less resources available for networking (control and/or data plane) compared with the usual PEs and their number can easily reach 10Ks, having heard of 100K servers/VSwitches per DC. 

My 2 sentence shot for what is worth...

> I am reviewing the nvo3 draft charter for the IESG telechat this week
> and I stumbled on the distinction between "overlay" and "VPN".
>

---

From: "Stiliadis, Dimitrios (Dimitri)" <[email-masked]>
Date: Wed, 11 Apr 2012 12:17:40 -0500

Thomas:

My suggestion is to define everything around administrative domains,
and I clearly see three of them:
1. Tenants that require isolation
2. Overlay domains provide network service to tenants
3. Underlay domains provide transport service to overlay domains.

In an overlay network, the overlay domain provides a network 
virtualization service over one or multiple underlay domains.

In a "managed VPN" case, the overlay and underlay domains
are often (but not always) the same administrative authority.

Note, that I am explicitly defining this as "managed VPN" and not just
VPN, since an IPSec based BGP-VPN could also be classified as an 
overlay. (see for example the AWS VPC deployment that is along the same
lines and requires no relationship between overlay and underlay).

Dimitri

> From: Thomas Narten [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2012 9:35 AM
> To: Stiliadis, Dimitrios (Dimitri)
> Cc: [email-masked]; [email-masked]

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Apr 2012 11:23:31 -0700

Stewart,

I don't think this is correct.  The data center owner is both "the provider of the underlying network" and the provider of the VPN service.

Thanks,

John 

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stewart Bryant
> Sent: Wednesday, April 11, 2012 9:16 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Apr 2012 11:31:38 -0700

Comment inline.

Sent from my iPhone

> David Allan I
> Sent: Wednesday, April 11, 2012 9:27 AM
> To: [email-masked]; [email-masked]
> Technically an overlay does not have to be a VPN, one can overlay one
> large any-to-any community of interest on another, but that only
> benefits state in the core if # of CE >> # of PE, and offers some
> isolation between core and client; each edge still requires a full
> forwarding table for the larger community. If one considers many
> smaller communities of interest then the opportunity to divide and
> conquer at the edge emerges as well.
> 
> "An overlay approach is the preferred solution to VPNs for multi-
> tenacy, as it provides opportunities to limit the state in any one
> platform, and confines the provisioning of per-VPN connectivity policy
> to the edge devices"

[JD] I have two problems with this.  It doesn't define the term 'overlay approach' and the balance of the text is perfectly applicable to existing L2/L3 VPN technologies.

> Adrian Farrel

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 11 Apr 2012 14:51:41 -0400

John,

I have to agree with Stewart. The most general case is that the DC and
the underlying network have different ownerships, and even if they are
the same, they may be different groups with the DC group a customer of
the underlying network group. The nvo3 goal is to provide logical
separation for the DC customers without requiring any active
involvement of the underlying network.

Cheers,
Andy

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Apr 2012 12:02:24 -0700

Adrian,

I checked around and sections 4 and 4.1 of http://tools.ietf.org/html/draft-narten-nvo3-overlay-problem-statement-01 attempt to define 'overlay'  The only problem is that its definition is equally applicable to existing L2/L3 VPN technologies.

(And, of course, the description of VRFs in section 3.1 is completely wrong.)

If the term 'overlay' is not defined in the charter, it shouldn't be used in the charter.  Similarly, if it can't be defined in a way which is distinguishable from the term 'VPN', it also shouldn't be used in the charter.

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Apr 2012 12:18:16 -0700

Snipped...

> involved at all (in most cases).

[JD]  You seem to assume that the only ones allowed to deploy existing L2/L3 *technologies* are service providers.  As far as I know, there are no VPN police to enforce this.  

> And there is a sense that the tools
> particular that an NVO3-based alternative offers a number of compelling
> benefits to the pain that is being felt.

[JD]  There is no consensus on these points and the people making these points have yet to provide any substantive evidence of their correctness.  Further, the people making these points claim to be making them on behalf of a vast silent group of data center operators, which I find to be extremely presumptuous.

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Apr 2012 12:28:54 -0700

Andy,

There are many 'underlying networks', but in this discussion I think the underlying network is the data center network and it is the owner of this network that will be offering the NV03 service to its tenants.

Thanks,

John 

Sent from my iPhone

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2012 11:52 AM
> To: John E Drake
> Cc: [email-masked]; [email-masked]; [email-masked]
> > I don't think this is correct.  The data center owner is both "the
> provider of the underlying network" and the provider of the VPN
> service.
> >
> > Thanks,
> >
> > John
> >
> > Sent from my iPhone
> >
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Stewart Bryant
> >> > I am reviewing the nvo3 draft charter for the IESG telechat this
> >> > week and I stumbled on the distinction between "overlay" and
> "VPN".
> >> >

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 11 Apr 2012 19:40:40 +0000

Adrian,

Ok, veeeeery broadly....

*       The term 'VPN', as used in the IETF requires 'some' involvement by the underlying IP network.

*       The term 'Overlay', as used in this context requires 'no' involvement by the underlying IP network.

Of course the degree of 'some' v.s. 'no' is open for debate but that's probably the simplest high level view of the terminology difference + baggage I can think of.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, April 11, 2012 11:44 AM
To: [email-masked]
Subject: [nvo3] When is an overlay not a VPN?

Hi,

Thanks,
Adrian

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Apr 2012 12:52:56 -0700

Peter,

I don't think that is correct.  In existing L2/L3 VPN technologies, the VPN awareness is restricted to the PEs.  In NV03, the VPN awareness is restricted to the NV03 edge nodes (aka PEs).

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, April 11, 2012 12:41 PM
To: [email-masked]; [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Adrian,

Ok, veeeeery broadly....

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, April 11, 2012 11:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] When is an overlay not a VPN?

Hi,

Thanks,
Adrian

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

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 11 Apr 2012 19:52:19 +0000

>Thomas

Strongly agree because to do otherwise will raise serious security concerns. Infact a security section should explicitly discuss how this is preventable otherwise nobody will trust the encap starting on the servers.

Peter Ashwood-Smith

---

From: David Allan I <[email-masked]>
Date: Wed, 11 Apr 2012 15:55:31 -0400

Hi John:

You could also define a VPN "flat" via policy based forwarding, massive deployment of permit/deny filtering. Say TCAMs perhaps with some central control logic...

So IMO there is a distinction.

Not sure it goes all the way to address your concerns tho...

Cheers
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Wednesday, April 11, 2012 12:02 PM
To: [email-masked]; [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Adrian,

Thanks,

John

Sent from my iPhone

> Of Adrian Farrel

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 11 Apr 2012 20:06:16 +0000

Hey John,

Yeah but the P's have to get involved for ALL the VPN's via LDP ;) .. which was what I was getting at with 'some'. That's definitely not a property of 'no'

Otherwise they are the same and then presumably Adrian has a problem ;)

Peter

________________________________
From: John E Drake [mailto:[email-masked]]
Sent: Wednesday, April 11, 2012 3:53 PM
To: AshwoodsmithPeter; [email-masked]; [email-masked]
Subject: RE: [nvo3] When is an overlay not a VPN?

Peter,

Thanks,

John

Sent from my iPhone

Adrian,

Ok, veeeeery broadly....

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, April 11, 2012 11:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] When is an overlay not a VPN?

Hi,

Thanks,
Adrian

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Wed, 11 Apr 2012 15:16:52 -0500

Peter,
There are IP tunneling options for VPNs that do not require on P devices LDP or any other signaling.
Florin

From: [email-masked] [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, April 11, 2012 1:06 PM
To: John E Drake; [email-masked]; [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Hey John,

Peter

To: AshwoodsmithPeter; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Peter,

Thanks,

John

Sent from my iPhone

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Wednesday, April 11, 2012 12:41 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] When is an overlay not a VPN?

Adrian,

Ok, veeeeery broadly....

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, April 11, 2012 11:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] When is an overlay not a VPN?

Hi,

Thanks,
Adrian

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 11 Apr 2012 13:17:24 -0700

Hi Peter,

VPN services are offered in 2 different paradigms, roughly:
Overlay (IPsec SSL, etc)/ Peer-to-peer (MPLS/ ATM etc)

So in my view Overlay is a type of a VPN connectivity.

However in the NVO3 context I think the difference is where the tunnels
start.

Thanks,
Vishwas

On Wed, Apr 11, 2012 at 12:40 PM, AshwoodsmithPeter <
[email-masked]> wrote:

>
> Adrian,
>
> Ok, veeeeery broadly....
>
>
>     - The term 'VPN', as used in the IETF requires 'some' involvement by
>    the underlying IP network.
>
>
>
>     - The term 'Overlay', as used in this context requires 'no'
>    involvement by the underlying IP network.
>
>
> Of course the degree of 'some' v.s. 'no' is open for debate but that’s
> probably the simplest high level view of the terminology difference +
> baggage I can think of.
>
> Peter
>
>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of Adrian Farrel

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Apr 2012 13:19:39 -0700

Peter,

The VPN labels for a given VPN are distributed only to the PEs in that VPN, and any intervening RRs.    if you are using MPLS/LDP, the only labels that are being distributed are those for each PE's loopback address, which are probably also being used for normal IP forwarding.  If you don't want to use MPLS,  you can use non-MPLS tunnels between the PEs, so that MPLS is used strictly between the PEs to mux/demux packets.

Thanks,

John

Sent from my iPhone

From: AshwoodsmithPeter [mailto:[email-masked]]
Sent: Wednesday, April 11, 2012 1:06 PM
To: John E Drake; [email-masked]; [email-masked]
Subject: RE: [nvo3] When is an overlay not a VPN?

Hey John,

Peter

Peter,

Thanks,

John

Sent from my iPhone

Adrian,

Ok, veeeeery broadly....

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, April 11, 2012 11:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] When is an overlay not a VPN?

Hi,

Thanks,
Adrian

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 11 Apr 2012 13:22:54 -0700

Peter/ Florin,

In this context it is more about the communication between PE/ CE devices.

When we use IP tunneling in the core, we are overlaying a GRE/ L2TP tunnel
over the core. However from the context of the CE it would be a
peer-to-peer VPN.

Thanks,
Vishwas

On Wed, Apr 11, 2012 at 1:16 PM, Balus, Florin Stelian (Florin) <
[email-masked]> wrote:

> Peter,****
>
> There are IP tunneling options for VPNs that do not require on P devices
> LDP or any other signaling.****
>
> Florin****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *AshwoodsmithPeter
> *Sent:* Wednesday, April 11, 2012 1:06 PM
> *To:* John E Drake; [email-masked]; [email-masked]
>
> *Subject:* Re: [nvo3] When is an overlay not a VPN?****
>
> ** **
>
> Hey John,****
>
> ** **
>
> Yeah but the P’s have to get involved for ALL the VPN’s via LDP ;) ..
> which was what I was getting at with ‘some’. That’s definitely not a
> property of ‘no’****
>
> ** **
>
> Otherwise they are the same and then presumably Adrian has a problem ;)***
> *
>
> ** **
>
> Peter****
>
> ** **
> ------------------------------
>
> *From:* John E Drake [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, April 11, 2012 3:53 PM
> *To:* AshwoodsmithPeter; [email-masked]; [email-masked]
> *Subject:* RE: [nvo3] When is an overlay not a VPN?****
>
> ** **
>
> Peter,****
>
> ** **
>
> I don’t think that is correct.  In existing L2/L3 VPN technologies, the
> VPN awareness is restricted to the PEs.  In NV03, the VPN awareness is
> restricted to the NV03 edge nodes (aka PEs).****
>
> ** **
>
> Thanks,****
>
> ** **
>
> John  ****
>
> ** **
>
> Sent from my iPhone****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *AshwoodsmithPeter
> *Sent:* Wednesday, April 11, 2012 12:41 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [nvo3] When is an overlay not a VPN?****
>
> ** **
>
>  ****
>
> Adrian,****
>
>  ****
>
> Ok, veeeeery broadly....****
>
>  ****
>
> **·         **The term 'VPN', as used in the IETF requires 'some'
> involvement by the underlying IP network.****
>
>  ****
>
> **·         **The term 'Overlay', as used in this context requires 'no'
> involvement by the underlying IP network.****
>
>  ****
>
> baggage I can think of.****
>
>  ****
>
> Peter****
>
>  ****
>
>  ****
>
> Subject: [nvo3] When is an overlay not a VPN?****
>
>  ****
>
> Hi,****
>
>  ****
>
> ****
> stumbled on the distinction between "overlay" and "VPN".****
>
>  ****
>
> Would someone like to risk two sentences of definition that allows me to
> see the****
>
> difference?****
>
>  ****
>
> Thanks,****
>
> Adrian****
>
>  ****
>
> _______________________________________________****
>
> nvo3 mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/nvo3****
>
>  ****
>

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 11 Apr 2012 13:35:34 -0700

Hi Peter/ Adrian,

Just to clarify further in the Overlay, the 2 end devices talk directly to
each other. Issues with overlays include scalability, advantages include
can work irrespective of lower layer.

In the case of P2P, the intermediate network is a peer to the end devices.
The provider/ lower network has to do most of the work to provide isolation
etc.

Does it make things clearer?

Thanks,
Vishwas

On Wed, Apr 11, 2012 at 1:17 PM, Vishwas Manral <[email-masked]>wrote:

>> see the

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 11 Apr 2012 20:44:17 +0000

Hey John, thanks but I do understand label stacks and that the labels managed by P routers are not per VPN and that 'normally' they exist as a pre-requisit to all VPNs. Of course if you chose not to run over LDP but put the service labels over IP, then things start to look pretty similar between an overlay and the existing IETF VPN technolgies.

Since Adrian was looking for the 'difference' this is why I highlighted 'some' involvement by the underlay ;) .. otherwise I've got nothing that can be used in a couple  sentence elevator pitch ;)

Is it fair to  presume your position is that there is no difference when MPLS VPNs run over IP?

Peter Ashwood-Smith

Sent: Wednesday, April 11, 2012 4:20 PM

Peter,

Thanks,

John

Sent from my iPhone

Hey John,

Peter

Peter,

Thanks,

John

Sent from my iPhone

Adrian,

Ok, veeeeery broadly....

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, April 11, 2012 11:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] When is an overlay not a VPN?

Hi,

Thanks,
Adrian

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 11 Apr 2012 15:47:31 -0500

Peter,

P router does not involve in VPN processing, P does not see VPN label,
it forwards VPN packet through LDP label switched path,  RSVP-TE tunnel,
or other IP tunnels, e.g. GRE tunnel... 

When outer label (non-VPN) fails, the VPN gets blackholed, as P router
has no idea of VPN label.

For BGP/MPLS L3VPN, CP and DP are separated, P supports forwarding only,
VPN PE and VPN RR have the knowledge of the VPN.

Luyuan

From: [email-masked] [mailto:[email-masked]] On Behalf Of
AshwoodsmithPeter
Sent: Wednesday, April 11, 2012 4:06 PM
To: John E Drake; [email-masked]; [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Hey John,

Yeah but the P's have to get involved for ALL the VPN's via LDP ;) ..
which was what I was getting at with 'some'. That's definitely not a
property of 'no'

Peter

Peter,

I don't think that is correct.  In existing L2/L3 VPN technologies, the
VPN awareness is restricted to the PEs.  In NV03, the VPN awareness is
restricted to the NV03 edge nodes (aka PEs).

Thanks,

John  

Sent from my iPhone

AshwoodsmithPeter

Adrian,

Ok, veeeeery broadly....

*         The term 'VPN', as used in the IETF requires 'some'
involvement by the underlying IP network.

*         The term 'Overlay', as used in this context requires 'no'
involvement by the underlying IP network.

Of course the degree of 'some' v.s. 'no' is open for debate but that's
probably the simplest high level view of the terminology difference +
baggage I can think of.

Peter

-----Original Message-----

Hi,

and I

difference?

Thanks,

Adrian

nvo3 mailing list

[email-masked]

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 11 Apr 2012 15:57:23 -0500

Peter,

VPN label is unknown to P routers. 

The forwarding mechanism can be MPLS or IP.

For VPN over GRE tunnel, see RFC 4797. 

Luyuan

From: [email-masked] [mailto:[email-masked]] On Behalf Of
AshwoodsmithPeter
Sent: Wednesday, April 11, 2012 4:44 PM
To: John E Drake; [email-masked]; [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Hey John, thanks but I do understand label stacks and that the labels
managed by P routers are not per VPN and that 'normally' they exist as a
pre-requisit to all VPNs. Of course if you chose not to run over LDP but
put the service labels over IP, then things start to look pretty similar
between an overlay and the existing IETF VPN technolgies.

Since Adrian was looking for the 'difference' this is why I highlighted
'some' involvement by the underlay ;) .. otherwise I've got nothing that
can be used in a couple  sentence elevator pitch ;)

Is it fair to  presume your position is that there is no difference when
MPLS VPNs run over IP? 

Peter Ashwood-Smith

Peter,

The VPN labels for a given VPN are distributed only to the PEs in that
VPN, and any intervening RRs.    if you are using MPLS/LDP, the only
labels that are being distributed are those for each PE's loopback
address, which are probably also being used for normal IP forwarding.
If you don't want to use MPLS,  you can use non-MPLS tunnels between the
PEs, so that MPLS is used strictly between the PEs to mux/demux packets.

Thanks,

John

Sent from my iPhone

Hey John,

Peter

Peter,

Thanks,

John  

Sent from my iPhone

 

Adrian,

Ok, veeeeery broadly....

Peter

-----Original Message-----

Hi,

difference?

Thanks,

Adrian

nvo3 mailing list

[email-masked]

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 11 Apr 2012 20:57:27 +0000

Sure, but given two sets S1 = (A B) and S2 = (B) the correct answer for why they are different is A ... which I believe was the original question.

The fact that they intersect at B is the answer to a different question that was not asked ;)

Peter

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Balus, Florin Stelian (Florin)
Sent: Wednesday, April 11, 2012 4:17 PM
To: AshwoodsmithPeter; John E Drake; [email-masked]; [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Peter,

Hey John,

Peter

Peter,

Thanks,

John

Sent from my iPhone

Adrian,

Ok, veeeeery broadly....

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, April 11, 2012 11:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] When is an overlay not a VPN?

Hi,

Thanks,
Adrian

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 11 Apr 2012 14:11:51 -0700

Peter,

> Hey John, thanks but I do understand label stacks and that the labels manag=
> ed by P routers are not per VPN and that 'normally' they exist as a pre-req=
> uisit to all VPNs. Of course if you chose not to run over LDP but put the 
> service labels over IP, then things start to look pretty similar between an =
> overlay and the existing IETF VPN technolgies.

Note that an overlay does use tunnels. With this in mind, can an overlay 
use MPLS for creating tunnels ?

Yakov.
  
> Since Adrian was looking for the 'difference' this is why I highlighted 'so=
> me' involvement by the underlay ;) .. otherwise I've got nothing that can b=
> e used in a couple  sentence elevator pitch ;)
> 
> Is it fair to  presume your position is that there is no difference when MP=
> LS VPNs run over IP?
> 
> Peter Ashwood-Smith
> 
> The VPN labels for a given VPN are distributed only to the PEs in that VPN,=
>  and any intervening RRs.    if you are using MPLS/LDP, the only labels tha=
> t are being distributed are those for each PE's loopback address, which are=
>  probably also being used for normal IP forwarding.  If you don't want to u=
> se MPLS,  you can use non-MPLS tunnels between the PEs, so that MPLS is use=
> d strictly between the PEs to mux/demux packets.
> 
> Thanks,
> 
> John
> 
> Sent from my iPhone
> 
> Yeah but the P's have to get involved for ALL the VPN's via LDP ;) .. which=
>  was what I was getting at with 'some'. That's definitely not a property of=
>  'no'
> 
> To: AshwoodsmithPeter; [email-masked]<mailto:[email-masked]>; nvo=
> [email-masked]<mailto:[email-masked]>
> I don't think that is correct.  In existing L2/L3 VPN technologies, the VPN=
>  awareness is restricted to the PEs.  In NV03, the VPN awareness is restric=
> ted to the NV03 edge nodes (aka PEs).
> 
> Thanks,
> 
> John
> 
> Sent from my iPhone
> 
> From: [email-masked]<mailto:[email-masked]> [mailto:nvo3-boun=
> [email-masked]] On Behalf Of AshwoodsmithPeter
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:n=
> [email-masked]>
> *                    The term 'VPN', as used in the IETF requires 'some' in=
> volvement by the underlying IP network.
> 
> *                    The term 'Overlay', as used in this context requires '=
> no' involvement by the underlying IP network.
> 
> Of course the degree of 'some' v.s. 'no' is open for debate but that's prob=
> ably the simplest high level view of the terminology difference + baggage I=
>  can think of.
> 
> Peter
> 
> 
> From: [email-masked]<mailto:[email-masked]> [mailto:nvo3-boun=
> [email-masked]] On Behalf Of Adrian Farrel
> Would someone like to risk two sentences of definition that allows me to se=
> e the
> difference?
> 
> Thanks,
> Adrian
> 
> --_000_7AE6A4247B044C4ABE0A5B6BF427F8E293916Edfweml503mbx_
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
> osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww=
> w.w3.org/TR/REC-html40" xmlns:ns0=3D"http://schemas.microsoft.com/office/20=
> 04/12/omml">
> <head>
> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
> >
> <meta name=3D"Generator" content=3D"Microsoft Word 11 (filtered medium)">
> <!--[if !mso]>
> <style>
> v\:* {behavior:url(#default#VML);}
> o\:* {behavior:url(#default#VML);}
> w\:* {behavior:url(#default#VML);}
> .shape {behavior:url(#default#VML);}
> </style>
> <![endif]--><o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:offic=
> e:smarttags" name=3D"City" /><o:SmartTagType namespaceuri=3D"urn:schemas-mi=
> crosoft-com:office:smarttags" name=3D"place" /><!--[if !mso]>
> <style>
> st1\:*{behavior:url(#default#ieooui) }
> </style>
> <![endif]--><style>
> <!--a:link
> 	{mso-style-priority:99;}
> span.MSOHYPERLINK
> 	{mso-style-priority:99;}
> a:visited
> 	{mso-style-priority:99;}
> span.MSOHYPERLINKFOLLOWED
> 	{mso-style-priority:99;}
> p.MSOACETATE
> 	{mso-style-priority:99;}
> li.MSOACETATE
> 	{mso-style-priority:99;}
> div.MSOACETATE
> 	{mso-style-priority:99;}
> span.BALLOONTEXTCHAR
> 	{mso-style-priority:99;}
> span.BALLOONTEXTCHAR0
> 	{mso-style-priority:99;}
> 
>  /* Font Definitions */
>  @font-face
> 	{font-family:Batang;
> 	panose-1:2 3 6 0 0 1 1 1 1 1;}
> @font-face
> 	{font-family:Tahoma;
> 	panose-1:2 11 6 4 3 5 4 4 2 4;}
> @font-face
> 	{font-family:"\@Batang";
> 	panose-1:2 3 6 0 0 1 1 1 1 1;}
> @font-face
> 	{font-family:Calibri;
> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
>  /* Style Definitions */
>  p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:12.0pt;
> 	font-family:"Times New Roman";}
> a:link, span.MsoHyperlink
> 	{color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{color:purple;
> 	text-decoration:underline;}
> p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:8.0pt;
> 	font-family:Tahoma;}
> span.BalloonTextChar
> 	{font-family:Tahoma;}
> p.emailquote, li.emailquote, div.emailquote
> 	{mso-margin-top-alt:auto;
> 	margin-right:0in;
> 	mso-margin-bottom-alt:auto;
> 	margin-left:1.0pt;
> 	font-size:12.0pt;
> 	font-family:"Times New Roman";}
> span.balloontextchar0
> 	{font-family:Tahoma;}
> span.EmailStyle21
> 	{mso-style-type:personal;
> 	font-family:Calibri;
> 	color:#1F497D;}
> span.EmailStyle22
> 	{mso-style-type:personal;
> 	font-family:Arial;
> 	color:navy;}
> span.EmailStyle23
> 	{mso-style-type:personal;
> 	font-family:Calibri;
> 	color:#1F497D;}
> span.EmailStyle24
> 	{mso-style-type:personal-reply;
> 	font-family:Arial;
> 	color:navy;}
> @page Section1
> 	{size:8.5in 11.0in;
> 	margin:1.0in 1.0in 1.0in 1.0in;}
> div.Section1
> 	{page:Section1;}
>  /* List Definitions */
>  @list l0
> 	{mso-list-id:493883260;
> 	mso-list-template-ids:1471716540;}
> @list l0:level1
> 	{mso-level-number-format:bullet;
> 	mso-level-text:\F0B7;
> 	mso-level-tab-stop:.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;
> 	mso-ansi-font-size:10.0pt;
> 	font-family:Symbol;}
> @list l0:level2
> 	{mso-level-tab-stop:1.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level3
> 	{mso-level-tab-stop:1.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level4
> 	{mso-level-tab-stop:2.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level5
> 	{mso-level-tab-stop:2.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level6
> 	{mso-level-tab-stop:3.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level7
> 	{mso-level-tab-stop:3.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level8
> 	{mso-level-tab-stop:4.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level9
> 	{mso-level-tab-stop:4.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l1
> 	{mso-list-id:1868328856;
> 	mso-list-template-ids:-685047888;}
> @list l1:level1
> 	{mso-level-number-format:bullet;
> 	mso-level-text:\F0B7;
> 	mso-level-tab-stop:.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;
> 	mso-ansi-font-size:10.0pt;
> 	font-family:Symbol;}
> @list l1:level2
> 	{mso-level-tab-stop:1.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l1:level3
> 	{mso-level-tab-stop:1.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l1:level4
> 	{mso-level-tab-stop:2.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l1:level5
> 	{mso-level-tab-stop:2.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l1:level6
> 	{mso-level-tab-stop:3.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l1:level7
> 	{mso-level-tab-stop:3.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l1:level8
> 	{mso-level-tab-stop:4.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l1:level9
> 	{mso-level-tab-stop:4.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> ol
> 	{margin-bottom:0in;}
> ul
> 	{margin-bottom:0in;}
> -->
> </style><!--[if gte mso 9]><xml>
>  <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
>  <o:shapelayout v:ext=3D"edit">
>   <o:idmap v:ext=3D"edit" data=3D"1" />
>  </o:shapelayout></xml><![endif]-->
> </head>
> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
> <div class=3D"Section1">
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy">Hey John, thanks but I do understand l=
> abel stacks and that the labels managed by P routers are not per VPN and th=
> at &#8216;normally&#8217; they exist
>  as a pre-requisit to all VPNs. Of course if you chose not to run over LDP =
> but put the service labels over IP, then things start to look pretty simila=
> r between an overlay and the existing IETF VPN technolgies.<o:p></o:p></spa=
> n></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy">Since
> <st1:City w:st=3D"on"><st1:place w:st=3D"on">Adrian</st1:place></st1:City> =
> was looking for the &#8216;difference&#8217; this is why I highlighted &#82=
> 16;some&#8217; involvement by the underlay ;) .. otherwise I&#8217;ve got n=
> othing that can be used in a couple &nbsp;sentence elevator pitch ;)<o:p></=
> o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy">Is it fair to &nbsp;presume your posit=
> ion is that there is no difference when MPLS VPNs run over IP?
> <o:p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy">Peter Ashwood-Smith<o:p></o:p></span><=
> /font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p>
> <div>
> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><font=
>  size=3D"3" face=3D"Times New Roman"><span style=3D"font-size:12.0pt">
> <hr size=3D"2" width=3D"100%" align=3D"center" tabindex=3D"-1">
> </span></font></div>
> <p class=3D"MsoNormal"><b><font size=3D"2" face=3D"Tahoma"><span style=3D"f=
> ont-size:10.0pt;
> font-family:Tahoma;font-weight:bold">From:</span></font></b><font size=3D"2=
> " face=3D"Tahoma"><span style=3D"font-size:10.0pt;font-family:Tahoma"> John=
>  E Drake [mailto:[email-masked]]
> <br>
> <b><span style=3D"font-weight:bold">Sent:</span></b> Wednesday, April 11, 2=
> 012 4:20 PM<br>
> <b><span style=3D"font-weight:bold">To:</span></b> AshwoodsmithPeter; adria=
> [email-masked]; [email-masked]<br>
> <b><span style=3D"font-weight:bold">Subject:</span></b> RE: [nvo3] When is =
> an overlay not a VPN?</span></font><o:p></o:p></p>
> </div>
> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 12.0pt"><o:p>&nbsp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D">Peter,<o=
> :p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D"><o:p>&nb=
> sp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D">The VPN =
> labels for a given VPN are distributed only to the PEs in that VPN, and any=
>  intervening RRs.&nbsp; &nbsp;&nbsp;if you are using MPLS/LDP,
>  the only labels that are being distributed are those for each PE&#8217;s l=
> oopback address, which are probably also being used for normal IP forwardin=
> g.&nbsp; If you don&#8217;t want to use MPLS, &nbsp;you can use non-MPLS tu=
> nnels between the PEs, so that MPLS is used strictly between
>  the PEs to mux/demux packets.<o:p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D"><o:p>&nb=
> sp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D">Thanks,<=
> o:p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D"><o:p>&nb=
> sp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D">John<o:p=
> ></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D"><o:p>&nb=
> sp;</o:p></span></font></p>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D">Sent fro=
> m my iPhone<o:p></o:p></span></font></p>
> </div>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D"><o:p>&nb=
> sp;</o:p></span></font></p>
> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
> 4.0pt">
> <div>
> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
> 0in 0in">
> <p class=3D"MsoNormal"><b><font size=3D"2" face=3D"Tahoma"><span style=3D"f=
> ont-size:10.0pt;
> font-family:Tahoma;font-weight:bold">From:</span></font></b><font size=3D"2=
> " face=3D"Tahoma"><span style=3D"font-size:10.0pt;font-family:Tahoma"> Ashw=
> oodsmithPeter [mailto:[email-masked]]
> <br>
> <b><span style=3D"font-weight:bold">Sent:</span></b> Wednesday, April 11, 2=
> 012 1:06 PM<br>
> <b><span style=3D"font-weight:bold">To:</span></b> John E Drake; adrian@old=
> dog.co.uk; [email-masked]<br>
> <b><span style=3D"font-weight:bold">Subject:</span></b> RE: [nvo3] When is =
> an overlay not a VPN?<o:p></o:p></span></font></p>
> </div>
> </div>
> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 12.0pt"><o:p>&nbsp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy">Hey John,<o:p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy">Yeah but the P&#8217;s have to get inv=
> olved for ALL the VPN&#8217;s via LDP ;) .. which was what I was getting at=
>  with &#8216;some&#8217;. That&#8217;s definitely
>  not a property of &#8216;no&#8217;<o:p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy">Otherwise they are the same and then p=
> resumably
> <st1:City w:st=3D"on"><st1:place w:st=3D"on">Adrian</st1:place></st1:City> =
> has a problem ;)<o:p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy">Peter<o:p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"navy" face=3D"Arial"><span=
>  style=3D"font-size:
> 10.0pt;font-family:Arial;color:navy"><o:p>&nbsp;</o:p></span></font></p>
> <div>
> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><font=
>  size=3D"3" face=3D"Times New Roman"><span style=3D"font-size:12.0pt">
> <hr size=3D"2" width=3D"100%" align=3D"center">
> </span></font></div>
> <p class=3D"MsoNormal"><b><font size=3D"2" face=3D"Tahoma"><span style=3D"f=
> ont-size:10.0pt;
> font-family:Tahoma;font-weight:bold">From:</span></font></b><font size=3D"2=
> " face=3D"Tahoma"><span style=3D"font-size:10.0pt;font-family:Tahoma"> John=
>  E Drake [<a href=3D"mailto:[email-masked]">mailto:[email-masked]</=
> a>]
> <br>
> <b><span style=3D"font-weight:bold">Sent:</span></b> Wednesday, April 11, 2=
> 012 3:53 PM<br>
> <b><span style=3D"font-weight:bold">To:</span></b> AshwoodsmithPeter; <a hr=
> ef=3D"mailto:[email-masked]">
> [email-masked]</a>; <a href=3D"mailto:[email-masked]">[email-masked]</a>=
> <br>
> <b><span style=3D"font-weight:bold">Subject:</span></b> RE: [nvo3] When is =
> an overlay not a VPN?</span></font><o:p></o:p></p>
> </div>
> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 12.0pt"><o:p>&nbsp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D">Peter,<o=
> :p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D"><o:p>&nb=
> sp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D">I don&#8=
> 217;t think that is correct.&nbsp; In existing L2/L3 VPN technologies, the =
> VPN awareness is restricted to the PEs.&nbsp; In NV03, the
>  VPN awareness is restricted to the NV03 edge nodes (aka PEs).<o:p></o:p></=
> span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D"><o:p>&nb=
> sp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D">Thanks,<=
> o:p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D"><o:p>&nb=
> sp;</o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D">John &nb=
> sp;<o:p></o:p></span></font></p>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D"><o:p>&nb=
> sp;</o:p></span></font></p>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D">Sent fro=
> m my iPhone<o:p></o:p></span></font></p>
> </div>
> <p class=3D"MsoNormal"><font size=3D"2" color=3D"#1f497d" face=3D"Calibri">=
> <span style=3D"font-size:11.0pt;font-family:Calibri;color:#1F497D"><o:p>&nb=
> sp;</o:p></span></font></p>
> <div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
> 4.0pt">
> <div>
> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
> 0in 0in">
> <p class=3D"MsoNormal"><b><font size=3D"2" face=3D"Tahoma"><span style=3D"f=
> ont-size:10.0pt;
> font-family:Tahoma;font-weight:bold">From:</span></font></b><font size=3D"2=
> " face=3D"Tahoma"><span style=3D"font-size:10.0pt;font-family:Tahoma">
> <a href=3D"mailto:[email-masked]">[email-masked]</a> [<a href=
> =3D"mailto:[email-masked]">mailto:[email-masked]</a>]
> <b><span style=3D"font-weight:bold">On Behalf Of </span></b>AshwoodsmithPet=
> er<br>
> <b><span style=3D"font-weight:bold">Sent:</span></b> Wednesday, April 11, 2=
> 012 12:41 PM<br>
> <b><span style=3D"font-weight:bold">To:</span></b> <a href=3D"mailto:adrian=
> @olddog.co.uk">
> [email-masked]</a>; <a href=3D"mailto:[email-masked]">[email-masked]</a>=
> <br>
> <b><span style=3D"font-weight:bold">Subject:</span></b> Re: [nvo3] When is =
> an overlay not a VPN?<o:p></o:p></span></font></p>
> </div>
> </div>
> <p class=3D"MsoNormal"><font size=3D"3" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 12.0pt"><o:p>&nbsp;</o:p></span></font></p>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 10.0pt">&nbsp;<o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font s=
> ize=3D"2" face=3D"Courier New"><span style=3D"font-size:10.0pt;font-family:=
> &quot;Courier New&quot;">Adrian</span></font></st1:place></st1:City><font s=
> ize=3D"2" face=3D"Courier New"><span style=3D"font-size:10.0pt;font-family:=
> &quot;Courier New&quot;">,</span></font><font size=3D"2"><span style=3D"fon=
> t-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">&nbsp;</span></font><font size=3D"2"><=
> span style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">Ok, veeeeery broadly....</span></font>=
> <font size=3D"2"><span style=3D"font-size:10.0pt"><o:p></o:p></span></font>=
> </p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 10.0pt">&nbsp;<o:p></o:p></span></font></p>
> </div>
> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
> lt:auto;
> margin-left:0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
> <![if !supportLists]><font size=3D"2" face=3D"Symbol"><span style=3D"font-s=
> ize:10.0pt;font-family:Symbol"><span style=3D"mso-list:Ignore">&middot;<fon=
> t size=3D"1" face=3D"Times New Roman"><span style=3D"font:7.0pt &quot;Times=
>  New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
> sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> </span></font></span></span></font><![endif]><font size=3D"2" face=3D"Couri=
> er New"><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;=
> ">The term 'VPN', as used in the IETF requires 'some' involvement by the un=
> derlying IP network.<o:p></o:p></span></font></p>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 10.0pt">&nbsp;<o:p></o:p></span></font></p>
> </div>
> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
> lt:auto;
> margin-left:0in;text-indent:-.25in;mso-list:l1 level1 lfo4">
> <![if !supportLists]><font size=3D"2" face=3D"Symbol"><span style=3D"font-s=
> ize:10.0pt;font-family:Symbol"><span style=3D"mso-list:Ignore">&middot;<fon=
> t size=3D"1" face=3D"Times New Roman"><span style=3D"font:7.0pt &quot;Times=
>  New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
> sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> </span></font></span></span></font><![endif]><font size=3D"2" face=3D"Couri=
> er New"><span style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;=
> ">The term 'Overlay', as used in this context requires 'no' involvement by =
> the underlying IP network.<o:p></o:p></span></font></p>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 10.0pt">&nbsp;<o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">Of course the degree of 'some' v.s. 'n=
> o' is open for debate but that&#8217;s probably the simplest high level vie=
> w of the terminology difference &#43; baggage
>  I can think of.</span></font><font size=3D"2"><span style=3D"font-size:10.=
> 0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 10.0pt">&nbsp;<o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">Peter</span></font><font size=3D"2"><s=
> pan style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 10.0pt">&nbsp;<o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 10.0pt">&nbsp;<o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">-----Original Message-----<br>
> From: <a href=3D"mailto:[email-masked]">[email-masked]</a> [<=
> a href=3D"mailto:[email-masked]">mailto:[email-masked]</a>] O=
> n Behalf Of Adrian Farrel<br>
> Sent: Wednesday, April 11, 2012 11:44 AM<br>
> To: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> Subject: [nvo3] When is an overlay not a VPN?</span></font><font size=3D"2"=
> ><span style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 10.0pt">&nbsp;<o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">Hi,</span></font><font size=3D"2"><spa=
> n style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">&nbsp;</span></font><font size=3D"2"><=
> span style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">I am reviewing the nvo3 draft charter =
> for the IESG telechat this week and I</span></font><font size=3D"2"><span s=
> tyle=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">stumbled on the distinction between &q=
> uot;overlay&quot; and &quot;VPN&quot;.</span></font><font size=3D"2"><span =
> style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">&nbsp;</span></font><font size=3D"2"><=
> span style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">Would someone like to risk two sentenc=
> es of definition that allows me to see the</span></font><font size=3D"2"><s=
> pan style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">difference?</span></font><font size=3D=
> "2"><span style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">&nbsp;</span></font><font size=3D"2"><=
> span style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">Thanks,</span></font><font size=3D"2">=
> <span style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font s=
> ize=3D"2" face=3D"Courier New"><span style=3D"font-size:10.0pt;font-family:=
> &quot;Courier New&quot;">Adrian</span></font></st1:place></st1:City><font s=
> ize=3D"2"><span style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">&nbsp;</span></font><font size=3D"2"><=
> span style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">______________________________________=
> _________</span></font><font size=3D"2"><span style=3D"font-size:10.0pt"><o=
> :p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;">nvo3 mailing list</span></font><font s=
> ize=3D"2"><span style=3D"font-size:10.0pt"><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;"><a href=3D"mailto:[email-masked]">nvo3@=
> ietf.org</a></span></font><font size=3D"2"><span style=3D"font-size:10.0pt"=
> ><o:p></o:p></span></font></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Courier New"><span style=3D=
> "font-size:10.0pt;
> font-family:&quot;Courier New&quot;"><a href=3D"https://www.ietf.org/mailma=
> n/listinfo/nvo3">https://www.ietf.org/mailman/listinfo/nvo3</a></span></fon=
> t><font size=3D"2"><span style=3D"font-size:10.0pt"><o:p></o:p></span></fon=
> t></p>
> </div>
> <div>
> <p class=3D"MsoNormal"><font size=3D"2" face=3D"Times New Roman"><span styl=
> e=3D"font-size:
> 10.0pt">&nbsp;<o:p></o:p></span></font></p>
> </div>
> </div>
> </div>
> </div>
> </body>
> </html>
> 
> --_000_7AE6A4247B044C4ABE0A5B6BF427F8E293916Edfweml503mbx_--
> 
> --===============7659482904959966991==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============7659482904959966991==--

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Apr 2012 06:15:43 +0900

> tenants isolated from each other.

again, 'isolated' is way too loose a term here.  if there is link
sharing of any form, the privacy issues when there is no encryption
need to be mentioned, and traffic/bandwidth sharing issues need to be
considered.

randy

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 11 Apr 2012 21:36:08 +0000

> Yakov.
  
As far as I can tell, the only real difference functionally between overlay and MPLS VPN's happens when you have to use a specific core transport besides IP. I.e. my 'some' involvement by the core.

If the core transport is IP, then (multicast not withstanding) there is 'no' involvement by the core and so the two are equivalent irrespective of what format you use to differenciate tennants.

So I think that 'some' v.s. 'no' involvement by the core is a useful point of differenciation but yes .. MPLS is capable of having 'no' involvement too .. in 'some' circumstances ;) .. hence YES to your question.

Peter

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 11 Apr 2012 16:38:08 -0500

Peter,

VPN is one kind (actually many types of VPNs here) of Overlay with
certain level of security.

There are different types of IETF VPNs, e.g. IPSec VPN, L3VPN, L2VPN...
VPNs are generally overlay technology using some sort of tunnels. 

The difference we are often looking is where the terminating points of
the VPNs, for what purpose using the VPN (encryption or route
isolation?), who operates it...

IPSec is mostly for end users, can be SP managed service as well.

L3VPN and L2VPN started as and still largely is SP provisioned, later
extended to enterprise as well.

Overlay is too broad a term, all the above VPNs, and more, e.g. OTV for
DCI, and LISP too, can all be considered as overlay technologies.

I think what we are looking here is what would be the most suited
technologies for intra-DC and inter-DC connections, may use existing
technologies in some cases, may create new ones if necessary, or
combinations.

I don't see how you can distinguish VPN from Overlay.

Luyuan

From: AshwoodsmithPeter [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2012 5:08 PM
To: Luyuan Fang (lufang)
Subject: RE: [nvo3] When is an overlay not a VPN?

Luyuan,  the question was how are IETF VPNs and overlays 'different' ..
not how are they the same ;)

Cheers,

Peter

From: Luyuan Fang (lufang) [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2012 4:57 PM
To: AshwoodsmithPeter
Cc: John E Drake; [email-masked]; [email-masked]
Subject: RE: [nvo3] When is an overlay not a VPN?

Peter,

Luyuan

Peter Ashwood-Smith

Peter,

Thanks,

John

Sent from my iPhone

Hey John,

Peter

Peter,

Thanks,

John  

Sent from my iPhone

 

Adrian,

Ok, veeeeery broadly....

Peter

-----Original Message-----

Hi,

difference?

Thanks,

Adrian

nvo3 mailing list

[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Apr 2012 23:06:26 +0100

> use MPLS for creating tunnels ?
In this context, yes, IFF the DC operator community considers MPLS an
acceptable technology. The current indications are that they do not
consider it an acceptable technology. It is their network and thus
their call.

Stewart

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 11 Apr 2012 17:35:27 -0700

Hi Adrian,

Having read through this very interesting thread, I had to go back to the charter.

> stumbled on the distinction between "overlay" and "VPN".

Overlay, as Luyuan pointed out, is a very general term.

The charter says:

Para 1: Support for multi-tenancy has become a core requirement of data centers ... A key multi-tenancy requirement is traffic [and address] isolation ...

Para 2: This WG will develop an approach to multi-tenancy that does not rely on any underlying L2 isolation mechanisms to support multi-tenancy. ...

Para 3: NVO3 will document the problem statement, the applicability, and an architectural framework for overlay networks within a data center environment. ...

The first two paras develop the theme of multi-tenancy and isolation; the third throws up the term "overlay network" with no context or definition.  Somewhat jarring, no?

> Would someone like to risk two sentences of definition that allows me to see the

If you rephrase as: "... difference between 'multi-tenancy with address/traffic isolation' and VPN", I'd say, "None, unequivocally."

There were some creative attempts to read into "overlay network" the notion of independence from the underlay network. I don't buy it: the OBP, wherever it lives, is part of the underlay network.  I don't buy the artificial distinction between IP and MPLS either: whether the OBP speaks OSPF, ISIS or LDP to the rest of the underlay network, the main thing is, the OBP is a part of the underlay network's routing; if it isn't, its packets are going nowhere.

I'd really appreciate the IESG and IAB re-re-reviewing the third para in light of my comment, and tweaking it to be less jarring.

Thanks,
Kireeti

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Apr 2012 02:31:13 +0000

Agree with Luyuan’s points. The most important thing for us to pay attention is the intention of this BoF.  Since its real intention is to find or even invent in the future a VPN technology suitable for data center networks in which the VPN boundary could be terminated either at networks or at hosts,  to save our energy and focus it on the real problems, how about just use a more concrete and familiar term such as “Data Center VPN”, or “DCVPN” in short , rather than the term “overlay network” that may cause confusions.

Best regards,
Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Luyuan Fang (lufang)
发送时间: 2012年4月12日 5:38
收件人: AshwoodsmithPeter
抄送: John E Drake; [email-masked]; [email-masked]
主题: Re: [nvo3] When is an overlay not a VPN?

Peter,

VPN is one kind (actually many types of VPNs here) of Overlay with certain level of security.

There are different types of IETF VPNs, e.g. IPSec VPN, L3VPN, L2VPN…   VPNs are generally overlay technology using some sort of tunnels.

The difference we are often looking is where the terminating points of the VPNs, for what purpose using the VPN (encryption or route isolation?), who operates it…
IPSec is mostly for end users, can be SP managed service as well.
L3VPN and L2VPN started as and still largely is SP provisioned, later extended to enterprise as well.

Overlay is too broad a term, all the above VPNs, and more, e.g. OTV for DCI, and LISP too, can all be considered as overlay technologies.

I think what we are looking here is what would be the most suited technologies for intra-DC and inter-DC connections, may use existing technologies in some cases, may create new ones if necessary, or combinations.
I don’t see how you can distinguish VPN from Overlay.

Luyuan

Luyuan,  the question was how are IETF VPNs and overlays ‘different’ .. not how are they the same ;)

Cheers,

Peter

Peter,

Luyuan

Hey John, thanks but I do understand label stacks and that the labels managed by P routers are not per VPN and that ‘normally’ they exist as a pre-requisit to all VPNs. Of course if you chose not to run over LDP but put the service labels over IP, then things start to look pretty similar between an overlay and the existing IETF VPN technolgies.

Since Adrian was looking for the ‘difference’ this is why I highlighted ‘some’ involvement by the underlay ;) .. otherwise I’ve got nothing that can be used in a couple  sentence elevator pitch ;)

Peter Ashwood-Smith

Peter,

The VPN labels for a given VPN are distributed only to the PEs in that VPN, and any intervening RRs.    if you are using MPLS/LDP, the only labels that are being distributed are those for each PE’s loopback address, which are probably also being used for normal IP forwarding.  If you don’t want to use MPLS,  you can use non-MPLS tunnels between the PEs, so that MPLS is used strictly between the PEs to mux/demux packets.

Thanks,

John

Sent from my iPhone

Hey John,

Yeah but the P’s have to get involved for ALL the VPN’s via LDP ;) .. which was what I was getting at with ‘some’. That’s definitely not a property of ‘no’

Peter

Peter,

I don’t think that is correct.  In existing L2/L3 VPN technologies, the VPN awareness is restricted to the PEs.  In NV03, the VPN awareness is restricted to the NV03 edge nodes (aka PEs).

Thanks,

John

Sent from my iPhone

Adrian,

Ok, veeeeery broadly....

・         The term 'VPN', as used in the IETF requires 'some' involvement by the underlying IP network.

・         The term 'Overlay', as used in this context requires 'no' involvement by the underlying IP network.

Of course the degree of 'some' v.s. 'no' is open for debate but that’s probably the simplest high level view of the terminology difference + baggage I can think of.

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, April 11, 2012 11:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] When is an overlay not a VPN?

Hi,

Thanks,
Adrian

---

From: Jon Hudson <[email-masked]>
Date: Wed, 11 Apr 2012 19:50:28 -0700

That was much fun to read all at once. 

VPNs, Overlays, Tunnels all have different meanings depending on where you come from.

For me (as a rather irrelevant example, but an example of another view)

VPN are encrypted things you are not allowed to see into or enter.

Tunnels are things that you have to go inside to see into and are welcome to enter at an appropriate location.

Overlays sit on top of things and are open to "people watching" from outside the virtual network.

All provide intend to hide the complexity underneath.

So from inside they all look the same, from outside they each intend to look different.

</irrelevant example>

The use case I most often see given by customers for what I think this charter hopes to provide is a virtual network that runs on top of other networks but looks like it doesn't. Either for VM mobility or for Multi-tenancy. Just a VM is not suppose to be able to tell its a VM. 

There is no indication of privacy for those inside the virtual network.

There is no indication or assurance of security in the virtual network.

So I think VPN implies powers that may not be there.

And Tunnel implies point->point and implies some level of privacy (vs security)

Overlay people from many different levels seem to like. It implies a multipoint lattice or fabric that is "overlay'd" onto of an existing network.

However I agree it is not very specific and allows for the most interpretations. 

Personally I like "Network Wormhole" or "Folded Network Space" myself....or perhaps the "aether"...

But I would have to say that for anyone that _doesn't_ know MPLS (hard to fathom I know, but my cousin saw one once) VPN suggests security and privacy of which this offers neither natively. It is not (only) point->point and offers no privacy. 

And so Overlay makes the most sense...unless of course enough of you like Network Wormhole or Folded Network Space.

But ones view partially depends on if you are trying to associate it with an existing technology or trying to make it seem like something totally new.

In the end it's just a virtual network.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Apr 2012 09:43:32 +0100

> In the end it's just a virtual network.

This I think hits the nail on the head.

"VPN" carries a bunch of feature and technology
baggage.

We do not know until we write the requirements
draft what features we want, and it is important
that we don't encode in the language of the charter
a foothold or a barrier for any particular technology.

However we do know that we want the properties
of some type of virtual network.

Can we perhaps adopt the tern VN to move forward
and then replace the term later if we come up with
a better one?

Stewart

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 12 Apr 2012 10:04:36 +0000

http://irtf.org/concluded/vnrg

It seems that VN is still a term with broad semantics.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Stewart Bryant
> 发送时间: 2012年4月12日 16:44
> 收件人: Jon Hudson
> 抄送: [email-masked]; <[email-masked]>; Kireeti Kompella

---

From: John E Drake <[email-masked]>
Date: Thu, 12 Apr 2012 04:14:53 -0700

Stewart,

Would you please point me to the poll that lead you to the conclusion that the DC operator community does not consider MPLS an acceptable technology?  All I can recall seeing is some NV03 drafts and BoF presentations that asserted this.

Thanks,

John

Sent from my iPhone

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2012 3:06 PM
> To: Yakov Rekhter
> Cc: AshwoodsmithPeter; John E Drake; [email-masked]; [email-masked]
> >> manag= ed by P routers are not per VPN and that 'normally' they
> exist
> >> as a pre-req= uisit to all VPNs. Of course if you chose not to run
> >> over LDP but put the service labels over IP, then things start to
> >> look pretty similar between an = overlay and the existing IETF VPN
> technolgies.
> > Note that an overlay does use tunnels. With this in mind, can an
> > overlay use MPLS for creating tunnels ?
> >
> > Yakov.
> >

---

From: John E Drake <[email-masked]>
Date: Thu, 12 Apr 2012 04:37:26 -0700

Stewart,

I prefer Xiaohu's suggestion of 'Data Center VPN'.  It has the advantage of accurately describing the topic of this conversation.

Thanks,

John

Sent from my iPhone

> Sent: Thursday, April 12, 2012 1:44 AM
> To: Jon Hudson
> Cc: [email-masked]; <[email-masked]>; Kireeti Kompella
> "VPN" carries a bunch of feature and technology baggage.
> 
> We do not know until we write the requirements draft what features we
> want, and it is important that we don't encode in the language of the
> charter a foothold or a barrier for any particular technology.
> 
> However we do know that we want the properties of some type of virtual
> network.
> 
> Can we perhaps adopt the tern VN to move forward and then replace the
> term later if we come up with a better one?
> 
> Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Apr 2012 13:49:22 +0100

John

Certainly adoption of MPLS in existing DCs seems to be rather limited.

Perhaps you could take an action to run such a poll during the
requirements phase?

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Cristiano Monteiro <[email-masked]>
Date: Thu, 12 Apr 2012 10:07:08 -0300

Hi,

In my opinion no difference at all. However I think we need to focus in the
kind of problem we´re trying to solve here. In my opinion we should study
if the current LxVPN technology are suitable for DC. I think the big
difference here is who´s the VPN starter. In this way I also agree
completely with Xuxiaohu we should focus on DCVPN instead of overlay
networks to avoid confusion.

Best Regards,

Cristiano

Best

2012/4/11 Adrian Farrel <[email-masked]>

---

From: John E Drake <[email-masked]>
Date: Thu, 12 Apr 2012 06:08:59 -0700

Stewart

Comments inline.

Thanks,

John

Sent from my iPhone

> Sent: Thursday, April 12, 2012 5:49 AM
> To: [email-masked]

[JD]  Below you are explicitly agreeing that no one knows whether the DC operator community considers MPLS an acceptable technology, while above you are once again asserting that it does not.  As I mentioned yesterday, most of the folks that make this assertion are not part of the DC operator community, but claim to be speaking on its behalf.

And just to be clear, existing L2/L3 VPN technologies do not require MPLS as an tunneling technology, so the real questions to be asked are whether the DC operator community considers existing L2/L3 VPN technology to be acceptable, and if not, why not?  

> > Would you please point me to the poll that lead you to the conclusion
> that the DC operator community does not consider MPLS an acceptable
> technology?  All I can recall seeing is some NV03 drafts and BoF
> presentations that asserted this.
> >
> > Thanks,
> >
> > John
> >
> > Sent from my iPhone
> >
> >

---

From: John E Drake <[email-masked]>
Date: Thu, 12 Apr 2012 06:10:29 -0700

Excellent

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cristiano Monteiro
Sent: Thursday, April 12, 2012 6:07 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Hi,

In my opinion no difference at all. However I think we need to focus in the kind of problem we´re trying to solve here. In my opinion we should study if the current LxVPN technology are suitable for DC. I think the big difference here is who´s the VPN starter. In this way I also agree completely with Xuxiaohu we should focus on DCVPN instead of overlay networks to avoid confusion.

Best Regards,

Cristiano

Best
2012/4/11 Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Hi,

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Apr 2012 14:21:52 +0100

I certainly see "VN" as having less baggage than "overlay" (which the transport
world has as a very clear concept) and "VPN" which *some* people think forces us
to adopt one technology or another.

So I would see changing the wording in the draft charter to use "virtual network
(VN)" as a good step forward.

At the same time, however...

1. The term should not simply be used without explanation. The charter is used
to proscribe the work of the working group and it is not helpful to introduce a
term and hope that everyone will think the same thing when they see the term. I
suggest that this merits a two or three line paragraph to explain the term.

2. There seems to be a fair amount in the draft charter about what I would
consider "network privacy".  For example: 

|  A key multi-tenancy requirement
| is traffic isolation, so that a tenant's traffic (and internal address
| usage) is not visible to any other tenant and does not collide with
| addresses used within the data center itself.

If a network is virtual and the network requires privacy, is it not a virtual
private network?
Maybe a new term "Private Virtual Network (PVN)"?

Adrian

> Sent: 12 April 2012 09:44
> To: Jon Hudson
> Cc: <[email-masked]>; [email-masked]; Kireeti Kompella

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 12 Apr 2012 09:07:10 -0500

> Maybe a new term "Private Virtual Network (PVN)"?

Now our turn to ask you. :-)
- What is the difference between "VPN" and "PVN"?

Luyuan

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Adrian Farrel
> Sent: Thursday, April 12, 2012 9:22 AM
> To: Stewart Bryant (stbryant); 'Jon Hudson'
> Cc: [email-masked]; 'Kireeti Kompella'
> term and hope that everyone will think the same thing when they see
the
> term. I

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Apr 2012 15:14:54 +0100

Luyuan,

I can refer you to RFC 5513, or I can say "that is exactly my point, thank you
for making it so clearly"

> Sent: 12 April 2012 15:07
> To: [email-masked]; Stewart Bryant (stbryant); Jon Hudson
> Cc: [email-masked]; Kireeti Kompella

---

From: Thomas Narten <[email-masked]>
Date: Thu, 12 Apr 2012 10:19:19 -0400

Hi Randy.

> need to be mentioned, and traffic/bandwidth sharing issues need to be

Fair enough.

The charter used the wording:

    A key multi-tenancy requirement is traffic isolation, so that a
    tenant's traffic (and internal address usage) is not visible to
    any other tenant and does not collide with addresses used within
    the data center itself.

If there is link sharing (on the underlying transport network), there
needs to be a mechanism for preventing traffic from one tenant from
being visible to another. Encryption is one way (and presumably has
the highest level of assurance).

But using a VLAN also does the same, presumably with less assurance.

NVO3, using an IP encapsulation that has an embedded VN identifer (but
no other encryption mechanism) might be a little worse the VLANs. Or
not.

Definitely stuff to document and be clear about.

Also, it will be very hard in practice to ensure that traffic from
Tenant 1 can have *no* perceptible impact on Tenant 2. Especialy if
any tenant is allowed to use all available *unused* bandwidth. We
should document/discuss that as well.

Thomas

---

From: John E Drake <[email-masked]>
Date: Thu, 12 Apr 2012 07:21:22 -0700

DC VPN?

Sent from my iPhone

> Sent: Thursday, April 12, 2012 7:15 AM
> To: 'Luyuan Fang (lufang)'; 'Stewart Bryant (stbryant)'; 'Jon Hudson'
> I can refer you to RFC 5513, or I can say "that is exactly my point,
> thank you for making it so clearly"
> 
> > > If a network is virtual and the network requires privacy, is it not
> > > a virtual private network?
> > > I certainly see "VN" as having less baggage than "overlay" (which
> > > the transport world has as a very clear concept) and "VPN" which
> > > *some* people think forces us to adopt one technology or another.
> > >
> > > So I would see changing the wording in the draft charter to use
> > > "virtual network (VN)" as a good step forward.
> > >
> > > 1. The term should not simply be used without explanation. The
> > > charter is used to proscribe the work of the working group and it
> is
> > > not helpful to introduce a term and hope that everyone will think
> > > the same thing when they see
> > the
> > > term. I
> > > 2. There seems to be a fair amount in the draft charter about what
> I
> > > would consider "network privacy".  For example:
> > >
> > > | usage) is not visible to any other tenant and does not collide
> > > | with addresses used within the data center itself.
> > >
> > > If a network is virtual and the network requires privacy, is it not
> > > a virtual private network?
> > > > We do not know until we write the requirements draft what
> features
> > > > we want, and it is important that we don't encode in the language
> > > > of the charter a foothold or a barrier for any particular
> > > > technology.
> > > >
> > > > However we do know that we want the properties of some type of
> > > > virtual network.
> > > >
> > > > Can we perhaps adopt the tern VN to move forward and then replace
> > > > the term later if we come up with a better one?
> > > >
> > > > Stewart
> > >

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 12 Apr 2012 07:33:07 -0700

Hi Adrian,

> Maybe a new term "Private Virtual Network (PVN)"?

That (with a definition that captures multi-tenancy and isolation/privacy) would address my comment.

Kireeti

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 12 Apr 2012 09:35:27 -0500

> VPN are encrypted things you are not allowed to see into or enter.

Not true. 

IPsec VPN comes with encryption. 
Other VPNs may only provide isolation, e.g. L3VPN provides routing
isolation by using VRF, but no encryption.

Luyuan

Of
> Jon Hudson
> Sent: Wednesday, April 11, 2012 10:50 PM
> To: <[email-masked]>
> Cc: [email-masked]; Kireeti Kompella
> Tunnels are things that you have to go inside to see into and are
> welcome to enter at an appropriate location.
> 
> So from inside they all look the same, from outside they each intend
to
> look different.
> 
> </irrelevant example>
> 
> The use case I most often see given by customers for what I think this
> charter hopes to provide is a virtual network that runs on top of
other
> networks but looks like it doesn't. Either for VM mobility or for
> Multi-tenancy. Just a VM is not suppose to be able to tell its a VM.
> 
> Overlay people from many different levels seem to like. It implies a
> multipoint lattice or fabric that is "overlay'd" onto of an existing
> network.
> 
> But I would have to say that for anyone that _doesn't_ know MPLS (hard
> to fathom I know, but my cousin saw one once) VPN suggests security
and
> privacy of which this offers neither natively. It is not (only) point-
> >point and offers no privacy.
> 
> And so Overlay makes the most sense...unless of course enough of you
> like Network Wormhole or Folded Network Space.
> 
> But ones view partially depends on if you are trying to associate it
> with an existing technology or trying to make it seem like something
> totally new.
> 
> > Having read through this very interesting thread, I had to go back
to
> the charter.
> week and I
> > Para 1: Support for multi-tenancy has become a core requirement of
> data centers ... A key multi-tenancy requirement is traffic [and
> address] isolation ...
> >
> > Para 2: This WG will develop an approach to multi-tenancy that does
> not rely on any underlying L2 isolation mechanisms to support multi-
> tenancy. ...
> >
> > Para 3: NVO3 will document the problem statement, the applicability,
> and an architectural framework for overlay networks within a data
> center environment. ...
> >
> > The first two paras develop the theme of multi-tenancy and
isolation;
> the third throws up the term "overlay network" with no context or
> definition.  Somewhat jarring, no?
> >
> me to see the
> > If you rephrase as: "... difference between 'multi-tenancy with
> address/traffic isolation' and VPN", I'd say, "None, unequivocally."
> >
> > There were some creative attempts to read into "overlay network" the
> notion of independence from the underlay network. I don't buy it: the
> OBP, wherever it lives, is part of the underlay network.  I don't buy
> the artificial distinction between IP and MPLS either: whether the OBP
> speaks OSPF, ISIS or LDP to the rest of the underlay network, the main
> thing is, the OBP is a part of the underlay network's routing; if it
> isn't, its packets are going nowhere.
> >
> > I'd really appreciate the IESG and IAB re-re-reviewing the third
para
> in light of my comment, and tweaking it to be less jarring.
> >
> > Thanks,
> > Kireeti
> >
> >> Thanks,
> >> Adrian
> >>

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 12 Apr 2012 10:59:56 -0400

> isolation by using VRF, but no encryption.

L3VPNs are frequently sold as being a secure means of isolating your
private network from eavesdropping and unwanted entry in transit,
encryption or no.

Regard
Marshall

---

From: Roland Bless <[email-masked]>
Date: Thu, 12 Apr 2012 18:13:51 +0200

Hi,

> Would someone like to risk two sentences of definition that allows me to see the

An overlay has _usually_ its own topology, "independent" from the
underlaying network, uses its own addressing and routing scheme.
There are some overlays that are actually not VPNs, e.g.,
if you consider a DiffServ domain: it has partitioned
a single physical network into different logical networks
with separate resources. In this case, we even have the
same topology, same addressing, and same routing.
Depending on the level of isolation, the "P" in VPN sometimes
requires encryption and integrity protection.

Regards,
 Roland

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 12 Apr 2012 12:36:21 -0400

On Thu, Apr 12, 2012 at 12:13 PM, Roland Bless <[email-masked]> wrote:
> with separate resources.

And basically no protection from snooping. Again, I think the
"private" is the key distinguisher.

Regards
Marshall

> In this case, we even have the

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Apr 2012 23:35:04 +0200

John,

I don't think this is a matter of poll.

MPLS can be used as demux label (VPN label) I think just fine. It really 
does not matter if we demux based on tenant id or mpls label.

However for creating a tunnel MPLS requires signalling. If tunnel starts 
and terminates on the hosts that means that hosts must be part of the 
signalling. I am yet to see working LDP implementation for the host.

Of course there is one alternative to push programming of encap from 
controller which could run some form of tunnel setup control plane to 
each host. But I think it is not very clear in the current conversation 
if NVO3 would assume clear data and control plane separation model or not.

Also another problem is that current MPLS spec and implementation 
require exact FEC match. That bring all the scaling issues with large 
number of host routes or worse building seamless mpls hierarchy on top 
in order to support transport tunnel between any two encapsulation 
points. IP transport just scales much better as it works across natural 
IP address summarization.

Regards,
R.

---

From: Roland Bless <[email-masked]>
Date: Fri, 13 Apr 2012 01:13:01 +0200

Hi,

On 12.04.2012 18:36, Marshall Eubanks wrote:
> On Thu, Apr 12, 2012 at 12:13 PM, Roland Bless<[email-masked]>  wrote:

> "private" is the key distinguisher.

Additionally, The IP network itself is also an overlay (above various L2 
networks) and it's not a VPN.

Regards,
  Roland

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Apr 2012 01:30:07 +0000

I also agree that the major concern about using MPLS in data centers is deploying MPLS LSP tunnels, rather than using MPLS label for identifying VPN or VN instances. Besides the reasons Robert has mentioned below, there are additional reasons that DC operators hesitate to deploy MPLS LSP tunnels within data centers:  As for LDP LSP, it doesn't bring significant benefits compared to IP-based tunnels (e.g., GRE tunnel); As for TE LSP, it seems much more complex and more importantly doesn't scale very well.

Best regards,
Xiaohu 

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Robert
> Raszuk
> 发送时间: 2012年4月13日 5:35
> 收件人: John E Drake
> 抄送: AshwoodsmithPeter; Yakov Rekhter; [email-masked];
> [email-masked]; [email-masked]
> > Would you please point me to the poll that lead you to the conclusion that the
> DC operator community does not consider MPLS an acceptable technology?
> All I can recall seeing is some NV03 drafts and BoF presentations that asserted
> this.
> >
> > Thanks,
> > John
> 
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Apr 2012 01:50:41 +0000

> Marshall Eubanks
> 发送时间: 2012年4月12日 23:00
> 收件人: Luyuan Fang (lufang)
> 抄送: [email-masked]; [email-masked]; Kireeti Kompella; Jon Hudson

Exactly. IMHO, that's one of the major advantages of using MPLS label in data packets over using global VN identifier in data packets.

Best regards,
Xiaohu

---

From: Ross Callon <[email-masked]>
Date: Thu, 12 Apr 2012 22:01:54 -0400

> As for LDP LSP, it doesn't bring significant benefits compared to IP-based tunnels (e.g., GRE tunnel);

If the routers are involved in tunneling, then one huge advantage of using MPLS tunnels, as compared to other forms of tunnels, is that a very wide range of deployed routers can support MPLS encapsulation and decapsulation at line rate in the normal data plane. 

A corresponding problem with datagram tunneling techniques is quite simply that there are too many options (IPv4-in-IPv4, GRE, L2TP, LISP, ...). Any one of these would have been straightforward to implement in hardware in the data plane, if only there weren't so many of them. 

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, April 12, 2012 9:30 PM
To: [email-masked]; John E Drake
Cc: [email-masked]; Yakov Rekhter; [email-masked]; [email-masked]; AshwoodsmithPeter
Subject: Re: [nvo3] When is an overlay not a VPN?

Best regards,
Xiaohu

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Apr 2012 04:18:19 +0200

Hi Ross,

> very wide range of deployed routers can support MPLS encapsulation
> and decapsulation at line rate in the normal data plane.

Let's observe that very wide range of deployed routers can support IP
encapsulation and decapsulation at line rate in normal data plane too.

It was 15 years ago where routers and switches were not able to perform
IP based line rate tunneling.

However your line of analysis leads to very basic analogy that since
hosts are in scope as encap/decap points non of them can provide MPLS
encapsulation and decapsulation at _any_ rate today. That sounds like a
bit of a showstopper to build DC overlay transport using MPLS as the
choice of tunneling encapsulation.

Best regards,
R.

> If the routers are involved in tunneling, then one huge advantage of
> using MPLS tunnels, as compared to other forms of tunnels, is that a
> very wide range of deployed routers can support MPLS encapsulation
> and decapsulation at line rate in the normal data plane.
> 
> A corresponding problem with datagram tunneling techniques is quite
> simply that there are too many options (IPv4-in-IPv4, GRE, L2TP,
> LISP, ...). Any one of these would have been straightforward to
> implement in hardware in the data plane, if only there weren't so
> many of them.
> 
> Ross
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Xuxiaohu Sent: Thursday,
> April 12, 2012 9:30 PM To: [email-masked]; John E Drake Cc:
> [email-masked]; Yakov Rekhter; [email-masked];
> [email-masked]; AshwoodsmithPeter Subject: Re: [nvo3] When is an
> overlay not a VPN?
> 
> I also agree that the major concern about using MPLS in data centers
> is deploying MPLS LSP tunnels, rather than using MPLS label for
> identifying VPN or VN instances. Besides the reasons Robert has
> mentioned below, there are additional reasons that DC operators
> hesitate to deploy MPLS LSP tunnels within data centers:  As for LDP
> LSP, it doesn't bring significant benefits compared to IP-based
> tunnels (e.g., GRE tunnel); As for TE LSP, it seems much more complex
> and more importantly doesn't scale very well.
> 
> Best regards, Xiaohu
> 
>> -----邮件原件----- 发件人: [email-masked]
>> [mailto:[email-masked]] 代表 Robert Raszuk 发送时间: 2012年4月13日
>> 5:35 收件人: John E Drake 抄送: AshwoodsmithPeter; Yakov Rekhter;
>> [email-masked]; [email-masked]; [email-masked] 主题: Re:
>> [nvo3] When is an overlay not a VPN?
>> 
>> John,
>> 
>> MPLS can be used as demux label (VPN label) I think just fine. It
>> really does not matter if we demux based on tenant id or mpls
>> label.
>> 
>> However for creating a tunnel MPLS requires signalling. If tunnel
>> starts and terminates on the hosts that means that hosts must be
>> part of the signalling. I am yet to see working LDP implementation
>> for the host.
>> 
>> Of course there is one alternative to push programming of encap
>> from controller which could run some form of tunnel setup control
>> plane to each host. But I think it is not very clear in the current
>> conversation if NVO3 would assume clear data and control plane
>> separation model or not.
>> 
>> require exact FEC match. That bring all the scaling issues with
>> large number of host routes or worse building seamless mpls
>> hierarchy on top in order to support transport tunnel between any
>> two encapsulation points. IP transport just scales much better as
>> it works across natural IP address summarization.
>> 
>> Regards, R.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Apr 2012 20:38:00 -0700

> A corresponding problem with datagram tunneling techniques is quite simply that there are too many options (IPv4-in-IPv4, GRE, L2TP, LISP, ...). Any one of these would have been straightforward to…

Ross, LISP is more than just an encapsulation format. But when we designed it 5 years ago, we initially chose GRE and were told we couldn't get good load-splitting across LAGs in the core. Hence we went with a UDP encapsulation for obvious reasons.

Dino

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Apr 2012 03:57:17 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Dino
> Farinacci
> 发送时间: 2012年4月13日 11:38
> 收件人: Ross Callon
> 抄送: John E Drake; Xuxiaohu; [email-masked]; [email-masked]
> > A corresponding problem with datagram tunneling techniques is quite simply
> that there are too many options (IPv4-in-IPv4, GRE, L2TP, LISP, ...). Any one of
> these would have been straightforward to implement in hardware in the data
> plane, if only there weren't so many of them.
> 
> Ross, LISP is more than just an encapsulation format. But when we designed it
> 5 years ago, we initially chose GRE and were told we couldn't get good
> load-splitting across LAGs in the core. Hence we went with a UDP
> encapsulation for obvious reasons.

Hi Dino,

What about the flow label that can be carried in the key field of the GRE header?

Best regards,
Xiaohu

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Apr 2012 21:05:22 -0700

> What about the flow label that can be carried in the key field of the GRE header?

Most core routers in the Internet will 5-tuple hash for UDP and TCP packets. IPsec, GRE, and other IP protocol number based encapsulations just use (source, destination) hashing which means all traffic from one encapsulator goes on one member link of the LAG.

Dino

---

From: Shane Amante <[email-masked]>
Date: Thu, 12 Apr 2012 22:08:02 -0600

On Apr 12, 2012, at 7:30 PM, Xuxiaohu wrote:
> I also agree that the major concern about using MPLS in data centers is deploying MPLS LSP tunnels, rather than using MPLS label for identifying VPN or VN instances. Besides the reasons Robert has mentioned below, there are additional reasons that DC operators hesitate to deploy MPLS LSP tunnels within data centers:  As for LDP LSP, it doesn't bring significant benefits compared to IP-based tunnels (e.g., GRE tunnel);

Assuming we're talking about native MPLS switching in the dataplane and *not* MPLS/(GRE|L2TPv3)/IP ...

I think a "flaw" in a variety of MPLS implementations, and perhaps a root cause of the issue of "why not MPLS"?, is the requirement to enable MPLS encapsulation on each interface that will perform MPLS encaps/decaps/switching.  Although this is a single CLI command on /each/ physical interface ... when talking about a [single] DC and depending on *where* exactly in the DC topology MPLS forwarding is required it's likely on the order of thousands (or, more) potential physical interfaces that would need this.  Of course, MPLS SW implementations could think about enabling MPLS encapsulation on physical interfaces, by default, and this problem goes away.  Alternatively, many equipment vendors do support "interface range" CLI commands and/or simple automation in their CLI's that could support mass configuration of a new encapsulation across a slew of physical interfaces in one or two keystrokes -- however, I haven't explored this capability, wrt the MPLS encaps piece, in-depth.  Lastly, there's always automation (homegrown or COTS) that could do this too.

Assuming one would get past that hurdle, what's next?  My answer: not much.
1)  Clearly, the DC operator has already enabled an IGP, (OSPF|IS-IS), since that's a key assumption/requirement the discussions around NVO3 have stated, thus far.  MPLS switching requires an IGP so this "step" is no additional work.
2)  Now, to take advantage of that MPLS switching capability all the operator needs to do next is turn on LDP.  How hard is this?  Not to pick on anybody in particular, but in JUNOS this is literally 2 CLI commands:
---snip---
set protocols mpls interface all
set protocols ldp interface all
---snip---
... that's it.  Done.

So, what possibilities does that open up?  Well, once that's done I instantly gain the capability to, if I want, either:
a)  Transport PWE3 VC's across this network; and/or,
b)  Enable VPLS-LDP across this network.
... both using Targeted LDP, of course ... IOW, I still haven't touched BGP, at all.  Of course, whether those are desired or required capabilities in the eyes of a DC operator is left as an exercise for the reader.  

> As for TE LSP, it seems much more complex and more importantly doesn't scale very well.

Perhaps in the overwhelming majority of cases, particularly in a DC, I would agree that TE LSP's are not needed.  However, the fact that one would have the /capability/ to use it (i.e.: break-glass-when-needed) is, I think, powerful.  

Lastly, with respect to the argument that "MPLS is new" or that "LDP is new" to a DC operator, thus they would need to go through training, I would say a few things:
a)  There exists a plethora of training materials, in many cases freely available, to learn MPLS & LDP now;
b)  Whatever solution(s) that NVO3 provides, particularly for the control plane, are also going to be new, thus it remains to be seen how much training is going to be required for NVO3 vs. MPLS, (whether it's more or less, who knows).

Arguably, and this is perhaps where the fundamental difference lies, is that wrt an "overlay solution" that does not require any changes to the network, the only 'training' that MAY need to be performed is to the Server Administrators ... assuming that NVO3 is deployed down into the Hypervisor and doesn't "touch" the ToR, (or if it does touch the ToR, they are administered by the Server Admins).  OTOH, if we're talking about native MPLS switching, there is dependency to train not only Server Admins, but also Network Admins, as well as some operational cooperation between the two groups during the life of the deployed solution.

In summary, I hope that I've dispelled the myth that "Native MPLS is hard".  Yes, it may be new to an organization, but to some extent so will NVO3.

And, just to be clear, if we switch the discussion back to: I still want IP in the forwarding plane, but could we just use MPLS as just a "demux label" on top of IP, e.g.: MPLS/(GRE|L2TPv3)/IP, then most (if not all) of what I just said above does not apply.  In that case, the focus of the discussion should likely center around what are the current and future encaps/decaps capabilities/limitations of the ASIC/NPU/Hypervisor responsible for pushing/popping a "application label" as per the reqmt's of NVO3.

-shane

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Apr 2012 21:11:16 -0700

Shane, people like overlays because nothing between the overlay endpoints have to change or get upgraded. That is much simpler than simply turning on MPLS/LDP.  ;-)

Dino

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Apr 2012 04:11:07 +0000

> 发送时间: 2012年4月13日 12:05
> 收件人: Xuxiaohu
> 抄送: Ross Callon; John E Drake; [email-masked]; [email-masked]
> Most core routers in the Internet will 5-tuple hash for UDP and TCP packets.
> IPsec, GRE, and other IP protocol number based encapsulations just use
> (source, destination) hashing which means all traffic from one encapsulator
> goes on one member link of the LAG.

To be compatible to those deployed core routers as mentioned above, how about allowing the egress PE router to advertise a tunnel endpoint address prefix of which any single address could be used as tunnel destination address by ingress PE routers?

Best regards,
Xiaohu

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Apr 2012 21:20:50 -0700

> To be compatible to those deployed core routers as mentioned above, how about allowing the egress PE router to advertise a tunnel endpoint address prefix of which any single address could be used a…

That is what a LISP ETR does when it registers its locators to the mapping database. Then an ITR, that encapsulates to it can choose any locator, of course, based on priority and weight, set by the destination site policy.

Dino

---

From: Shane Amante <[email-masked]>
Date: Thu, 12 Apr 2012 22:31:41 -0600

> Shane, people like overlays because nothing between the overlay endpoints have to change or get upgraded. That is much simpler than simply turning on MPLS/LDP.  ;-)

I would agree; however, TINSTAAFL.  Specifically, a key operational challenge with overlays is the folks who operate the 'underlying network', at key times, require the capability to look at and/or understand the traffic riding on top of the underlying network, i.e.: Netflow/IPFIX/sFlow.  Furthermore, the network folks need that capability if they are expected to avoid, (i.e.: steer certain traffic away from), congestion that appears from time to time in the underlying network.  In the latter case, having the ability to "steer" important (VPN) traffic into, say, RSVP-TE LSP's so it avoids congestion, perhaps at the expense of taking a sub-optimal path, while waiting for an augment to be put in place is, shall we say, helpful.  :-)  Admittedly, wiring up new connections inside a DataCenter should be substantially easier and more timely than, say, installing a new Inter-City Long-Haul WDM system ...  However, you have to admit that overlays w/out these capabilities will have a tendency to cause 'underlying network guys' pain.  Ultimately, this is why I expressed that it would be _nice_ if there is some way, in the future, for the NVO3 'overlay' (really, the Control Plane) to have "visibility" of the underlying network carrying its packets.  One very simple example is: what happens when there is loss of component-links in either a LAG or ECMP group that result in degraded BW of the underlying network?  The network guys are going to have a fire lit under them to restore capacity ASAP and/or alternatively they have to, try to, overbuild to attempt to avoid this from happening in the first place.

Ultimately, when you think about the very _simple_ capabilities that exist in BGP to perform path selection on MED's (i.e.: a 'neighbor' telling me the best-exit to reach them) and IGP metric (if all MED's are equal, what is my own topologically closest exit) ... those were developed for very obvious reasons.  I would hope that NVO3, eventually, considers similar capabilities to be more kind to the Network Admins of these DC's.

-shane

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Apr 2012 21:36:31 -0700

> I would agree; however, TINSTAAFL.  Specifically, a key operational challenge with overlays is the folks who operate the 'underlying network', at key times, require the capability to look at and/or…

An ITR can always encapsulate to an RTR (Reencapsulating Tunnel Router) which is in your network, so when you decap, you can use legacy equipment to process the inner header. And, arguably, you will get better cache management out of your ITR as well. And to boot, the RLOC-probing issues go down, because now the ITR doesn't have to RLOC-probe every ETR but can probe a smaller set of RTRs. Will scale better. And then you can steer traffic as well because your RTR can decide where to encap to next (another RTR in your network or your peer's network or directly to the ETR at the destination site).

Dino

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Apr 2012 06:39:52 +0200

<Adjusting the subject to reflect the topic>

Hi Shane,

> and *not* MPLS/(GRE|L2TPv3)/IP ...

Sure.

> I think a "flaw" in a variety of MPLS implementations, and perhaps a
> root cause of the issue of "why not MPLS"?, is the requirement to
> enable MPLS encapsulation on each interface that will perform MPLS
> encaps/decaps/switching.

Through all years helping various customers to deploy MPLS I have never
heard that configuration of LDP is an issue. It is least worry one has
when facing mpls.

> Assuming one would get past that hurdle, what's next?  My answer: not

And my answer as stated is that main problems is FEC exact match (you
just can't summarize and aggregate host routes at the area boundaries)
so your IGP grows to large number of prefixes. The current workaround I
proposed around 2002 to one customer trying to make each DSLAM as PE was
to put a new layer of BGP 3107 so those /32s would not be present in
core and all remote areas of the IGP.

Here we have few order of magnitude mode potential entities which will
act as encap/decap elements.

> 1)  Clearly, the DC operator has already enabled an IGP,
> (OSPF|IS-IS), since that's a key assumption/requirement the
> discussions around NVO3 have stated, thus far.  MPLS switching
> requires an IGP so this "step" is no additional work.

Wrong. Hosts do not run IGP. If you want to enable encap/decap in the
host you need both IGP (maybe even BGP so IGP will not melt) and LDP.

The alternative is OpenFlow configuration of host's OVS but it is just
shifting LDP to set of controllers.

> So, what possibilities does that open up?  Well, once that's done I
> instantly gain the capability to, if I want, either: a)  Transport
> PWE3 VC's across this network; 

IP can transport those just fine as well.

> and/or, b)  Enable VPLS-LDP across
> this network. ... 

Can run over IP transport as well.

> Arguably, and this is perhaps where the fundamental difference lies,
> is that wrt an "overlay solution" that does not require any changes
> to the network, the only 'training' that MAY need to be performed is
> to the Server Administrators ... assuming that NVO3 is deployed down
> into the Hypervisor and doesn't "touch" the ToR, (or if it does touch
> the ToR, they are administered by the Server Admins).  OTOH, if we're
> talking about native MPLS switching, there is dependency to train not
> only Server Admins, but also Network Admins, as well as some
> operational cooperation between the two groups during the life of the
> deployed solution.

Before you recommend running MPLS on the hypervisor can we answer the
scaling problems indicated above ?

Then we could analyze what LDP open source code you recommend to run on
hosts.

> In summary, I hope that I've dispelled the myth that "Native MPLS is
> hard". 

No it is not hard. It is just completely wrong tool in this environment.

Regards,
R.

---

From: Shane Amante <[email-masked]>
Date: Thu, 12 Apr 2012 22:47:35 -0600

> An ITR can always encapsulate to an RTR (Reencapsulating Tunnel Router) which is in your network, so when you decap, you can use legacy equipment to process the inner header. And, arguably, you wil…

Sure, that's possible; but, now you've just increased stretch and, more importantly, CapEx costs for traffic that now needs to traverse this RTR ...

-shane

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Apr 2012 07:00:01 +0200

Shane,

> Ultimately, when you think about the very_simple_  capabilities that
> exist in BGP to perform path selection on MED's (i.e.: a 'neighbor'
> telling me the best-exit to reach them) and IGP metric (if all MED's
> are equal, what is my own topologically closest exit) ... those were
> developed for very obvious reasons.  I would hope that NVO3,
> eventually, considers similar capabilities to be more kind to the
> Network Admins of these DC's.

Network awareness is a good thing. However I would argue that it is not
only required at transport of an overlay, but way before your
orchestration system would instantiate set of tenant VMs.

The network topology and network state which interconnects hosts may be
a critical factor on which such host VMs for a given user's requirements
are instantiated.

Then when interconnect comes in place one could think about NVO3 overlay
in sense of other very popular overlays (peer to peer set for each
tenant) with ALTO/NPS ability to deliver hint on the closest gateway,
FW, xTRs or set of load balancers.

Rgs,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Apr 2012 05:20:54 +0000

> -----邮件原件-----
> 发件人: Dino Farinacci [mailto:[email-masked]]
> 发送时间: 2012年4月13日 12:21
> 收件人: Xuxiaohu
> > To be compatible to those deployed core routers as mentioned above, how
> about allowing the egress PE router to advertise a tunnel endpoint address
> prefix of which any single address could be used as tunnel destination address
> by ingress PE routers?
> 
> That is what a LISP ETR does when it registers its locators to the mapping
> database. Then an ITR, that encapsulates to it can choose any locator, of
> course, based on priority and weight, set by the destination site policy.

In this way, the core routers (i.e., P routers) could distribute customer traffic flows between a given PE pair across multiple paths. In other words, MAC-in-MPLS-in-GRE/IP encapsulation can fill the load-balancing purpose as well. This may be useful for consideration when writing the NVo3 data-plane requirement draft.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Apr 2012 05:27:07 +0000

> -----邮件原件-----
> 发件人: Xuxiaohu
> 发送时间: 2012年4月13日 9:51
> 收件人: 'Marshall Eubanks'; Luyuan Fang (lufang)
> 主题: re: [nvo3] When is an overlay not a VPN?
> 
> > -----邮件原件-----
> Exactly. IMHO, that's one of the major advantages of using MPLS label in data
> packets over using global VN identifier in data packets.

By the way, I think this is also worthwhile for consideration when writing the NVo3 data plane requirement draft.

Xiaohu

---

From: Jon Hudson <[email-masked]>
Date: Thu, 12 Apr 2012 23:45:10 -0700

Actually for many Users there is a big difference.

Most Users hear of VPNs only in the context of "I have to use VPN to connect to work" Or "the VPN is down, fix it!"

Right or wrong, many many non MPLS folks think VPN implies encryption.

Private Virtual Network just implies a virtual network that requires an invitation. 

But we would have to make sure caps are use properly since most virtualization folks add a "p" to something to denote physical 
(i.e. pNIC->vNIC)

So pVN could make their head explode ;-)

I think;

Private Virtual Network - PVN
Overlay Virtual Network - OVN
Software Virtual Network - SVN

Or even Open Virtual Network to denote a standard approach to the technology. (OpenVN or OVN)

These would all make sense to many Users and aid in adoption.

Keep in mind that the first time most Users are introduction to tech like what NOV3 is discussing is with VxLAN, and understand it to be a Virtual LAN. 

While few like to admit it, there is a PR aspect to protocols, name recognition matters.

Actually...the more I think on it, Open Virtual Network might be a really good idea.

Many are starting to group VXLAN/NVGRE/STT & OpenFlow etc all as types of SDN. And Openstack and Openflow even get presented together _all the time_ just because they both start with "open" 

And OpenVN would help us ride the "Open" wave

---

From: Jon Hudson <[email-masked]>
Date: Thu, 12 Apr 2012 23:47:45 -0700

I'm not talking about people like us

I'm talking about the Datacenter Users (admins)

---

From: Jon Hudson <[email-masked]>
Date: Fri, 13 Apr 2012 00:02:47 -0700

Nice!

But I would add that I don't think its always complexity of implementations. 

It's a feature availability issue

To your lovely JUNOS example, can you do that on a 4200? Or even a qfx3500? Rarely do entry level or even high end TOR devices support MPLS

---

From: Rob Shakir <[email-masked]>
Date: Fri, 13 Apr 2012 11:30:40 +0100

On 12 Apr 2012, at 22:35, Robert Raszuk wrote:

> [..snip..]
> Also another problem is that current MPLS spec and implementation require exact FEC match. That bring all the scaling issues with large number of host routes or worse building seamless mpls hierarchy on top in order to support transport tunnel between any two encapsulation points. IP transport just scales much better as it works across natural IP address summarization.

Robert, All,

Whilst I appreciate the analysis here, one thing that I would say is that discussions around "what should we use for an encapsulation format" at this point, IMHO, are premature. The NVO3 charter that Stewart posted covers why this is the case well:

"Based on this framework, the WG will develop requirements for both
control plane protocol(s) and data plane encapsulation format(s), and
perform a gap analysis of existing candidate mechanisms. In addition to
functional and architectural requirements, NVO3 will develop operational,
maintenance, troubleshooting, and security requirements."

Until one is able to perform a gap analysis of /all/ solutions, against the requirements for the problem space that these efforts intend to solve, then I don't see how one can immediately write off any format. It seems to me like it'd be much better to focus our efforts into getting the requirements clearly defined, without the bias of "box X does not currently support feature Y", and then work from there.

Additionally, as with other comments on this list, I would like to see comments from people running such datacentre environments as to what their requirements are (and will aim to contribute the requirements of such solutions that are characteristic to those environments with which I am involved). As with many things, some of these decisions come down to what the specific operator's requirements are (in terms of existing environment into which services should be integrated, and operational expertise) - so I'm again not sure how we can write whole technologies off at this point.

I think that the charter Stewart posted yesterday is a great starting point for this effort, without writing any particular approach off, and appreciating that potentially, there will be different approaches to implementing any framework that is defined. I'd therefore support progressing this.

Kind regards,
r.

---

From: John E Drake <[email-masked]>
Date: Fri, 13 Apr 2012 04:41:23 -0700

Robert,

I agree with Rob Shakir that bashing solutions is premature and that there will be plenty of time for it later.  However, as you and I have both noted, non-MPLS tunnels (of which there are an almost infinite variety from which to choose) may be used to connect the PEs, so I am not sure that your analysis of LDP's shortcomings is germane.

Thanks,

John

Sent from my iPhone

> From: Robert Raszuk [mailto:[email-masked]]
> Sent: Thursday, April 12, 2012 2:35 PM
> To: John E Drake
> Cc: [email-masked]; Yakov Rekhter; [email-masked];
> [email-masked]; AshwoodsmithPeter
> really does not matter if we demux based on tenant id or mpls label.
> 
> starts and terminates on the hosts that means that hosts must be part
> of the signalling. I am yet to see working LDP implementation for the
> host.
>

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 13 Apr 2012 06:53:41 -0700

Hi Shane,

On Apr 12, 2012, at 21:08, Shane Amante <[email-masked]> wrote:

> I think a "flaw" in a variety of MPLS implementations, and perhaps a root cause of the issue of "why not MPLS"?, is the requirement to enable MPLS encapsulation on each interface that will perform MPLS encaps/decaps/switching.  

...

> Assuming one would get past that hurdle, what's next?  My answer: not much.

Thanks, Shane, for clearing the air on that!  What you said carries a whole lot more weight than anything that I (as "vendor scum") say would.

I would take your statement one step further, and say that what MPLS implementations *owe* the industry is to make MPLS progressively easier to use -- in the limit, "MPLS Plug'n'Play".  Which is not to say that the bells and whistles are not useful, but, to use your words, they should be a "break glass if needed" fallback.

Your other comment, learning MPLS vs. learning whatever new thing NVO3 comes up with is also right on.  One difference is, MPLS has ~15 years of deployment, interoperability and scaling experience.

Kireeti

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 13 Apr 2012 07:11:44 -0700

Hi Rob,

On Apr 13, 2012, at 3:30, Rob Shakir <[email-masked]> wrote:

> one thing that I would say is that discussions around "what should we use for an encapsulation format" at this point, IMHO, are premature

You're absolutely right.  However, the flavor of the discussions so far is, don't rule out MPLS (or BGP, or whatever) out of hand.

At least, that's been my approach, and that's how I read Shane's epistle.  _Some_ folks have been hammering away on why you should use xyz technology.

Kireeti

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Apr 2012 08:39:10 -0700

> Sure, that's possible; but, now you've just increased stretch and, more importantly, CapEx costs for traffic that now needs to traverse this RTR ...

You don't have to if it is on path. Plus the transit has more control. And that, many times, is important.

Dino

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Apr 2012 17:34:20 +0100

Hi Jon,

I am a great fan of the bank card "PIN number" phrase in common usage.

Reading your text below, I wondered if it is time for the "virtual VPN" or the
"private VPN" or maybe the "VPN network"

My take away from this thread is that we fail if we use any buzz phrase or
acronym. We must say what we mean and not hide behind terminology.

Actually, this is not a bad guideline for a charter in any case. 

Adrian

> From: Jon Hudson [mailto:[email-masked]]
> Sent: 13 April 2012 07:45
> To: Luyuan Fang (lufang)
> Cc: <[email-masked]>; Stewart Bryant (stbryant); <[email-masked]>; Kireeti
> Kompella
> Most Users hear of VPNs only in the context of "I have to use VPN to connect
to
> work" Or "the VPN is down, fix it!"
> 
> But we would have to make sure caps are use properly since most virtualization
> folks add a "p" to something to denote physical
> (i.e. pNIC->vNIC)
> 
> Keep in mind that the first time most Users are introduction to tech like what
> NOV3 is discussing is with VxLAN, and understand it to be a Virtual LAN.
> 
> While few like to admit it, there is a PR aspect to protocols, name
recognition
> matters.
> Many are starting to group VXLAN/NVGRE/STT & OpenFlow etc all as types of
> SDN. And Openstack and Openflow even get presented together _all the time_
> just because they both start with "open"
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 13 Apr 2012 19:04:20 +0000

That's definitely a huge non starter in a DC core unless those ASICs get respun to look deeper in the LAG hash.

That should probably be included in the charter. I.e. the encapsulation has to provide excellent entropy while being transparent, private.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Friday, April 13, 2012 12:05 AM
To: Xuxiaohu
Cc: Ross Callon; John E Drake; [email-masked]; [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Dino

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 13 Apr 2012 12:30:19 -0700

Hi Peter,

On Fri, Apr 13, 2012 at 12:04 PM, AshwoodsmithPeter <
[email-masked]> wrote:

> That should probably be included in the charter. I.e. the encapsulation
> has to provide excellent entropy while being transparent, private.
>

I won't go there now (though it's so hard not to!) ... but I think I can
help you with that.

(Sitting on my hands!)

Thanks for making my day, though!
Kireeti.

> Dino Farinacci
> Most core routers in the Internet will 5-tuple hash for UDP and TCP
> packets. IPsec, GRE, and other IP protocol number based encapsulations just
> use (source, destination) hashing which means all traffic from one
> encapsulator goes on one member link of the LAG.
>
> Dino
>

-- 
Kireeti

---

From: Ross Callon <[email-masked]>
Date: Fri, 13 Apr 2012 15:40:09 -0400

To me this is a requirement. However, it seems unlikely that we can list all technical requirements in the charter (as opposed to listing "produce requirements document" in the charter, and then listing the requirements in the requirements document). 

Ross

-----Original Message-----
From: AshwoodsmithPeter [mailto:[email-masked]] 
Sent: Friday, April 13, 2012 3:04 PM
To: Dino Farinacci; Xuxiaohu
Cc: Ross Callon; John E Drake; [email-masked]; [email-masked]
Subject: RE: [nvo3] When is an overlay not a VPN?

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Friday, April 13, 2012 12:05 AM
To: Xuxiaohu
Cc: Ross Callon; John E Drake; [email-masked]; [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Dino

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 13 Apr 2012 19:46:25 +0000

Kireeti, I'll take that as a 'yes it's a requirement', with the caveat that you really need to get out more if packet entropy makes your day ;)

Peter

________________________________
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Friday, April 13, 2012 3:30 PM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Hi Peter,

On Fri, Apr 13, 2012 at 12:04 PM, AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>> wrote:
That should probably be included in the charter. I.e. the encapsulation has to provide excellent entropy while being transparent, private.

I won't go there now (though it's so hard not to!) ... but I think I can help you with that.

(Sitting on my hands!)

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dino Farinacci
Sent: Friday, April 13, 2012 12:05 AM
To: Xuxiaohu
Cc: Ross Callon; John E Drake; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] When is an overlay not a VPN?

Dino

--
Kireeti

---

From: John E Drake <[email-masked]>
Date: Fri, 13 Apr 2012 13:17:19 -0700

I've been hearing about this thing called entropy label.

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Friday, April 13, 2012 12:30 PM
To: AshwoodsmithPeter
Cc: [email-masked]
Subject: Re: [nvo3] When is an overlay not a VPN?

Hi Peter,

(Sitting on my hands!)

Peter

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dino Farinacci
Sent: Friday, April 13, 2012 12:05 AM
To: Xuxiaohu
Cc: Ross Callon; John E Drake; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] When is an overlay not a VPN?

Dino

--
Kireeti

---

From: "Yves Hertoghs (yhertogh)" <[email-masked]>
Date: Fri, 13 Apr 2012 10:34:54 +0200

When reading this lovely thread, its my observation that most of the discussion stems from the fact that a lot of people have very strict ties between the control and dataplane in mind, as per the established work in IETF.  For example, IF we choose MPLS as the underlying network, THEN we MUST use BGP to do host to location mapping.

But i think the big value from NVO3 could come from taking a clean slate and take a fresh look at both the dataplane requirements as well as the control plane requirements for both the underlying network as well as the controlplane requirement for the  host to locaton mapping protocol. This latter controlplane could have rather particular requirements which might not have been solved with todays protocols and VPN solutions out there, and the controlplane chosen should be as independent as possible from the underlying network dataplane.

My .02 € 

Yves
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, April 13, 2012 07:00
To: Shane Amante
Cc: John E Drake; AshwoodsmithPeter; Yakov Rekhter; [email-masked]; [email-masked]; Xuxiaohu; Dino Farinacci (dino); Stewart Bryant (stbryant)
Subject: Re: [nvo3] When is an overlay not a VPN?

Shane,

> Network Admins of these DC's.

Network awareness is a good thing. However I would argue that it is not only required at transport of an overlay, but way before your orchestration system would instantiate set of tenant VMs.

The network topology and network state which interconnects hosts may be a critical factor on which such host VMs for a given user's requirements are instantiated.

Then when interconnect comes in place one could think about NVO3 overlay in sense of other very popular overlays (peer to peer set for each
tenant) with ALTO/NPS ability to deliver hint on the closest gateway, FW, xTRs or set of load balancers.

Rgs,
R.

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 13 Apr 2012 16:00:31 -0700

Why, entropy makes my day every Friday the 13th!

:)

Kireeti 

On Apr 13, 2012, at 12:46, AshwoodsmithPeter <[email-masked]> wrote:

> Kireeti, I’ll take that as a ‘yes it’s a requirement’, with the caveat that you really need to get out more if packet entropy makes your day ;)
>  
> Peter
>  
> On Fri, Apr 13, 2012 at 12:04 PM, AshwoodsmithPeter <[email-masked]> wrote:

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 16 Apr 2012 03:06:37 +0000

By the way, is MPLS-in-UDP is a valuable piece of work for the purpose of load-balancing?

Best regards,
Xiaohu

> Xuxiaohu
> 发送时间: 2012年4月13日 13:21
> 收件人: Dino Farinacci
> In this way, the core routers (i.e., P routers) could distribute customer traffic
> flows between a given PE pair across multiple paths. In other words,
> MAC-in-MPLS-in-GRE/IP encapsulation can fill the load-balancing purpose as
> well. This may be useful for consideration when writing the NVo3 data-plane
> requirement draft.
> 
> Best regards,
> Xiaohu
> 
> > Dino
> >
>

---

From: <[email-masked]>
Date: Mon, 16 Apr 2012 17:41:28 +0200

Hi Adrian,

Risking re-asserting what as already been said, and explained, by 
others, my answer is that there is no difference between the service 
provided by "NVO3 overlays" (providing L2 or L3 isolated network 
connectivity over an underlying network) and "VPNs" as used in the 
context of L2VPN and L3VPN. Even the techniques suggested (encapsulation 
+ some way of determining the remote tunnel endpoint) are totally 
similar. If you apply the L2VPN E-VPN specs with an MPLS/GRE 
encapsulation, it's obvious that you can meet the high level 
requirements outlined in the current proposed charter.

The real difference between "overlay" and "VPNs" lies in the belief that 
techniques implemented in routers to let network service provider deploy 
VPNs cannot be used. Your question was "When is an overlay not a VPN?" 
and I think the answer is that an "overlay" is not a "VPN" as soon as 
one assumes/concludes that the BGP/MPLS toolbox used there is not 
applicable to servers.

Without introducing any preconception on what the answer is, it is 
obvious that we would benefit from making it clear upfront, in the 
charter, that the goal is in fact the same ; not doing it and forging a 
new term is just rushing the process and assuming what are the 
conclusions of the initial charter milestones.

Using full sentences instead of acronyms (such as "VPNs") or nicknames 
(such as "overlays"), is I think the right way to avoid endless debates 
about names, categories and definitions.

-Thomas

P.S. : In contexts distinct from L2VPN/L3VPN, "VPN" is often used to 
designate encrypted tunnels to work/home/etc. This use of the term is 
clearly distinct from what NVO3 tries to achieve. Since NVO3 relates to 
servers, and an audience possibly more familiar to that use of the term, 
we /might/ want to avoid re-using it..., but this is not really the 
interesting part of the discussion