Devil's Advocate - Segment Routing, Why?
mark.tinka at seacom.mu
Wed Jun 17 22:23:22 UTC 2020
On 17/Jun/20 23:07, adamv0025 at netconsultings.com wrote:
> First of all the "SR = network programmability" is BS, SR = MPLS, any
> programmability we've had for MPLS since ever works the same way for SR.
I see it the same way.
> Yes anything that works for RSVP-TE (i.e. PCEP), if you want to play there's this free app on top of ODL(acting as PCEP+BGP-LS) to program LSPs (can't recall the name).
In short, more working and not the panacea it was made out to be. No
problem with that, if you're one to roll your sleeves up.
> "service chaining" = traffic-engineering, you can do that with or without SR just fine.
I don't make the terms up... best-of-breed and all that :-).
> To service-chain DC or as hipsters call it "cloud" stuff. To TE path from VM to FW to ...whatever, or to TE mice flows around elephant flows.
And how many classic telco's are doing this at scale in a way that only
SR can solve?
> They do via telco cloud.
What's that :-)?
> The same point I was trying to get across in our LDPv6 (or any v6 in control-plane or management plane for that matter) discussion, there's no problem to solve.
> Personally I'll be doing SR only in brand new greenfield deployments or if I start running out of RSVP-TE scale on existing deployments.
If I want to remove BGP state in the core (which is a good thing, given
how heavy BGP code and FIB requirements are), LDPv4 and LDPv6 are useful
for native dual-stack networks that do not share fate between either IP
But, YMMV on that one :-).
More information about the NANOG