On 17/Jun/20 23:07, adamv0...@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.
