[c-nsp] Internet in VRF

[Mark Tinka]

On 2/May/15 01:13, Jason Lixfeld wrote:

> I’ve been doing this for years on ME3600s, 7600s, A9Ks and A1Ks.  Except, I don’t separate my Internet customers into a different VRF than the Internet VRF.  Internet and all Internet customers are in the same VRF.  VOIP is in another VRF, IPTV in another, Management in another, etc.  Putting sub-sets of customers who require the same services inside different VRFs and having to leak between the two is more complexity than we need.  We don’t sell L3VPNs, so leaking between VRFs is never something I’ve had to worry much about.
>
> I do have one application where I need to leak between two VRFs on an A9K.  That is a royal pain in the ass which requires a loopback cable because IOS and XR by default inherit the next hop of the route when it’s leaked, instead of providing a knob to adjust this behaviour.
>
> Overall, I love the design.  It shrinks failure domains very nicely.  If someone fat fingers something in a VRF, it’s limited to that VRF and the global table is left completely intact.  Alternatively, with one huge routing table, one fat enough finger and you’re in quite the pickle.  Since everything is in a VRF, the global table is pretty much completely hands off except for device M-A-C events, but those are far less frequent than other config M-A-C events which happen inside these VRFs.  A stable global table means stable MPLS underpinnings.  Stable MPLS underpinnings mean stable EoMPLS/VPLS/NG-MVPN.

So we are now seeing LDPv6 spring up in IOS XR 5.3.0 - are you going to
start planning something similar for IPv6 routing/forwarding?

Generally, we use BGP communities, very extensively, to create the
necessary separation as demanded by the business and the network. Pretty
much everything we touch in BGP is community-driven, and that works very
well. Of course, this works well because we have the luxury of
discretely separating functions to specific devices in all the PoP's we
operate (which is essentially what VRF's or logical systems/SDR's do
anyway). So not an option for everyone, but one has to cost hardware as
well as operational complexity to find out what works for them. We went
the "other" route :-)...

Mark.