nanog mailing list archives

Re: Devil's Advocate - Segment Routing, Why?


From: Mark Tinka <mark.tinka () seacom mu>
Date: Sun, 21 Jun 2020 22:54:08 +0200



On 21/Jun/20 21:15, adamv0025 () netconsultings com wrote:

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.   

It's probably less of a problem now than it was 10 years ago. But, yes,
I don't have any real-world experience.



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.

Well, the global table is the basics, and VRF's is where sexy lives :-).


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). 

Like I said, with today's CPU's and memory, probably not an issue. But
it's not an area I play in, so those with more experience - like
yourself - would know better.

Mark.


Current thread: