"vpn exchange point"

Fri Jul 23 17:07:43 UTC 2010

On Fri, Jul 23, 2010 at 9:45 AM, Vitkovsky, Adam <avitkovsky at 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