On 17/Jun/20 23:07, adamv0025@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 :-)?
None, 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 protocol. But, YMMV on that one :-). Mark.