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 <[email protected]> To: jimmi <[email protected]> Cc: [email protected], [email protected] 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 <[email protected]> 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 ------- _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
