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

[jimmi]

Kenny, Mark, and who else are interesting on this matter.

It will be a pleasure to discuss and share information regarding it, 
but if you don't mind I rather doing it private, without coping the 
whole list. 

Just let me know how else are interesting.

---------- Original Message -----------
From: Kenny Sallee <kenny.sallee at gmail.com>
To: jimmi <jimmi at netpoint.com.br>
Cc: mtinka at globaltransit.net, cisco-nsp at puck.nether.net
Sent: Mon, 9 Nov 2009 13:57:19 -0800
Subject: Re: [c-nsp] MPLS Multi-AS options...

> 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
> 
> >
> >
> >
> >
------- End of Original Message -------