[c-nsp] ME3600 iBGP to RR

[Adam Vitkovsky]

Hi Aaron,

The whole trick where carrier's carrier routers don't need to know the customer's carrier routes is realised via seamless label switched path being built between the customer's carrier ASBRs.
As you can see that would require customers to enable MPLS on their routers.
So this model is/was used to provide service to MPLS providers the so called "customer carriers" so that they could extend their networks.
Nowadays however L2 E-LINE/E-LAN services are preferred in cases where customers or customer carriers for that matter wants/needs to be independent of carriers routing.
 
adam
> -----Original Message-----
> From: Aaron [mailto:aaron1 at gvtc.com]
> Sent: 06 March 2015 14:24
> To: 'CiscoNSP List'; mark.tinka at seacom.mu; Adam Vitkovsky; cisco-
> nsp at puck.nether.net
> Subject: RE: [c-nsp] ME3600 iBGP to RR
> 
> After I read this...
> 
> "Because how I would use this is just to get the full table to the customer
> hanging off of the ME."
> 
> ...i started wondering if CSC (carrier supporting carrier) for Customer
> Carrier (ISP type) would help here?
> 
> I recently tested CSC and look at it for the first time in my lab.  I
> understand that CSC for Customer Carrier ISP will allow a customer ce to
> hang off a backbone carrier pe and the customer carrier can learn all the
> bgp routes it wants to from a distant side customer carrier ce, AND the
> backbone carrier pe's do not learn those bgp routes.  So your PE's save
> memory and table space.
> 
> I'm not sure if this is what you are able to do or looking to do, but
> started to wonder if csc could help.
> 
> Aaron
> 
> 
> -----Original Message-----
> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> CiscoNSP List
> Sent: Friday, March 06, 2015 1:13 AM
> To: mark.tinka at seacom.mu; Adam Vitkovsky; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ME3600 iBGP to RR
> 
> Thanks for all the feedback/suggestions guys.
> 
> 
> > Date: Fri, 6 Mar 2015 07:35:10 +0200
> > From: mark.tinka at seacom.mu
> > To: Adam.Vitkovsky at gamma.co.uk; cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] ME3600 iBGP to RR
> >
> >
> >
> > On 5/Mar/15 19:12, Adam Vitkovsky wrote:
> > >
> > > Sorry, now I see I haven't made myself clear at all, I meant
> > > disconnected from VRFs perspective.
> > > Of course the box would have been reachable over OOB management
> > > network or via IGP.
> >
> > Of course :-).
> > >
> > >
> > > These are interesting numbers indeed.
> > > And I wanted to ask you for some time now what prefixes do you
> > > actually leak into the FIB to make any use of it.
> >
> > Internal iBGP routes, customer routes held in iBGP, some routes from
> > peers (they need to be in the FIB as we do some special things with
> > them
> > re: forwarding), 0/0 and ::/0.
> >
> > > Because how I would use this is just to get the full table to the
> > > customer hanging off of the ME.
> >
> > We hold everything else in RAM, and just hand it off to customers via
> > eBGP sessions.
> >
> > >
> > > Anyways the problem is 20K is not that much and can easily be
> > > exhausted with VPN customer prefixes in which case the SD can't
> > > really be used.
> > At any rate, BGP-SD is not supported for VPN address families.
> >
> > >
> > > You just need to make sure you never mess up the route-map used for
> SD.
> >
> > If you want to be simple, a simple "route-map BLAH deny 10" is all you
> > need to have nothing installed in the FIB.
> >
> > Otherwise, you can create a route-map similar to what you'd do for a
> > BGP routing policy to decide what enters the FIB. Nothing more special
> > than that.
> >
> > Mark.
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------