Subject: The possibility of using global MPLS labels as VNIs

From: Xuxiaohu <[email-masked]>
Date: Thu, 18 Jul 2013 09:54:43 +0000

Hi all,

Till now, it seem that the only remaining technical reason for some people to prefer VXLAN/NVGRE encapsulation format to MAC-in-MPLS-in-IP encapsulation format for network virtualization overlay is the former has global VNIs while the latter doesn't have. If this reason is true, why can't we consider the possibility of using global MPLS labels to achieve the same goal?

In fact, there are multiple possible ways to achieve global MPLS labels:

1) the first way is to allocate a label block from the existing label space and use it as a global label space from which VPN labels are assigned. In this way, the VPN label of a given VN is set to the corresponding VNI. This approach doesn't require any change to the data plane.
2) the second way is to allocate a separate protocol type code for the global MPLS label so as to distinguish global labels from downstream-assigned and upstream-assigned labels. This approach requires some change to the data plane of PE routers.
3) the third way is to reserve a special purpose label to indicate that the label below such special purpose label is a global label. This approach requires some change to the data plane of PE routers as well.

In case 2) and 3), the global label space mentioned above could be a label space dedicated for VNI or a label space which is shared with other applications (e.g., segment routing). 

Any comments?

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 19 Jul 2013 03:42:50 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Xuxiaohu
> 发送时间: 2013年7月18日 17:55
> 收件人: [email-masked]; L3VPN; [email-masked]; [email-masked]
> 主题: [nvo3] The possibility of using global MPLS labels as VNIs
> 
> Hi all,
> 
> Till now, it seem that the only remaining technical reason for some people to
> prefer VXLAN/NVGRE encapsulation format to MAC-in-MPLS-in-IP
> encapsulation format for network virtualization overlay is the former has global
> VNIs while the latter doesn't have. If this reason is true, why can't we consider

Or the reason for requiring global VNI in the data packet itself is fake or insignificant? I just noticed that the NVo3 data plane requirement doc just mentioned "...This field MAY be an explicit, unique (to the administrative domain) virtual network identifier (VNID) or MAY express the necessary context information in other ways (e.g. a locally significant identifier)..." I haven't found any description about the reason for requiring global VNI in the data center packet in the NVO3 related docs. Shouldn't the reason for requiring global VNI in the data packet be investigated by NVo3 WG? Since it would be beneficial to the gap analysis work which would be performed on the existing STANDARDIZED candidate mechanisms, IMHO.

Best regards,
Xiaohu

> the possibility of using global MPLS labels to achieve the same goal?

> 1) the first way is to allocate a label block from the existing label space and use
> it as a global label space from which VPN labels are assigned. In this way, the
> VPN label of a given VN is set to the corresponding VNI. This approach doesn't
> require any change to the data plane.
> 2) the second way is to allocate a separate protocol type code for the global
> MPLS label so as to distinguish global labels from downstream-assigned and
> upstream-assigned labels. This approach requires some change to the data
> plane of PE routers.
> 3) the third way is to reserve a special purpose label to indicate that the label
> below such special purpose label is a global label. This approach requires some
> change to the data plane of PE routers as well.
> 
> In case 2) and 3), the global label space mentioned above could be a label space
> dedicated for VNI or a label space which is shared with other applications (e.g.,
> segment routing).
> 
> Any comments?
> 
> Best regards,
> Xiaohu
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: <[email-masked]>
Date: Fri, 19 Jul 2013 13:18:19 +0000

Hi Xuxiaohu,

2013-07-18, Xuxiaohu:
>
> Till now, it seem that the only remaining technical reason for some
> people to prefer VXLAN/NVGRE encapsulation format to
> MAC-in-MPLS-in-IP encapsulation format for network virtualization
> overlay is the former has global VNIs while the latter doesn't have.
> If this reason is true, why can't we consider the possibility of
> using global MPLS labels to achieve the same goal?

IMHO, examining *why* someone would want a "global VNI" should be the 
start of the discussion, rather than possible solutions.

I could possibly see at least one reason *not* to try to have a 
dedicated identifier in the dataplane common for all flows of "a VPN". 
It is not related to the encapsulation, but to the fact that RFC4364 
has, in fact, no strict notion of "a VPN", but only of how connectivity 
is established betweens set of VRFs.

-Thomas

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 19 Jul 2013 06:23:11 -0700

Thomas,

> is established betweens set of VRFs.

Moreover, connectivity between set of VRFs is not "cast in concrete".
To the contrary it could change, as extranets are formed/dissolved,
and the process of forming/dissolving extranets could be fairly
dynamic.

Yakov.

> 
> -Thomas
> 
> ______________________________________________________________________________
___________________________________________
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages elect
roniques etant susceptibles d'alteration,
> they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete th
is message and its attachments.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 19 Jul 2013 13:34:06 +0000

> start of the discussion, rather than possible solutions.

+1.

> is established betweens set of VRFs.

I find http://tools.ietf.org/html/rfc4364#section-1.1 sufficiently
describing the notion of VPN (which could be intranet or extranet).

Cheers
Rajiv

-----Original Message-----
From: Yakov Rekhter <[email-masked]>
Date: Friday, July 19, 2013 9:23 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: The possibility of using global MPLS labels as VNIs ... for
l3vpn

>> Ce message et ses pieces jointes peuvent contenir des informations
>>confidentie
>lles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>recu ce
> message par erreur, veuillez le signaler
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>>ou fal
>sifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged
>>inform
>ation that may be protected by law;
>> As emails may be altered, Orange is not liable for messages that have
>>been mod
>ified, changed or falsified.
>> Thank you.
>> 
>> 
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 19 Jul 2013 16:49:09 +0000

Comments In-Line..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yakov Rekhter
Sent: Friday, July 19, 2013 9:23 AM
To: [email-masked]
Cc: L3VPN
Subject: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn

Thomas,

Moreover, connectivity between set of VRFs is not "cast in concrete".
To the contrary it could change, as extranets are formed/dissolved,
and the process of forming/dissolving extranets could be fairly
dynamic.
[Jim U>] This happens today..

Yakov.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 22 Jul 2013 01:52:52 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Yakov
> Rekhter
> 发送时间: 2013年7月19日 21:23
> 收件人: [email-masked]
> 抄送: L3VPN
> 主题: Re: The possibility of using global MPLS labels as VNIs ... for l3vpn
> 
> Thomas,
> 
> > 2013-07-18, Xuxiaohu:
> > >

Is extranet is a normal requirement for Layer3 DC network virtualization overlay? I haven't seen any description of this in the NVo3 requirement and framework drafts yet.

Best regards,
Xiaohu

> > Orange decline toute responsabilite si ce message a ete altere, deforme ou
> fal
> sifie. Merci.
> >
> > As emails may be altered, Orange is not liable for messages that have been
> mod

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 22 Jul 2013 12:16:22 +0000

Yes creating extranets is currently done in L3VPN. I would assume that this is also creating when extending a customers VPN into a VPC ( Virtual Private Cloud ).. IMO NVO3 is focused on only the overlay technology and not on the service realization.

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Sunday, July 21, 2013 9:53 PM
To: Yakov Rekhter; [email-masked]
Cc: [email-masked]; L3VPN
Subject: re: The possibility of using global MPLS labels as VNIs ... for l3vpn

Best regards,
Xiaohu

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Mon, 22 Jul 2013 16:19:19 +0000

As I remember, the global VPN-ID was discussed/debated in L3VPN WG around
2003-2006, the global VPN-ID was proposed in the vr draft. The general
consensus of the WG was that the L3VPN solution would be more flexible and
scalable without the global VPN-ID, as the way RFC4364/2547 handling it.

I don't believe this has changed since then. In fact, the extensive large
scale global deployments of 4364 L3VPNs over the past 15 years provide
good living testimony of it.

Luyuan

-----Original Message-----
From: <UTTARO>, JAMES <[email-masked]>
Date: Friday, July 19, 2013 12:49 PM
To: Yakov Rekhter <[email-masked]>, "[email-masked]"
<[email-masked]>
Cc: L3VPN <[email-masked]>
Subject: RE: The possibility of using global MPLS labels as VNIs ... for
l3vpn

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 23 Jul 2013 01:51:06 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Luyuan Fang (lufang)
> 发送时间: 2013年7月23日 0:19
> 收件人: UTTARO, JAMES; Yakov Rekhter; [email-masked]
> 抄送: L3VPN

I fully agree that we should make the most of the existing and proven technologies if possible. The reason that I started this discussion is to make sure whether the Virtual Network Context Identification contained in the data packet is REALLY required to be globally unique in some cases.

Best regards,
Xiaohu 

> >>______________________________________________________________
> ___________
> >>_____

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 23 Jul 2013 09:39:42 +0300

Kireeti

On Jul 23, 2013, at 4:51, Xuxiaohu <[email-masked]> wrote:

> The reason that I started this discussion is to make sure whether the Virtual Network Context Identification contained in the data packet is REALLY required to be globally unique in some cases.

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 23 Jul 2013 09:46:19 +0300

Hi Xuxiaohu,

Sorry for the previous empty email. 

> The reason that I started this discussion is to make sure whether the Virtual Network Context Identification contained in the data packet is REALLY required to be globally unique in some cases.

No. There's nothing useful that I know that one can do with global IDs in the data plane that one cannot do with local IDs, and local IDs are easier to allocate and manage. So, I'd be going the other way and advocate locally significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Kireeti

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 23 Jul 2013 07:05:35 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Kireeti
> Kompella
> 发送时间: 2013年7月23日 14:46
> 收件人: Xuxiaohu
> 抄送: [email-masked]; L3VPN; Yakov Rekhter; [email-masked];
> UTTARO, JAMES
> > The reason that I started this discussion is to make sure whether the Virtual
> Network Context Identification contained in the data packet is REALLY required
> to be globally unique in some cases.
> 
> No. There's nothing useful that I know that one can do with global IDs in the
> data plane that one cannot do with local IDs, and local IDs are easier to
> allocate and manage. So, I'd be going the other way and advocate locally
> significant VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)

Hi Kireeti,

I've ever heard that the major technical reason for some operators to prefer VXLAN or NVGRE to MAC-in-MPLS-in-IP as the encapsulation scheme is that the former provides global VNIDs in the data packets. Therefore, I want to know the concrete use cases where the global VNID is required. Now since you advocate locally significant VNIDs for VXLAN and NVGRE, would you please share your reason why not directly use the MAC-in-MPLS-in-IP format where the VNID (i.e., VPN label) is already locally significant?

Best regards,
Xiaohu

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 23 Jul 2013 11:20:51 +0000

+1

Regards,
Jeff

---

From: Aldrin Isaac <[email-masked]>
Date: Tue, 23 Jul 2013 08:59:57 -0400

+1.

Network operators lose flexibility with Global VNIDs. Virtual topology will
be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a round
hole (where it's otherwise not needed).  I think local context IDs will
make a come back once we regain our sanity.  :).

On Tuesday, July 23, 2013, Kireeti Kompella wrote:

> On Jul 23, 2013, at 4:51, Xuxiaohu <[email-masked] <javascript:;>>
> wrote:
>
> > The reason that I started this discussion is to make sure whether the
> Virtual Network Context Identification contained in the data packet is
> REALLY required to be globally unique in some cases.
>
> No. There's nothing useful that I know that one can do with global IDs in
> the data plane that one cannot do with local IDs, and local IDs are easier
> to allocate and manage. So, I'd be going the other way and advocate locally
> [email-masked] <javascript:;>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 23 Jul 2013 10:01:37 -0400

Another issue as I recall, was around the management and administration of the ID space to avoid conflicts, etc...

	--Tom

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Tue, 23 Jul 2013 14:05:18 +0000

Xuxiaohu,

> Is extranet is a normal requirement for Layer3 DC network
> virtualization overlay? I haven't seen any description of this in the
> NVo3 requirement and framework drafts yet.

Since we have not been able to fully pursue it as a requirement in nvo3, we have created a separate requirement document (http://tools.ietf.org/html/draft-fang-l3vpn-end-system-requirements-00) in l3vpn WG where it is stated as a requirement:

  "A network virtualization solution should allow a VM or application end-point to directly access multiple VPNs without a need to traverse a gateway. It is often the case that SP infrastructure services are provided to multiple tenants, for example voice-over-IP gateway services or video-conferencing services for branch offices. A network virtualization solution should support both, isolated VPNs and overlapping VPNs (often referred to as "extranets"), as well as both, any-to-any and hub-and-spoke topologies."

Maria

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 23 Jul 2013 14:12:25 +0000

Yep. Thanks, Tom!
Certainly another very important reason to avoid global ID, especially
considering operational impact which protocol designers sometimes forget.

Luyuan

-----Original Message-----
From: Thomas Nadeau <[email-masked]>
Date: Tuesday, July 23, 2013 10:01 AM
To: Luyuan Fang <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, Yakov Rekhter <[email-masked]>,
"[email-masked]" <[email-masked]>, L3VPN <[email-masked]>
Subject: Re: The possibility of using global MPLS labels as VNIs ... for
l3vpn

>
>	Another issue as I recall, was around the management and administration
>of the ID space to avoid conflicts, etc...
>
>	--Tom
>
>
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>Of
>>> Yakov Rekhter
>>>>_______________________________________________________________________
>>>>__
>>>> _____

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 23 Jul 2013 14:31:57 +0000

Xiaohu,

Thanks. I think we are in agreement.
One small subtlety to point out, "existing" is not the reason, "proven"
(to scale), yes. It is "right":-), not because it is there.

>whether the Virtual Network Context Identification contained in the data
>packet is REALLY required to be globally unique in some cases.
Not I know of. 

Thanks,
Luyuan

-----Original Message-----
From: Xuxiaohu <[email-masked]>
Date: Monday, July 22, 2013 9:51 PM
To: Luyuan Fang <[email-masked]>, "UTTARO, JAMES" <[email-masked]>,
Yakov Rekhter <[email-masked]>, "[email-masked]"
<[email-masked]>
Cc: L3VPN <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: re: The possibility of using global MPLS labels as VNIs ... for
l3vpn

>I fully agree that we should make the most of the existing and proven
>technologies if possible. The reason that I started this discussion is to
>make sure whether the Virtual Network Context Identification contained in
>the data packet is REALLY required to be globally unique in some cases.
>
>Best regards,
>Xiaohu 
>
>> Luyuan
>>

---

From: Lucy yong <[email-masked]>
Date: Tue, 23 Jul 2013 15:14:31 +0000

For distributed based architecture, the local context ID has a lot of benefits. For centralized (or SDN) architecture, will the global context ID have advance?  Another way to ask this is: is distributed architecture better than centralized architecture for VPN or virtual network overlay?

Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; [email-masked]; Xuxiaohu; [email-masked]; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

+1.

Network operators lose flexibility with Global VNIDs. Virtual topology will be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a round hole (where it's otherwise not needed).  I think local context IDs will make a come back once we regain our sanity.  :).

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

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 23 Jul 2013 15:21:34 +0000

Lucy,

As I see, using SDN approach or distributed control plane, and using global or local ID are two orthogonal questions.

> is distributed architecture better than centralized architecture for VPN or virtual network overlay?
No necessarily.

Luyuan
From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 23, 2013 11:14 AM
To: Aldrin Isaac <[email-masked]<mailto:[email-masked]>>, Kireeti Kompella <[email-masked]<mailto:[email-masked]>>
Cc: Luyuan Fang <[email-masked]<mailto:[email-masked]>>, L3VPN <[email-masked]<mailto:[email-masked]>>, Yakov Rekhter <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Lucy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; [email-masked]<mailto:[email-masked]>; Xuxiaohu; [email-masked]<mailto:[email-masked]>; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

+1.

Kireeti

---

From: Lucy yong <[email-masked]>
Date: Tue, 23 Jul 2013 15:58:45 +0000

As I see, using SDN approach or distributed control plane, and using global or local ID are two orthogonal questions.
[Lucy] then, the question to be asked is which usage makes sense in the SDN approach,  global ID or local ID? IMHO: they are related.

Lucy

No necessarily.

Luyuan

Lucy

+1.

Kireeti

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 23 Jul 2013 16:06:05 +0000

You choose the ID type: global or local.
You choose the control paradigm, SDN, dynamic control plane, or hybrid.

The two decisions are independent.

My personal preferences: SDN with local ID.

Luyuan

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 23, 2013 11:58 AM
To: Luyuan Fang <[email-masked]<mailto:[email-masked]>>, Aldrin Isaac <[email-masked]<mailto:[email-masked]>>, Kireeti Kompella <[email-masked]<mailto:[email-masked]>>
Cc: L3VPN <[email-masked]<mailto:[email-masked]>>, Yakov Rekhter <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Lucy

No necessarily.

Luyuan

Lucy

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Aldrin Isaac
Sent: Tuesday, July 23, 2013 8:00 AM
To: Kireeti Kompella
Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; [email-masked]<mailto:[email-masked]>; Xuxiaohu; [email-masked]<mailto:[email-masked]>; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

+1.

Kireeti

---

From: Lucy yong <[email-masked]>
Date: Tue, 23 Jul 2013 16:28:19 +0000

In distributed control plane approach, we have strong consensus that local ID is the way to go.

Like to hear more the people opinions about: in SDN approach, will global ID and local ID are equally good (just mater choice) or one is better than other?

Lucy

From: Luyuan Fang (lufang) [mailto:[email-masked]]
Sent: Tuesday, July 23, 2013 11:06 AM
To: Lucy yong; Aldrin Isaac; Kireeti Kompella
Cc: L3VPN; Yakov Rekhter; [email-masked]; Xuxiaohu; [email-masked]; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Luyuan

Lucy

No necessarily.

Luyuan

Lucy

+1.

Kireeti

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 23 Jul 2013 19:45:53 +0300

> Like to hear more the people opinions about: in SDN approach, will global ID and local ID are equally good (just mater choice) or one is better than other?

The SDN (centralized) approach makes allocation of global IDs easier. However, Xiaohu asked a data plane question. Local IDs are much easier for the data plane.

BTW, I am not in favor of centralizing everything. 

Kireeti

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 23 Jul 2013 17:10:13 +0000

Does a pure SDN network need MPLS labels?
A control plane that contains MPLS protocols is distributed
even if there are elements of SDN in it.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, July 23, 2013 9:28 AM
To: Luyuan Fang (lufang); Aldrin Isaac; Kireeti Kompella
Cc: L3VPN; Yakov Rekhter; [email-masked]; [email-masked]; UTTARO, JAMES
Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Lucy

From: Luyuan Fang (lufang) [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, July 23, 2013 11:06 AM
To: Lucy yong; Aldrin Isaac; Kireeti Kompella
Cc: L3VPN; Yakov Rekhter; [email-masked]<mailto:[email-masked]>; Xuxiaohu; [email-masked]<mailto:[email-masked]>; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Luyuan

Lucy

No necessarily.

Luyuan

Lucy

+1.

Kireeti

---

From: "Chen, Weijing" <[email-masked]>
Date: Tue, 23 Jul 2013 16:50:15 +0000

Centralized controller can allocate global IDs and build the mapping table of global ID to associated local ID.  Data plane and control protocol need not to aware of global ID.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Tuesday, July 23, 2013 11:46 AM
To: Lucy yong
Cc: [email-masked]; L3VPN; Yakov Rekhter; [email-masked]; Aldrin Isaac; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Kireeti

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 23 Jul 2013 17:03:22 +0000

One area where it would perhaps make a difference for SDN is in the case of merging two SDN controlled regions. Global identifiers (for anything) that overlap between the two SDN regions that must then be merged/deconflicted would be tricky to deal with.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Tuesday, July 23, 2013 12:46 PM
To: Lucy yong
Cc: [email-masked]; L3VPN; Yakov Rekhter; [email-masked]; Aldrin Isaac; Xuxiaohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Kireeti

---

From: Somesh Gupta <[email-masked]>
Date: Tue, 23 Jul 2013 12:36:03 -0700

A centralized architecture for a single domain is the way things
will be in practice (already are). One way or the other, non-virtualized
network devices (physical switches etc) will have to fit into that
model.

Now we can debate the definition of a domain is :) It may
be defined by the scope of a centralized control plane?

Somesh

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, July 23, 2013 8:15 AM
To: Aldrin Isaac; Kireeti Kompella
Cc: [email-masked]; L3VPN; Yakov Rekhter; [email-masked]; Xuxiaohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Lucy

+1.

Kireeti

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 23 Jul 2013 20:42:56 +0000

Maybe the approach should be to gather reqs and then decide what will be or not be in practice.

Jim Uttaro

From: Somesh Gupta [mailto:[email-masked]]
Sent: Tuesday, July 23, 2013 3:36 PM
To: Lucy yong; Aldrin Isaac; Kireeti Kompella
Cc: [email-masked]; L3VPN; Yakov Rekhter; [email-masked]; Xuxiaohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Somesh

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, July 23, 2013 8:15 AM
To: Aldrin Isaac; Kireeti Kompella
Cc: [email-masked]<mailto:[email-masked]>; L3VPN; Yakov Rekhter; [email-masked]<mailto:[email-masked]>; Xuxiaohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Lucy

+1.

Kireeti

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 23 Jul 2013 15:28:47 -0700

Somesh,

> will be in practice (already are). 

We can all speculate about how "the things will be in practice".

However, in terms of how things "already are", 2547 VPNs, which are widely
deployed today, are *not* based on "a centralized architecture".

Yakov.

> One way or the other, non-virtualized
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Luc=
> y yong
> Cc: [email-masked]; L3VPN; Yakov Rekhter; [email-masked]; Xuxiaohu;=
>  Luyuan Fang (lufang); UTTARO, JAMES
> Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...=
>  for l3vpn
> 
> For distributed based architecture, the local context ID has a lot of benef=
> its. For centralized (or SDN) architecture, will the global context ID have=
>  advance?  Another way to ask this is: is distributed architecture better t=
> han centralized architecture for VPN or virtual network overlay?
> 
> Lucy
> 
> From: [email-masked]<mailto:[email-masked]> [mailto:nvo3-boun=
> [email-masked]] On Behalf Of Aldrin Isaac
> Cc: Luyuan Fang (lufang); L3VPN; Yakov Rekhter; [email-masked]<mailto:nvo3@i=
> etf.org>; Xuxiaohu; [email-masked]<mailto:[email-masked]>=
> ; UTTARO, JAMES
> Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ...=
>  for l3vpn
> 
> +1.
> 
> Network operators lose flexibility with Global VNIDs. Virtual topology will=
>  be fine tuned on top of VNIDs by squeezing a square peg (ACLs) into a roun=
> d hole (where it's otherwise not needed).  I think local context IDs will m=
> ake a come back once we regain our sanity.  :).
> 
> On Jul 23, 2013, at 4:51, Xuxiaohu <[email-masked]<javascript:;>> wrot=
> e:
> 
> > The reason that I started this discussion is to make sure whether the Vir=
> tual Network Context Identification contained in the data packet is REALLY =
> required to be globally unique in some cases.
> 
> No. There's nothing useful that I know that one can do with global IDs in t=
> he data plane that one cannot do with local IDs, and local IDs are easier t=
> o allocate and manage. So, I'd be going the other way and advocate locally =
> --_000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_
> 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:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
> //www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV=3D"Content-Type" CONTENT=
> =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
> oft Word 14 (filtered medium)"><style><!--
> /* Font Definitions */
> @font-face
> 	{font-family:Wingdings;
> 	panose-1:5 0 0 0 0 0 0 0 0 0;}
> @font-face
> 	{font-family:Wingdings;
> 	panose-1:5 0 0 0 0 0 0 0 0 0;}
> @font-face
> 	{font-family:Calibri;
> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
> @font-face
> 	{font-family:Tahoma;
> 	panose-1:2 11 6 4 3 5 4 4 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:12.0pt;
> 	font-family:"Times New Roman","serif";}
> a:link, span.MsoHyperlink
> 	{mso-style-priority:99;
> 	color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{mso-style-priority:99;
> 	color:purple;
> 	text-decoration:underline;}
> p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
> 	{mso-style-priority:99;
> 	mso-style-link:"Balloon Text Char";
> 	margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:8.0pt;
> 	font-family:"Tahoma","sans-serif";}
> span.EmailStyle17
> 	{mso-style-type:personal;
> 	font-family:"Calibri","sans-serif";
> 	color:#1F497D;}
> span.BalloonTextChar
> 	{mso-style-name:"Balloon Text Char";
> 	mso-style-priority:99;
> 	mso-style-link:"Balloon Text";
> 	font-family:"Tahoma","sans-serif";}
> span.EmailStyle20
> 	{mso-style-type:personal-reply;
> 	font-family:"Calibri","sans-serif";
> 	color:#1F497D;}
> .MsoChpDefault
> 	{mso-style-type:export-only;
> 	font-size:10.0pt;}
> @page WordSection1
> 	{size:8.5in 11.0in;
> 	margin:1.0in 1.0in 1.0in 1.0in;}
> div.WordSection1
> 	{page:WordSection1;}
> --></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=3DEN-US link=3Dblue vli=
> nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f=
> ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A central=
> ized architecture for a single domain is the way things<o:p></o:p></span></=
> p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri=
> ","sans-serif";color:#1F497D'>will be in practice (already are). One way or=
>  the other, non-virtualized<o:p></o:p></span></p><p class=3DMsoNormal><span=
>  style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D=
> '>network devices (physical switches etc) will have to fit into that<o:p></=
> o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fa=
> mily:"Calibri","sans-serif";color:#1F497D'>model.<o:p></o:p></span></p><p c=
> lass=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","san=
> s-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><s=
> pan style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F4=
> 97D'>Now we can debate the definition of a domain is </span><span style=3D'=
> font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><span style=
> =3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> It =
> may<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0=
> pt;font-family:"Calibri","sans-serif";color:#1F497D'>be defined by the scop=
> e of a centralized control plane?<o:p></o:p></span></p><p class=3DMsoNormal=
> ><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#=
> 1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'fon=
> t-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Somesh<o:p>=
> </o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-=
> family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><d=
> iv 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=3DMsoNormal><b><span style=3D'font-size:10.0pt;=
> font-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size=
> :10.0pt;font-family:"Tahoma","sans-serif"'> [email-masked] [mailto:n=
> [email-masked]] <b>On Behalf Of </b>Lucy yong<br><b>Sent:</b> Tuesday=
> , July 23, 2013 8:15 AM<br><b>To:</b> Aldrin Isaac; Kireeti Kompella<br><b>=
> Cc:</b> [email-masked]; L3VPN; Yakov Rekhter; [email-masked]; Xuxia=
> ohu; Luyuan Fang (lufang); UTTARO, JAMES<br><b>Subject:</b> Re: [nvo3] The =
> possibility of using global MPLS labels as VNIs ... for l3vpn<o:p></o:p></s=
> pan></p></div></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMs=
> oNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";=
> color:#1F497D'>For distributed based architecture, the local context ID has=
>  a lot of benefits. For centralized (or SDN) architecture, will the global =
> context ID have advance? &nbsp;Another way to ask this is: is distributed a=
> rchitecture better than centralized architecture for VPN or virtual network=
>  overlay?<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-siz=
> e:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p=
> ></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-famil=
> y:"Calibri","sans-serif";color:#1F497D'>Lucy<o:p></o:p></span></p><p class=
> =3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-se=
> rif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div style=3D'border:none;b=
> order-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'b=
> order:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p cla=
> ss=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma","san=
> s-serif"'>From:</span></b><span style=3D'font-size:10.0pt;font-family:"Taho=
> ma","sans-serif"'> <a href=3D"mailto:[email-masked]">nvo3-bounces@ie=
> tf.org</a> [<a href=3D"mailto:[email-masked]">mailto:nvo3-bounces@ie=
> tf.org</a>] <b>On Behalf Of </b>Aldrin Isaac<br><b>Sent:</b> Tuesday, July =
> 23, 2013 8:00 AM<br><b>To:</b> Kireeti Kompella<br><b>Cc:</b> Luyuan Fang (=
> lufang); L3VPN; Yakov Rekhter; <a href=3D"mailto:[email-masked]">[email-masked]=
> rg</a>; Xuxiaohu; <a href=3D"mailto:[email-masked]">thomas.morin@o=
> range.com</a>; UTTARO, JAMES<br><b>Subject:</b> Re: [nvo3] The possibility =
> of using global MPLS labels as VNIs ... for l3vpn<o:p></o:p></span></p></di=
> v></div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>+1.<=
> o:p></o:p></p><div><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
> class=3DMsoNormal>Network operators lose flexibility&nbsp;with Global VNIDs=
> .&nbsp;Virtual&nbsp;topology will be fine tuned&nbsp;on top of VNIDs by&nbs=
> p;squeezing a square peg (ACLs) into a round hole (where it's otherwise not=
>  needed). &nbsp;I think&nbsp;local context IDs will make a come back once w=
> e regain our&nbsp;sanity. &nbsp;:).<o:p></o:p></p></div><div><p class=3DMso=
> Normal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal>On Tuesday, July 23, =
> 2013, Kireeti Kompella wrote:<o:p></o:p></p><p class=3DMsoNormal>Hi Xuxiaoh=
> u,<br><br>Sorry for the previous empty email.<br><br>On Jul 23, 2013, at 4:=
> 51, Xuxiaohu &lt;<a href=3D"javascript:;">[email-masked]</a>&gt; wrote=
> :<br><br>&gt; The reason that I started this discussion is to make sure whe=
> ther the Virtual Network Context Identification contained in the data packe=
> t is REALLY required to be globally unique in some cases.<br><br>No. There'=
> s nothing useful that I know that one can do with global IDs in the data pl=
> ane that one cannot do with local IDs, and local IDs are easier to allocate=
>  and manage. So, I'd be going the other way and advocate locally significan=
> t VNIDs for VXLAN and NVGRE, not global IDs for VPNs. (And I do)<br><br>Kir=
> eeti<br>_______________________________________________<br>nvo3 mailing lis=
> t<br><a href=3D"javascript:;">[email-masked]</a><br><a href=3D"https://www.i=
> etf.org/mailman/listinfo/nvo3" target=3D"_blank">https://www.ietf.org/mailm=
> an/listinfo/nvo3</a><o:p></o:p></p></div></div></div></div></div></body></h=
> tml>=
> 
> --_000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_--
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 23 Jul 2013 22:55:52 +0000

Somesh,

	IMO one of the bigger use cases is "stitching" between data center and WAN and data center 1 and data center 2 instances of a given VPN. These two CUGs are not orthogonal, this is where it is important to define the services that will utilize the technology.

Jim Uttaro

-----Original Message-----
From: Somesh Gupta [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2013 6:38 PM
To: Yakov Rekhter
Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; [email-masked]; L3VPN; [email-masked]; Xuxiaohu; Luyuan Fang (lufang); UTTARO, JAMES
Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn 

Yaakov,

I thought we were discussing virtual overlay networks (not VPNs) as related
to virtualized data centers (maybe I assumed incorrectly).

>From whatever I see from the vendors of these products, they seem to be
shipping/moving towards centralized control plane.

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2013 3:29 PM
> To: Somesh Gupta
> Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; [email-masked];
> L3VPN; Yakov Rekhter; [email-masked]; Xuxiaohu; Luyuan Fang (lufang);
> UTTARO, JAMES
> > etf.org>; Xuxiaohu;
> [email-masked]<mailto:[email-masked]>=
> > ; UTTARO, JAMES
> > --
> _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_
> > mily:"Calibri","sans-
> serif";color:#1F497D'>model.<o:p></o:p></span></p><p c=
> > family:"Calibri","sans-
> serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><d=
> > pan></p></div></div><p
> class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMs=
> > lufang); L3VPN; Yakov Rekhter; <a
> href=3D"mailto:[email-masked]">[email-masked]=
> > rg</a>; Xuxiaohu; <a
> href=3D"mailto:[email-masked]">thomas.morin@o=
> > o:p></o:p></p><div><p
> class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
> > etf.org/mailman/listinfo/nvo3"
> target=3D"_blank">https://www.ietf.org/mailm=
> >
> > --
> _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_-
> -
> >

---

From: Richard Li <[email-masked]>
Date: Wed, 24 Jul 2013 00:12:19 +0000

We may be able to get some wisdom from VLAN where both local and global ids are used.

The global vlan id is used to build a whole "subnet" across different and multi-hop Ethernet segments. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Wednesday, July 24, 2013 12:46 AM
To: Lucy yong
Cc: [email-masked]; L3VPN; Yakov Rekhter; [email-masked]; Aldrin Isaac; UTTARO, JAMES
Subject: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn

Kireeti

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 24 Jul 2013 01:50:32 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Richard
> Li
> 发送时间: 2013年7月24日 8:12
> 收件人: Kireeti Kompella; Lucy yong
> 抄送: L3VPN; Yakov Rekhter; [email-masked]; Aldrin Isaac;
> [email-masked]; UTTARO, JAMES
> 主题: Re: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn
> 

Whether a global VN ID in the data packet is required may depend on whether the transit nodes need to know the global VN ID, IMHO. For VLAN, the transit nodes need to know the global VN ID (i.e., VLAN ID) for packet forwarding. For TRILL, the transit RB nodes need to know the global VN ID (i.e., VLAN ID or FGL) for VLAN or FGL pruning. For NVo3, I haven't seen any use case yet and therefore I want to make sure whether there is any use case that I had missed.

Best regards,
Xiaohu

> > Like to hear more the people opinions about: in SDN approach, will global ID
> and local ID are equally good (just mater choice) or one is better than other?
> 
> The SDN (centralized) approach makes allocation of global IDs easier. However,
> Xiaohu asked a data plane question. Local IDs are much easier for the data
> plane.
>

---

From: Somesh Gupta <[email-masked]>
Date: Tue, 23 Jul 2013 15:37:55 -0700

Yaakov,

---

From: Somesh Gupta <[email-masked]>
Date: Tue, 23 Jul 2013 16:05:47 -0700

Jim,

I agree with you on the need to support services spanning
multiple "domains".

If that is the focus of the group, then of course, distributed
control plane makes sense.

Somesh

> From: UTTARO, JAMES [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2013 3:56 PM
> To: Somesh Gupta; Yakov Rekhter
> L3VPN; [email-masked]; Xuxiaohu; Luyuan Fang (lufang)
>       IMO one of the bigger use cases is "stitching" between data center
> and WAN and data center 1 and data center 2 instances of a given VPN.
> These two CUGs are not orthogonal, this is where it is important to define
> the services that will utilize the technology.
>
> Jim Uttaro
>
> L3VPN; [email-masked]; Xuxiaohu; Luyuan Fang (lufang); UTTARO, JAMES
> Vir=
> > > tual Network Context Identification contained in the data packet is
> REALLY
> > =
> t=
> > > o allocate and manage. So, I'd be going the other way and advocate
> locally
> > =
> > > //www.w3.org/TR/REC-html40"><head><META HTTP-
> EQUIV=3D"Content-
> > Type" CONTENT=
> > > nk=3Dpurple><div class=3DWordSection1><p
> class=3DMsoNormal><span
> > style=3D'f=
> > > [email-masked]] <b>On Behalf Of </b>Lucy
> yong<br><b>Sent:</b>
> > Tuesday=
> > > 23, 2013 8:00 AM<br><b>To:</b> Kireeti Kompella<br><b>Cc:</b>
> Luyuan
> > Fang (=
> > >  needed). &nbsp;I think&nbsp;local context IDs will make a come back
> once
> > w=
> > > 2013, Kireeti Kompella wrote:<o:p></o:p></p><p
> class=3DMsoNormal>Hi
> > Xuxiaoh=
> > > u,<br><br>Sorry for the previous empty email.<br><br>On Jul 23, 2013,
> at
> > 4:=
> > > 51, Xuxiaohu &lt;<a
> href=3D"javascript:;">[email-masked]</a>&gt;
> > wrote=

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 23 Jul 2013 23:24:31 +0000

The challenge I have had with NVO3 is determining the focus of the group. The message I have gotten is that it is solely focused on overlay technology not on how it will be used outside of a single data center. There is a notion that some device will speak overlay technology and 2547 and this will be the GW but that is about it..This of course leads us to solutions which are at best myopic. So where do we capture the reqs that reflect the VPN in the data center as part of a greater whole? This includes items like stitching but also security, protocol definition, GW etc... I have attached my discussion thread with folks from earlier this year. At the time I was hoping to create a reqs document that would address my biggest use case which is extending a WAN VPN into a Data Center.. I would like to pursue this.

Jim Uttaro

-----Original Message-----
From: Somesh Gupta [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2013 7:06 PM
To: UTTARO, JAMES; Yakov Rekhter
Cc: Lucy yong; Aldrin Isaac; Kireeti Kompella; [email-masked]; L3VPN; [email-masked]; Xuxiaohu; Luyuan Fang (lufang)
Subject: RE: [nvo3] The possibility of using global MPLS labels as VNIs ... for l3vpn 

Jim,

Somesh

> _000_BB8D8AEC7DBA1F41810DCB5D38AF56ABA3B78814C8HQ1EXCH02corp_-

Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft
From: "UTTARO, JAMES" <[email-masked]>
To: "'Balus, Florin Stelian (Florin)'" <[email-masked]>, "'Ali Sajassi (sajassi)'" <[email-masked]>, 'John E Drake' <[email-masked]>, 'Kireeti Kompella' <[email-masked]>, "'Henderickx, Wim (Wim)'" <[email-masked]>, "'Yakov Rekhter'" <[email-masked]>, 'Rex Fernando' <[email-masked]>, "'LASSERRE, MARC (MARC)'" <[email-masked]>, 'Nabil Mobile Bitar' <[email-masked]>
Cc: "LONGHITANO, ANTHONY C" <[email-masked]>, "NGUYEN, HAN Q" <[email-masked]>
Date: Wed, 24 Apr 2013 18:03:40 +0000

Florin,

                Here is the excerpt from Larry which IMO does not support your position..

                "NVO3 is about overlay networks in data centers (DC VPN), which could be a service provider's DC (public) or an enterprise's DC (private). "

The use case that I need covered is for a SP private cloud.

"As far as moving forward, I would welcome requirement text that uses the NVO3 terminology (not 2547), and keeps within the current scope of the NVO3 charter of a single data center.  What do you think?"

.               A VPN can span both the WAN portion and multiple VPCs. I need that use case covered..

Communication Channel between NCO<->NVE..

I think as an industry we need to create reqs for the Comm Channel.. Today folks are using different approaches XMPP, Netconf, etc.. That is cool but all of these must reflective of  a certain set of reqs.

                The other part are reqs for connectivity to a VPN instance that is in a WAN or is distributed across multiple private clouds..

"The assumption in NVO3 has been that a device that supports both an NVO3 protocol within the DC  (L2 or L3) and another VPN technology (e.g. 2547) for over the WAN, could interwork the two."

                I need to have this be much more than an assumption...

So, at the end of the day if NVO3 feels that these items are in the charter then that should be clearly called out. I would love to put this all in one place.. It just seems that from the feedback I have received NVO3 is not the place for it..Let me know how to proceed..

Jim Uttaro

From: Balus, Florin Stelian (Florin) [mailto:[email-masked]]
Sent: Wednesday, April 24, 2013 12:56 PM
To: UTTARO, JAMES; 'Ali Sajassi (sajassi)'; 'John E Drake'; 'Kireeti Kompella'; Henderickx, Wim (Wim); 'Yakov Rekhter'; Rex Fernando; LASSERRE, MARC (MARC); Nabil Mobile Bitar
Cc: LONGHITANO, ANTHONY C; NGUYEN, HAN Q
Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft

Jim,

See in-line...

From: <UTTARO>, JAMES <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 24, 2013 6:38 AM
To: "'Ali Sajassi (sajassi)'" <[email-masked]<mailto:[email-masked]>>, Florin Balus <[email-masked]<mailto:[email-masked]>>, 'John E Drake' <[email-masked]<mailto:[email-masked]>>, 'Kireeti Kompella' <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>, 'Yakov Rekhter' <[email-masked]<mailto:[email-masked]>>, Rex Fernando <[email-masked]<mailto:[email-masked]>>
Cc: "LONGHITANO, ANTHONY C" <[email-masked]<mailto:[email-masked]>>, "NGUYEN, HAN Q" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft

All,

                IMO the NVO3 charter and subsequent requirements draft does not cover the following:

                A) Network Controller<->NVE Communication Channel

I believe this is part of the charter and we eluded to it in the framework draft: http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework/?include_text=1 .

                B) VPC technology i.e CUGs etc....

The term Virtual Network (VN) and associated VNI means the same thing (see the above document). People wanted to use different terminology and we went through a lot of unnecessarily long exchanges to get this sorted out. If there are differences between what you have in mind for CUG and the VN description we should address them.

                C) WAN<->VPC(s)

If you mean here the WAN-VN interworking (GW) function we used a DC GW function and some description of the required functions in the above document. Should we expand it or dedicate a section to it? The control plane requirements is another place where this can be addressed.

                What are some of the thoughts as to how to proceed? First of all should we cover all three ( A,B,C )? I am most interested in getting ( A ) organized in the industry so IMO I think we should build a reqs document around this.. Ali had suggested extending the scope but I am not sure of that.. Pls Comment...

I believe the fastest way is to include the A, B, C in existing docs.

Thanks,

                Jim Uttaro

From: UTTARO, JAMES
Sent: Monday, April 22, 2013 10:40 AM
To: UTTARO, JAMES; 'Larry Kreeger (kreeger)'; 'LASSERRE, MARC (MARC)'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Cc: Ali Sajassi (sajassi); BALUS Florin; John E Drake; Kireeti Kompella; Henderickx, Wim (Wim); Yakov Rekhter
Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft

Larry,

                TBH the scope as described below is simply too narrow for my purposes.. I want to create a standard for extending a traditional VPN context into one or more data centers. Inherent in this is the ability to maintain the same service definition/experience when instantiating and endpoint in a Virtual Private Data Center..  I think that I will pursue this in either L2 or L3 WGs. As I began describing there are four main areas.. Hopefully we can re-use some of the work that was done in NVO3..

Jim Uttaro

From: UTTARO, JAMES
Sent: Sunday, April 21, 2013 6:52 PM
To: 'Larry Kreeger (kreeger)'; 'LASSERRE, MARC (MARC)'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft

Larry,

                I am trying to figure out how to move forward.. Give me a few more days to think about this...

Thanks,

                Jim Uttaro

From: Larry Kreeger (kreeger) [mailto:[email-masked]]
Sent: Friday, April 19, 2013 5:37 PM
To: UTTARO, JAMES; 'LASSERRE, MARC (MARC)'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft

Hi Jim,

I sent the below to you 10 days ago.  I'm just making sure it didn't slip through the cracks somewhere since I didn't see a reply from you.

Thanks, Larry

From: Larry Kreeger <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 9, 2013 6:30 PM
To: "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>, "'LASSERRE, MARC (MARC)'" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft

Hi Jim,

NVO3 is about overlay networks in data centers (DC VPN), which could be a service provider's DC (public) or an enterprise's DC (private).  The NVO3 framework document (draft-ietf-nvo3-framework-02) defines a Virtual Data Center as "A container for virtualized compute, storage and network services. Managed by a single tenant, a Virtual DC can contain multiple VNs and multiple Tenant Systems that are connected to one or more of these VNs.".  I'm not sure what your definition of VPC is (e.g. does it extend outside of a physical data center?), or whether it has any bearing on the requirements as you see them.  The assumption in NVO3 has been that a device that supports both an NVO3 protocol within the DC  (L2 or L3) and another VPN technology (e.g. 2547) for over the WAN, could interwork the two.

Once upon a time, there was a long discussion on the NVO3 list about the CUG terminology.  Several people felt that a CUG could be represented by the NVO3 term Virtual Network (a virtual L2 or L3 domain - depending on the service).  The thread petered out and we do not have CUG defined anywhere.

As far as moving forward, I would welcome requirement text that uses the NVO3 terminology (not 2547), and keeps within the current scope of the NVO3 charter of a single data center.  What do you think?

Thanks, Larry

From: <UTTARO>, JAMES <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 9, 2013 7:10 AM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>, "'LASSERRE, MARC (MARC)'" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft

Larry,

                I am mostly focuses on the VPC ( Virtual Private Cloud ) as opposed to a VDC which may support both private and public customers..  The terminology is specific to maintaining CUGs in this VPC for VPN separation, I tend to write in the language of 2547 but am agnostic in terms of solution..

Comments In-Line..

Jim Uttaro

From: Larry Kreeger (kreeger) [mailto:[email-masked]]
Sent: Monday, April 08, 2013 8:51 PM
To: UTTARO, JAMES; 'LASSERRE, MARC (MARC)'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft

Hi Jim,

Our draft does seem related to what you are discussing below, except for a few things.  For example, in NVO3 we are being very vague about the architecture at the moment and not assuming that there is a "controller" or "directory service" but are instead calling this the "oracle", or hopefully the new name "Information Mapping Authority".  The NVO3 charter is focused on intra-DC overlays (which the charter calls Data Center VPNs), where I see mention below of WAN connectivity which seems out of scope for now.  I also get concerned when I see mention of BGP VPN terminology like CUGs, RTs, RDs since the requirements need to be independent of what the solution is (BGP may be one possible solution).  Other than these differences, I do see useful characteristics/requirements for the NVE-to-oracle protocol in the message below!

[Jim U>] Agreed.. How would you want to proceed?

 - Larry

P.S. Does "VPC" stand for "Virtual Private Cloud"?  If so, we have been using the term "Virtual Data Center (VDC)".  Do you see these terms as being the same or different?

[Jim U>] Yes, the VPC implies that the customers are private in nature and want to ensure security and traditional CUG semantic in the VPC, furthermore implicit is the need to connect to their traditional VPN which may span multiple WAN AS domains...

From: <UTTARO>, JAMES <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 8, 2013 11:31 AM
To: "'LASSERRE, MARC (MARC)'" <[email-masked]<mailto:[email-masked]>>, Larry Kreeger <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>, David Black <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft

All,

                I am attempting build a reqs document in re the Network Controller<->NVE ( See Below )... Folks have suggested that I open this up to include all reqs relating to a VPC ( See Below )...  Marc has suggested that we expand the current kreeger draft and include these areas.. Pls Comment.. IMO I need to create reqs for the comm. Channels and also I think it would be beneficial to all to capture addl reqs in re the VPC as described below..

Thanks,

                Jim Uttaro

From: LASSERRE, MARC (MARC) [mailto:[email-masked]]
Sent: Tuesday, April 02, 2013 10:47 AM
To: UTTARO, JAMES; Balus, Florin Stelian (Florin); 'Sami Boutros (sboutros)'; Henderickx, Wim (Wim)
Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssalam); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil); LONGHITANO, ANTHONY C; NGUYEN, HAN Q
Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft

Hi Jim,

I did not get to see Ali's email as my name got added to the cc list later on.

I'd suggest to include Larry Kreeger in this discussion - being Ali's co-worker.

In order to make progress, it would be a good thing to add text related to your points below into Larry's draft since it is already an nvo3 requirements milestone draft.

Thanks,

Marc

     _____

   From: UTTARO, JAMES [mailto:[email-masked]]
   Sent: Friday, March 29, 2013 5:14 PM
   To: LASSERRE, MARC (MARC); Balus, Florin Stelian (Florin); 'Sami Boutros (sboutros)'; Henderickx, Wim (Wim)
   Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssalam); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil); LONGHITANO, ANTHONY C; NGUYEN, HAN Q
   Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft

   Marc,

                   Let me take another read on the draft.. Do you think the items that Ali brought up in his e-mail are covered under kreeger? If not should they be or should another draft be created that looks at these areas:

   a) Controller<->NVE communication channel

   b) CUG Definition

   c) Fabric Encapsulation

   d) WAN<->VPC connectivity

   e) Application of SDN flowspec like directives to a VM/VNIC? Sami and I had an interesting conversation about this..

   f) Creating shared extranets on the NVE ( Function of a & b )?

   What else?

   I am not religious, I started this effort concerned that we did not have  set of reqs for ( a ) if folks believe we should expand to the who shebang I am supportive of that in any venue..

   Thanks,

                   Jim Uttaro

   From: LASSERRE, MARC (MARC) [mailto:[email-masked]]
   Sent: Monday, March 25, 2013 10:44 AM
   To: Balus, Florin Stelian (Florin); UTTARO, JAMES; 'Sami Boutros (sboutros)'; Henderickx, Wim (Wim)
   Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssalam); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil); LONGHITANO, ANTHONY C; NGUYEN, HAN Q
   Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft

   Jim, Florin,

   I agree that draft-kreeger-nvo3-overlay-cp is the right fit for addressing channel specific requirements.

   Including a separate section in this draft would be useful.

   Marc

        _____

      From: Balus, Florin Stelian (Florin)
      Sent: Monday, March 18, 2013 6:18 PM
      To: UTTARO, JAMES; 'Sami Boutros (sboutros)'; Henderickx, Wim (Wim)
      Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssalam); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil); LONGHITANO, ANTHONY C; NGUYEN, HAN Q; LASSERRE, MARC (MARC)
      Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft

      No the draft below is data plane requirements. I was talking about the following draft where this might fit:

      http://datatracker.ietf.org/doc/draft-kreeger-nvo3-overlay-cp/?include_text=1

      (There are others I might have missed see at http://datatracker.ietf.org/wg/nvo3/ ....)

      This draft in my opinion needs your text badly. :)

      From: <UTTARO>, JAMES <[email-masked]<mailto:[email-masked]>>
      Date: Monday, March 18, 2013 10:09 AM
      To: Florin Balus <[email-masked]<mailto:[email-masked]>>, "'Sami Boutros (sboutros)'" <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>
      Cc: John E Drake <[email-masked]<mailto:[email-masked]>>, Kireeti Kompella <[email-masked]<mailto:[email-masked]>>, Yakov Rekhter <[email-masked]<mailto:[email-masked]>>, "Samer Salam (ssalam)" <[email-masked]<mailto:[email-masked]>>, "Rex Fernando (rex)" <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "Khandekar, Sunil S (Sunil)" <[email-masked]<mailto:[email-masked]>>, "LONGHITANO, ANTHONY C" <[email-masked]<mailto:[email-masked]>>, "NGUYEN, HAN Q" <[email-masked]<mailto:[email-masked]>>, "LASSERRE, MARC (MARC)" <[email-masked]<mailto:[email-masked]>>
      Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft

      Florin,

                      I think the draft you are referencing is:

                      http://tools.ietf.org/html/draft-bl-nvo3-dataplane-requirements-03

                      My thoughts is that we need to define the communication channel independently of the architectural framework of an NVO.. This will allow for implementers to have a clear understanding of the reqs of the channel independently of the data plane, OAM, GWs etc... In that regard maybe this does not belong in NVO3 but I seems the best fit..

      Thanks,

                      Jim Uttaro

      From: Balus, Florin Stelian (Florin) [mailto:[email-masked]]
      Sent: Monday, March 18, 2013 12:34 PM
      To: UTTARO, JAMES; 'Sami Boutros (sboutros)'; Henderickx, Wim (Wim)
      Cc: John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssalam); Rex Fernando (rex); Ali Sajassi (sajassi); Khandekar, Sunil S (Sunil); LONGHITANO, ANTHONY C; NGUYEN, HAN Q; LASSERRE, MARC (MARC)
      Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft

      I agree. There is a draft already in place for control plane requirements which will really benefit from additional operator input.

      From: <UTTARO>, JAMES <[email-masked]<mailto:[email-masked]>>
      Date: Monday, March 18, 2013 6:41 AM
      To: "'Sami Boutros (sboutros)'" <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Wim)" <[email-masked]<mailto:[email-masked]>>
      Cc: John E Drake <[email-masked]<mailto:[email-masked]>>, Kireeti Kompella <[email-masked]<mailto:[email-masked]>>, Yakov Rekhter <[email-masked]<mailto:[email-masked]>>, "Samer Salam (ssalam)" <[email-masked]<mailto:[email-masked]>>, "Rex Fernando (rex)" <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, Florin Balus <[email-masked]<mailto:[email-masked]>>, "Khandekar, Sunil S (Sunil)" <[email-masked]<mailto:[email-masked]>>, "LONGHITANO, ANTHONY C" <[email-masked]<mailto:[email-masked]>>, "NGUYEN, HAN Q" <[email-masked]<mailto:[email-masked]>>, "LASSERRE, MARC (MARC)" <[email-masked]<mailto:[email-masked]>>
      Subject: RE: Network Controller<->NVE Communication Channel Reqs Draft

      IMO it seems that NVO3 is best suited for this effort..

      Jim Uttaro

      From: Sami Boutros (sboutros) [mailto:[email-masked]]
      Sent: Sunday, March 17, 2013 5:33 PM
      To: Henderickx, Wim (Wim)
      Cc: UTTARO, JAMES; John E Drake; Kireeti Kompella; Yakov Rekhter; Samer Salam (ssalam); Rex Fernando (rex); Ali Sajassi (sajassi); Balus, Florin Stelian (Florin); Khandekar, Sunil S (Sunil); LONGHITANO, ANTHONY C; NGUYEN, HAN Q; LASSERRE, MARC (MARC)
      Subject: Re: Network Controller<->NVE Communication Channel Reqs Draft

      Agreed,

      Correcting Rex e-mail.

      Thanks,

      Sami

      On Mar 17, 2013, at 1:16 AM, Henderickx, Wim (Wim) wrote:

      Jim, this is a good start and we can start from this as a baseline. Do you think we should progress this in NVO3?

      Adding Marc L.

      From: <UTTARO>, JAMES <[email-masked]<mailto:[email-masked]>>
      Date: Sunday 17 March 2013 01:53
      To: John E Drake <[email-masked]<mailto:[email-masked]>>, Kireeti Kompella <[email-masked]<mailto:[email-masked]>>, Yakov Rekhter <[email-masked]<mailto:[email-masked]>>, Wim Henderickx <[email-masked]<mailto:[email-masked]>>, "Sami Boutros (sboutros)" <[email-masked]<mailto:[email-masked]>>, "([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, Rex Fernando <[email-masked]<mailto:[email-masked]>>, sajassi <[email-masked]<mailto:[email-masked]>>, "Balus, Florin Stelian (Florin)" <[email-masked]<mailto:[email-masked]>>
      Cc: "Khandekar, Sunil S (Sunil)" <[email-masked]<mailto:[email-masked]>>, "LONGHITANO, ANTHONY C" <[email-masked]<mailto:[email-masked]>>, "NGUYEN, HAN Q" <[email-masked]<mailto:[email-masked]>>
      Subject: Network Controller<->NVE Communication Channel Reqs Draft

      All,

                      I had a number of conversations with a bunch of you at the IETF this past week regarding the definition of the communication channel between the network controller and the NVE. From the presentations I have seen and the meetings I have attended it is clear that this is an area that needs  definition. To that end I suggest that we pull together a reqs draft that articulates the functionality and semantics of this communication channel.. We have had success with this approach in the past i.e EVPN Reqs, addpaths guidelines etc... Here is a first cut on my thoughts as to the areas that need to be addressed.. I am not looking to over-constrain implementations but we need to define a specification.. Pls let me know if you would like to participate in this effort..I really think we need to do this before we have solutions.. Pls forward if I missed anyone who you feel could add to the effort...

      Functionality ( Bi-Dir Communication )

                      The channel needs to be able to deliver info that will program the NVE.. This includes:

                      1) CUG Definition including RTs, RDs, VPN Label etc... How do know this is successful?

                      Network Management

                      1) Statistics - Retrieving/Programming info.

      a) VM termination ? How should we precede on this is it the responsibility of "compute" to associate a given VM with a CUG ( Not a stats question ;) )? Regardless it seems that the controller should be able to provide info as to which VMs are terminating in a CUG for network management etc...

      b) Server stats? We need to have this information packaged in a manner that is seamless to a customer.. So, if a customer is accessing stats via OSS stack in the WAN the controller should be able to also get stats for the NVE and associated VMs.. i.e how is the NIC performing..

      c) Customer validation ? Will customers want the ability to "Ping" the CUG on a server? This is a requirement for a number of managed services..

      2) Security

      a) Auditing. A record should be available when compute or network associates/disassociates a VM from a given CUG

      b) Access Control. How is access to the server controlled.. For a given server there are principals whom are allowed to perform some set of operations.

      c) Authentication. For a given NVE there are a set of network controllers that are allowed to perform operations. How should this be done if at all??

                      Routing State - The channel needs to deliver routing state, associated semantics i.e path coloring etc and routing policy..

      1)  Static

      a) The current thinking that I have seen revolves around programming routing state analogous to a static route. This also includes NH  Label? My assumption is that the VPN label will be obtained by virtue of the path being programmed in a given CUG

      2) Dynamic

      a) Dynamic routing.. Assuming that the controller is also a straight up reflector should we define the communication channel to provide the semantics of a routing session? I am not sure on this but am not convinced that it should not be precluded.. We may want to "advertise" other routing state i.e dynamically build extranets for extending the SPs services into this VPC ( SDN ).. This could of course be done via that programming method above but let's be clear about what we are looking for..

                      Coordination Problem

      1) Endpoint Failure. My assumption here is that each endpoint can fail and that failure is recognized.. The behavior needs to be defined as to "what should happen"

      2) Transient Failure. The communication channel itself may experience transient failure.. What should be the behavior in terms of ensuring that a subset of messages lost are recovered or not ?

      Election Problem

      1) Given a system where have multiple controllers for redundancy should one of them be "elected" as the primary for all communication?

      Safety Property

      1) Need to ensure that no "side effects" of the specification of the communication channel are permitted that are not inherently part of the specification.. IOW the domain of "effects' are bounded by the specification.. As an ex.. the communication channel may not increase memory for a given server as this is the domain of "compute" or the FIFO nature of the channel must service requests in the order of arrival. We would not want to change the order such that a delete came prior to the add..

      Liveness Property

      1) The "channel" must eventually provide service to every request.. An example of this is that a given request must complete..

      SDN Capability

      1) The communication channel must be able to provide a mechanism to apply SDN constructs in both the data ( flow ) and control plane ( extranet definition ).. The latter is sort of spoken about above in terms of routing but one could imagine that SDN could also provide the ability to constrain a CUG ..

      Sami and I had a long conversation as to what does flow policy mean when all VMs are utilizing the same physical resources i.e NIC.. This is quite interesting.. This will be part 2 ;)

      Thanks,

      Jim Uttaro

---

From: "Mustafa Bayramov (mbayramo)" <[email-masked]>
Date: Fri, 26 Jul 2013 18:59:16 +0000

If it ultimate centralized yes but probably due to high availability , geo redundancy and some other consideration
you will never have completely centralized so at some point ID space need to be synchronized.  : )

Mustafa