[c-nsp] MPLS Multi-AS options...

[Kenny Sallee]

Hi Jimmi - thanks for sharing - some comments / questions inline below

On Mon, Nov 9, 2009 at 10:07 AM, jimmi <jimmi at netpoint.com.br> wrote:

>
> Folks.
>
> I read these papers long time ago, so I do not remember anymore exactly
> what
> this options labels (A, B, AB,...) definition means.
>

Quick recap for you:
Option A = back to back VRF's via sub-interfaces and BGP peering PER VRF
(lots of resources)
Option B = exchange of VPN-IPv4 addresses and agreement on RT's and label
switched path from ingress PE to egress PE routers
Option AB (aka option D as I've learned): VRF's and sub-interface per client
and a single eBGP session to carry VPN-IPv4 addresses



>
> What I can tell you guys is that I operate a network which has a Inter-AS
> peering were we exchange IPv4 & VPNv4 prefixes and traffic while
>  maintaining
> QoS services compability at both sides (ASs) for long time, and customers
> which VPNs have sites serviced by both ASs have their QoS requirements
> honored
> at both ASs Backbones and last mile connections.
>

Sounds like your are doing option B?


>
> I already had real "Inter-AS + QoS compatibility" experience with Cisco
> being
> the only platform, and where Cisco interoperate with (two) different
> vendors,
> and that worked just fine.
>

On your ASBR - do you have to create VRF's for every customer that crosses
the ASBR?  Do you mind sharing the relveant parts of your configuration
(sanitized of course) if possible?



>
> This deployment where you just had to establish a single eBGP peering at
> VPNv4
> address-family to exchange VPNv4 prefixes and traffic (of course you may
> exchange IPv4 also, and may establish redundant peerings) brings lots of
> benefits. It does not impact at your ASBR resources, reduces the number of
> connections between ASBRs & routing gets simplified, allows
> oversubscription
> between ASBRs, does not require your to act at the borders (ASBRs) each
> time a
> "site" is added or removed from a customer VPN (despite where this site is
> connected).
>

That's interesting actually - sounds pretty straight forward.  So far it
seems like some overseas operators are actually doing this or contemplating
doing it.  Anyone in the continental US researching and/or implemented (ing)
either of the options?

Kenny


>
>
>
>