Subject: [nvo3] 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: 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:
> > >
> > > 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.
> 
> 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.

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

> Yakov.
> 
> >
> > -Thomas
> >
> >
> ________________________________________________________________
> ______________
> ___________________________________________
> >
> > 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
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages elect
> roniques etant susceptibles d'alteration,
> > 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;
> > 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.
> > 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: 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: "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