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.
