[c-nsp] Internet in VRF

[Adam Vitkovsky]

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:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Phil Bedard
> Sent: 02 May 2015 01:28
> To: Mike; cisco-nsp at puck.nether.net
> 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: "cisco-nsp at puck.nether.net"
> 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  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
---------------------------------------------------------------------------------------