Hi Weiguo, You still missing it .. sorry. There is nothing centralized in my model.
As I said my model does not exist today - it is new proposal - so any attempts to map it to existing RFC will not be successful. I said on the picture that NVE is still there on the hosts (compute nodes) in the role of PE1. VRFs on PE2/ASBR are only for aggregation purposes. Moreover I thought this was obvious but solution I proposed is a superset .. it means ASBR for some VPNs can be just pure vanilla option B and for those which have a lot of prefixes can be enhanced with per VRF aggregation function based on the vrf select mode per VN_ID. Effectively what I am proposing in this long thread is to define few modes of VN_ID allocations (just like we have few modes of VPN label allocation on a classic PE). For some VPNs you may have VN-ID directly mapped to VPN label and for some where aggregation of VPN routes makes sense you map VN_ID to a local VRF. Thx, R. On Wed, Jul 9, 2014 at 9:27 AM, Haoweiguo <[email protected]> wrote: > Hi Robert, > Your illustration is very clear. Your model is centralized NVO3 gateway + > Inter-as Option-B, our model in the draft is distributed NVO3 gateway + > Inter-as Option-B. > Your model is very good and easy to be deployed, it will be a great > complementary to this solution. > In your model PE2 have all VRFs of the data center. For the traffic data > from NVO3 side to MPLS VPN side, VRF is selected based on VN ID. For the > traffic data from MPLS VPN side to NVO3 side, VRF is selected based on MPLS > VPN Label instead of sub-interface between ASBRs. > In our model , gateway is located on each NVE instead of on the PE2/ASBR, VRF > is located on each NVE, only VN ID and MPLS VPN Label switching table exists > on the ASBR, VRF don't need to be setup on the ASBR.It is more similar to > vanilla inter-as Option-B. > Thanks > weiguo > ________________________________________ > 发件人: [email protected] [[email protected]] 代表 Robert Raszuk > [[email protected]] > 发送时间: 2014年7月8日 20:56 > 收件人: Haoweiguo > 抄送: [email protected] > 主题: Re: 答复: 答复: 答复: Solicit reviews and comments on > draft-hao-l3vpn-inter-nvo3-vpn-00 > > Hi Weiguo, > >> In this email, your model are clearly described > > I don't think so based on your reply. Your interpretation is > completely unrelated to my model :) Sorry. > > Let me try to illustrate: > > Data Center > WAN > > VMs/namespaces > hypervisor + kernel (PE1) > compute node > | > | > --------------------- PE2/ASBR --- option B --- ASBR > ------------- PE3 > > > I am describing PE2/ASBR network element where you combine plain > option B with the VRF select based on VN_ID PE. > > DC can be operated by any provider so can WAN. Those are completely > not related to each other except agreement to establish L3VPN option B > peering session between corresponding ASBRs. > > PE2 is acting as WAN side aggregator on a per VRF basis. There is no > option A in this model anywhere. > > L3 VPN architecture does not provide such model hence perhaps you were > trying to map it to something which does not really exist in any RFC > document and this was the src of your confusion. > > I suggest if you want to build scalable interconnect between DC based > virtualized resources and arbitrary WAN you use this model. Of course > for completenss such mode must also provide independent access from > Internet either plain or over IPSec, but I assume this is obvious and > here we are only focusing on hybrid L3 VPN interconnect case. > > PE1 may be just a data plane or it could be also control plane and > data plane. The choice there is flexible. > > Hopefully with the picture this is more clear now. > > Regards, > R. > > > > On Tue, Jul 8, 2014 at 12:11 PM, Haoweiguo <[email protected]> wrote: >> >> 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.
