On Fri, Jul 23, 2010 at 9:45 AM, Vitkovsky, Adam <avitkovsky@emea.att.com>wrote:
Yes please -option d also known as option AB -it's the same as option b with addition of VRFs on the ASBRs -it might as well be viewed as a natural step between opt a and opt b
-opt ab offers the same great control over the routes advertised between ASes as opt a -though provides for better scalability by introducing mp-ebgp session between ASBRs
By removing the VRFs from the ASBRs and turning off the default mp-ibgp behavior -option b doesn't suffer from some of the inherent drawbacks of opt ab like: Increased memory demands because ASBRs have to store routes in the per-vrf RIBs in addition to mp-bgp database Opt b has also streamlined the forwarding process by omitting the additional per-vrf ip lookup on the ASBRs The tradeoff is however -less control over the routes advertised between the AS domains
One advantage that comes naturally with opt ab is -you don't need to worry about the import/export RTs not matching in two different ASes and configuring RT rewrites on ASBRs -opt ab will take care of that for you
FWIW - I tried to get a couple of larger carriers in the states to do option b with my company (we are an ASP) - where we were the other 'ISP/AS'. Doing so would have allowed me to extend the VRF / VPN-ipV4 addresses to my core and map those to a VLAN interface in the same VRF (thus allowing all of our customers to maintain their own IP ranges instead of us handing out non-overlapping ranges). None of them would do it for security / manageability reasons. The solution today is back to back DS3 with frame encapsulation and a gazillion sub-interfaces (each sub-interface is in a VRF - and each VRF can have a VLAN interface for L2 and L3 autonomy). It solves my problem - but the config is a little complicated. So for me - it'd be nice if the carriers played in the Multi-AS backbone arena a little more. I could loose frame encapsulation and the management/scalability issues that goes along with a ton of sub-if's. It'd be easier on their provisioning teams as well. Not to mention a simplified QoS config etc... Another practical use for multi-as MPLS VPN options: if there were 2 providers that used RFC 4364 Multi-AS options - I could provide carrier / circuit redundancy into my data centers. Today I can only do that via a single MPLS provider and hope the core engineers of that carrier don't make mistakes...If I could have an MPLS circuit dropped from 2 different providers that provide access between our customers and our data centers - there'd be a lot of value there. I'm sure a lot of enterprises using MPLS would be interested. Kenny