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