Devil's Advocate - Segment Routing, Why?

adamv0025 at netconsultings.com adamv0025 at netconsultings.com
Sun Jun 21 19:15:05 UTC 2020


> From: NANOG <nanog-bounces at nanog.org> On Behalf Of Mark Tinka
> Sent: Friday, June 19, 2020 7:28 PM
> 
> 
> On 19/Jun/20 17:13, Robert Raszuk wrote:
> 
> >
> > So I think Ohta-san's point is about scalability services not flat
> > underlay RIB and FIB sizes. Many years ago we had requests to support
> > 5M L3VPN routes while underlay was just 500K IPv4.
> 
> Ah, if the context, then, was l3vpn scaling, yes, that is a known issue.
> 
I wouldn't say it's known to many as not many folks are actually limited by only up to ~1M customer connections, or next level up, only up to ~1M customer VPNs.   

> Apart from the global table vs. VRF parity concerns I've always had (one of
> which was illustrated earlier this week, on this list, with RPKI in a VRF),
>
Well yeah, things work differently in VRFs, not a big surprise.  
And what about an example of bad flowspec routes/filters cutting the boxes off net -where having those flowspec routes/filters contained within an Internet VRF would not have such an effect.
See, it goes either way.  
Would be interesting to see a comparison of good vs bad for the Internet routes in VRF vs in Internet routes in global/default routing table.


> the
> other reason I don't do Internet in a VRF is because it was always a trade-off:
> 
>     - More routes per VRF = fewer VRF's.
>     - More VRF's  = fewer routes per VRF.
> 
No, that's just a result of having a finite FIB/RIB size -if you want to cut these resources into virtual pieces you'll naturally get your equations above.
But if you actually construct your testing to showcase the delta between how much FIB/RIB space is taken by x prefixes with each in a VRF as opposed to all in a single default VRF (global routing table) the delta is negligible. 
(Yes negligible even in case of per prefix VPN label allocation method -which I'm assuming no one is using anyways as it inherently doesn't scale and would limit you to ~1M VPN prefixes though per-CE/per-next-hop VPN label allocation method gives one the same functionality as per-prefix one while pushing the limit to ~1M PE-CE links/IFLs which from my experience is sufficient for most folks out there). 
  
adam




More information about the NANOG mailing list