RE: Devil's Advocate - Segment Routing, Why?
From: NANOG <nanog-bounces@nanog.org> On Behalf Of Mark Tinka Sent: Wednesday, June 17, 2020 6:07 PM
I've heard a lot about "network programmability", e.t.c., 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.
but can anyone point me toward a solution that actually does this in the way that it has been touted for years? A true flow that shows the implementation of "network programming" over any incarnation of SR? Perhaps one a customer can go to the shop and grab off the shelf?
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).
I've heard about "end-to-end service chaining" as a use-case for SR. "service chaining" = traffic-engineering, you can do that with or without SR just fine.
To service-chain what? 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.
Classic telco's don't offer complex over-the-top services They do via telco cloud.
What problems are 90% of the operators running MPLS having that SR will truly fix,
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. adam
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.
On Wed, 17 Jun 2020 at 22:09, <adamv0025@netconsultings.com> wrote:
From: NANOG <nanog-bounces@nanog.org> On Behalf Of Mark Tinka Sent: Wednesday, June 17, 2020 6:07 PM
I've heard a lot about "network programmability", e.t.c., 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.
It works because SR != MPLS. SR is a protocol which describes many aspects, such as how traffic forwarding decisions made at the ingress node to a PSN can be guaranteed across the PSN, even though the nodes along the PSN path use per-hop forwarding behaviour and different nodes along the path have made different forwarding decisions. When using SR MPLS segment IDs are used as an index into the label range (SRGB) and so SIDs don't correlate 1:1 to MPLS labels, equally with SRv6 the segment IDs are encoded as IPv6 addresses and don't correlate 1:1 to an IPv6 address. There is a venn diagram with an overlapping section in the middle which is "generic SR" with a bunch of core features that are supported agnostic of the encoding mechanism. Cheers, James.
participants (3)
-
adamv0025ï¼ netconsultings.com -
James Bensley -
Mark Tinka