Hi Robert, Thanks for your clear description. In this email, your model are clearly described, it's different from the model in our draft. In your model, NVO3 gateway and PE are integrated in a single device. In our model, NVO3 gateway and PE are two independent devices. If data center network and MPLS VPN WAN network belongs to two different companies (for example, data center network belongs to Microsoft, MPLS VPN network belongs to AT&T), NVO3 gateway and PE function normally are splitted into two devices instead of integrating into single device. In this case, inter-as solution between NVO3 gateway and PE should be used, there are two solutions of Option-A and Option-B. In this draft, Option-B solution is described in detail.
Pls see my other replies inline with [weiguo]. Then the draft is wrong as Option-A does not use any MPLS encapsulation. [weiguo]. Sorry, it's a slip of the pen. Yes, Option-A has no MPLS encapsulation, native IP forwarding is used between ASBRs. Every VPN people should know the procedures. The correct description is: This is a inter-as option between NVO3 and MPLS VPN network. When traffic from internal NVO3 network is forwarded to external MPLS VPN network, the ASBR(NVO3 Gateway) terminates into a VRF and performs IP lookup, then forwards the traffic to peer ASBR. This mechanism is called Option-A in the draft. You are confusing on which side of ASBR VRFs sit. I am describing the model where ASBR is an option-B ASBR with in the same time integrated PE towards the DC side. There is no option A. [weiguo]: I understand what's your meaning now, we are not discussing the same scenario. In your description, PE and NVO3 gateway are integrated in a single device, so no Option-A here. If MPLS VPN network and data center network belongs to same company(such as AT&T, china telecom, and etc), your model are suitable, PE and NVO3 gateway are integrated on same device, VN ID is bounded to a VRF on the device. In our draft, PE and NVO3 gateway are splitted into two devices, PE belongs to carrier network(such as china telecom, AT&T,and etc), NVO3 gateway belongs to data center(such as Facebook, Microsoft, Tencent, and etc), in this case inter-as Option-A or Option-B solution should be used. In this case, NVO3 gateway in data center is ASBR1, PE in carrier network is ASBR2. If sub-interface is used to separate VPN traffic between ASBR1 and ASBR2, the solution is Option-A. If MPLS VPN Label is used to separate VPN traffic between ASBR1 and ASBR2, it is Option-B solution, the procedures is described in detail in this draft. Note also for clarity that packets are arriving at such PE from DC side not traditionally based on bounding to interface to a VRF but based on VN_ID bounding to a VRF. Some vendors call this "vrf select" mode. [weiguo]: Yes, in your model, bounding interface to VRF isn't needed, only VN ID bounding to VRF exists. Sorry if this model/architecture was not clear in my former mail. [weiguo]: I understand your model now, your model are different from the model described in our draft. Thanks weiguo ________________________________________ 发件人: [email protected] [[email protected]] 代表 Robert Raszuk [[email protected]] 发送时间: 2014年7月8日 17:06 收件人: Haoweiguo 抄送: [email protected] 主题: Re: 答复: 答复: Solicit reviews and comments on draft-hao-l3vpn-inter-nvo3-vpn-00 Hi Weiguo, > What's wrong with IP lookup per VPN on ASBR ? > > [weiguo]: This is a inter-as option between NVO3 and MPLS VPN > network. When traffic from internal NVO3 network is forwarded to > external MPLS VPN network, the ASBR(NVO3 Gateway) > terminates into a VRF and performs IP lookup, MPLS encapsulation > and then forwards the traffic to MPLS VPN network. This > mechanism is called Option-A in the draft. Then the draft is wrong as Option-A does not use any MPLS encapsulation. You are confusing on which side of ASBR VRFs sit. I am describing the model where ASBR is an option-B ASBR with in the same time integrated PE towards the DC side. There is no option A. Note also for clarity that packets are arriving at such PE from DC side not traditionally based on bounding to interface to a VRF but based on VN_ID bounding to a VRF. Some vendors call this "vrf select" mode. Sorry if this model/architecture was not clear in my former mail. > In extreme case, 16M VN/Tenants and several million end systems > need to be supported in a data center, inter-as option-A solution > has following drawbacks: I am not talking about option A so the following list does not apply. Moreover each solution needs to scale and I would not put any hard limit regardless what it is. So if particular box reaches its capacity you add another box to act as a gateway. That's it. > On ASBR1, VN ID is allocated per MPLS VPN Label received from peer > ASBR2 in MPLS VPN network. That is very inefficient and I would argue that architecturally wrong. This puts all the WAN churn and load towards all compute nodes which just does not belong there and brings no value. > If remote PE in MPLS VPN network allocates MPLS VPN Label per VPN, There is no such a thing. At best you can allocate a VPN label per PE per VRF, but this would require a lot of reconfiguration of the entire WAN L3VPN network which may not be welcome by number of providers. Best regards, R.
