I'd like to hear about the platform limitations mentioned here as I've never ran into issues with label imposition limitations when implementing H-MPLS based solutions.
adam > -----Original Message----- > From: cisco-nsp [mailto:[email protected]] On Behalf Of > Phil Bedard > Sent: 02 May 2015 01:28 > To: Mike; [email protected] > Subject: Re: [c-nsp] Internet in VRF > > I think it’s a popular enough option these days in carrier networks that the > larger vendors do plan for it somewhat at this point. In the beginning there > were issues with how labels are allocated (per-VRF or per-prefix) which leads > to lots of potential issues. The ability for the box to look deep enough into > the packet as well to get good entropy for load balancing. If you are doing > something like seamless MPLS and carrying 3+ labels on a packet some gear > may have issues. You also may run into issues with not being able to impose > enough labels for something like FRR/backup tunnels on an ingress node. > Like I said though, there are some large carriers doing this today so vendors > have solved most of those issues by now. > > I wouldn’t get crazy with route leaking, if you want to carry Internet in a > VRF, > just carry Internet in a VRF and not separate things into a bunch of different > ones. It always comes down to what problem are you really trying to solve. > > > Phil > > > > -----Original Message----- > From: Mike > Date: Friday, May 1, 2015 at 16:43 > To: "[email protected]" > Subject: Re: [c-nsp] Internet in VRF > > >===================================================== > >On 05/01/2015 12:00 PM, Mark Tinka wrote: > >> > >> On 30/Apr/15 18:41, Mike wrote: > >>> Hi, > >>> > >>> I'd like to ask for the collective opinion on routing in service > >>> provider network serving broadband subscribers: > >>> > >>> I have an ASR1k and will be terminating PPPoE broadband > >>> subscribers here. I'll also be terminating my primay internet feed > >>> (BGP) here, and I the future I will have 3 providers and will be > >>> multihomed. I also will have some MPLS vpns for certain customers. > >>> > >>> I think I want to have my default routing table carry mostly > >>> loopbacks and direct interface connected routes, while I want to stuff > >>> everything else into VRF's. Those other VRF's are likely to be > >>> Internet (full tables), Subscribers (all the /32's for PPPoE > >>> subscribers), and the odd vrf for any mpls vpn customers. The > >>> challenge is that - I think - I would want to only leak a default > >>> route into any other non-Internet VRF that requires shared service > >>> access to it, which should keep the table sizes down. My question is, > >>> does this sound reasonable? Is there any reason I wouldn't want to set > >>> things up this way? > >> I like simple. > >> > >> Internet routes in a VRF is not simple - too dependent on hardware and > >> software capabilities, without having to worry about what the vendors do > >> with the hardware or the software in future revisions. > >> > >> I know a few ISP's that went this router back in 2003, when MPLS was > >> all-the-rage; they're finding that tearing down this wall of complexity > >> is the way forward, but alas, mighty painful. > >> > > > >What exactly are the downsides? I don't have 100's of routers and > >transits and peerings and such, but if I'm going to be painting myself > >into a corner I'd like to know about it before it do it. > > > >Thank you. > > > >_______________________________________________ > >cisco-nsp mailing list [email protected] > >https://puck.nether.net/mailman/listinfo/cisco-nsp > >archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ > cisco-nsp mailing list [email protected] > 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 --------------------------------------------------------------------------------------- _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
