Hello maillist anyone had any experience with segment routing and its performance over LDP? We are evaluating the option to move to SR over LDP so we can label switch across our Nexus L3 switching environment. Thanks Packet Plumber
Matt, Just to clarify, Are you asking for SR and LDP interop or SR over LDP? Two different things. Thanks Dip On Fri, May 18, 2018 at 3:11 AM, Matt Geary <matt.geary@gmail.com> wrote:
Hello maillist anyone had any experience with segment routing and its performance over LDP? We are evaluating the option to move to SR over LDP so we can label switch across our Nexus L3 switching environment.
Thanks Packet Plumber
-- Sent from iPhone
SR as a replacement for LDP, but SR-LDP imterop is imteresting too. Do.you have any experience with that? On May 22, 2018 02:59, "dip" <diptanshu.singh@gmail.com> wrote: Matt, Just to clarify, Are you asking for SR and LDP interop or SR over LDP? Two different things. Thanks Dip On Fri, May 18, 2018 at 3:11 AM, Matt Geary <matt.geary@gmail.com> wrote:
Hello maillist anyone had any experience with segment routing and its performance over LDP? We are evaluating the option to move to SR over LDP so we can label switch across our Nexus L3 switching environment.
Thanks Packet Plumber
-- Sent from iPhone
On 18/May/18 12:11, Matt Geary wrote:
Hello maillist anyone had any experience with segment routing and its performance over LDP? We are evaluating the option to move to SR over LDP so we can label switch across our Nexus L3 switching environment.
Is your use-case because you need label switching and the Nexus does not support LDP? Mark.
Yes we are considering changing to SR on our backbone because LDP is not supported on the nexus switches. Although, we have no experience with SR and looks plainly simple but we loose some of the LSP path selection. On Tue, May 22, 2018, 10:05 Mark Tinka <mark.tinka@seacom.mu> wrote:
On 18/May/18 12:11, Matt Geary wrote:
Hello maillist anyone had any experience with segment routing and its performance over LDP? We are evaluating the option to move to SR over LDP so we can label switch across our Nexus L3 switching environment.
Is your use-case because you need label switching and the Nexus does not support LDP?
Mark.
On 22/May/18 10:06, Matt Geary wrote:
Yes we are considering changing to SR on our backbone because LDP is not supported on the nexus switches. Although, we have no experience with SR and looks plainly simple but we loose some of the LSP path selection.
Got you. I'm more curious about use-cases for folk considering SR, than SR itself. 4 years on, and I still can't find a reason to replace my LDP network with SR. Your use-case makes sense, as it sounds like Cisco deliberately left LDP out of your box, considering SR is in. But that's a whole other discussion :-)... Mark.
Yeah Cisco rep commented that adding LDP to nexus would make ASR obsolete. 48x10g with LDP for $5-7k Yeah no brainer. Although on other point I am not really seeing the value of SR to replace LDP on my backbone. With some scripting and lots of software tools I can make it just like LDP, but why? So break the ease of LDP just to get label switching on my hub core not really seeing it, unless someone has done it and they are seeing the value. On Tue, May 22, 2018, 10:14 Mark Tinka <mark.tinka@seacom.mu> wrote:
On 22/May/18 10:06, Matt Geary wrote:
Yes we are considering changing to SR on our backbone because LDP is not supported on the nexus switches. Although, we have no experience with SR and looks plainly simple but we loose some of the LSP path selection.
Got you.
I'm more curious about use-cases for folk considering SR, than SR itself.
4 years on, and I still can't find a reason to replace my LDP network with SR.
Your use-case makes sense, as it sounds like Cisco deliberately left LDP out of your box, considering SR is in. But that's a whole other discussion :-)...
Mark.
On 22/May/18 10:19, Matt Geary wrote:
Yeah Cisco rep commented that adding LDP to nexus would make ASR obsolete. 48x10g with LDP for $5-7k Yeah no brainer.
Gee, someone at Cisco had their thinking cap on. Let's hope Gert isn't reading this, lest he vent-off about the 6500/7600 debacle (and rightly so) :-). Seriously though, crippling one box to help ship another has never sat well with me. In the first instance, what business does a switch have being a label switching router? Maybe I'm too purist, but when functions begin to overlap like this, it's headache for operators and multiple sources of revenue for equipment vendors, despite what their "portfolio positioning" suggests. They are very aware about the confusion they are causing, at our expense. At least there are some new entrants into the space that haven't yet been totally corrupted by the silo-based approach that leads to the same company appearing like 1,200 different ones.
Although on other point I am not really seeing the value of SR to replace LDP on my backbone. With some scripting and lots of software tools I can make it just like LDP, but why? So break the ease of LDP just to get label switching on my hub core not really seeing it, unless someone has done it and they are seeing the value.
Yep, my point exactly. Mark.
On 22 May 2018 at 11:19, Matt Geary <matt.geary@gmail.com> wrote:
really seeing the value of SR to replace LDP on my backbone. With some scripting and lots of software tools I can make it just like LDP, but why? So break the ease of LDP just to get label switching on my hub core not really seeing it, unless someone has done it and they are seeing the value.
Can you elaborate what scripting and software tools are needed? If you'd talk about RSVP particularly AutoBW and SR, then yeah, but SR on itself should be less of a chore than LDP. SR is what MPLS was intended to be day1, it just wasn't very marketable idea to sell MPLS and sell need for changing all the IGPs as well. LDP is added state, added signalling, added complexity with reduced visibility. SR is like full-mesh LDP (everyone has everyone's label POV), while also removing one protocol entirely. -- ++ytti
fwiw - there's a potentially significant loss of visibility w/SR from a traffic management perspective depending on how it's deployed. though, i doubt the OP is really driving at this point. the data plane behavior on LDP is swap oriented, while the data plane on SR is pop oriented. depending on the hardware capabilities in use this may have (subtle) traffic engineering or diagnostic implications at a minimum. folks will likely have to build tooling to address this. we're pushing the bubble of complexity around. On Tue, May 22, 2018 at 8:47 AM Saku Ytti <saku@ytti.fi> wrote:
On 22 May 2018 at 11:19, Matt Geary <matt.geary@gmail.com> wrote:
really seeing the value of SR to replace LDP on my backbone. With some scripting and lots of software tools I can make it just like LDP, but why? So break the ease of LDP just to get label switching on my hub core not really seeing it, unless someone has done it and they are seeing the value.
Can you elaborate what scripting and software tools are needed? If you'd talk about RSVP particularly AutoBW and SR, then yeah, but SR on itself should be less of a chore than LDP.
SR is what MPLS was intended to be day1, it just wasn't very marketable idea to sell MPLS and sell need for changing all the IGPs as well. LDP is added state, added signalling, added complexity with reduced visibility. SR is like full-mesh LDP (everyone has everyone's label POV), while also removing one protocol entirely.
-- ++ytti
-- steve ulrich (sulrich@botwerks.*)
Hey Steve,
the data plane behavior on LDP is swap oriented, while the data plane on SR is pop oriented. depending on the hardware capabilities in use this may have (subtle) traffic engineering or diagnostic implications at a minimum. folks will likely have to build tooling to address this.
I think you're thinking of SR-TE, SR in normal LDP-like use case would be single egress label with swap on LSRs. Ingress PE would figure out label by using egress PE index as an offset to next-hop P's label range. Nexthop P would swap the label determining out label using same mechanism. I practice operators would configure same label range in every box, so swap would be from same label to same label. But that is purely due to operator configuration, and it's still swap. -- ++ytti
sorry, yes. i was referring to SRTE wrt the pop operation. in most of the implementations i've poked at, there is the ability to specify a consistent label range, but it's not always the case. SIDs are not labels but they are encoded as labels. i hope operators have the option to configure common/consistent label ranges, but i don't necessarily assume it. tooling to resolve this will be required just as in the LDP world. On Tue, May 22, 2018 at 9:19 AM Saku Ytti <saku@ytti.fi> wrote:
Hey Steve,
the data plane behavior on LDP is swap oriented, while the data plane on SR is pop oriented. depending on the hardware capabilities in use this may have (subtle) traffic engineering or diagnostic implications at a minimum. folks will likely have to build tooling to address this.
I think you're thinking of SR-TE, SR in normal LDP-like use case would be single egress label with swap on LSRs.
Ingress PE would figure out label by using egress PE index as an offset to next-hop P's label range. Nexthop P would swap the label determining out label using same mechanism.
I practice operators would configure same label range in every box, so swap would be from same label to same label. But that is purely due to operator configuration, and it's still swap.
-- ++ytti
-- steve ulrich (sulrich@botwerks.*)
On 22 May 2018 at 17:43, steve ulrich <sulrich@botwerks.org> wrote: Hey,
sorry, yes. i was referring to SRTE wrt the pop operation.
Yup RSVP=>SR is more ambiguous and debatable than LDP=>SR which is unambiguous win.
not labels but they are encoded as labels. i hope operators have the option to configure common/consistent label ranges, but i don't necessarily assume it. tooling to resolve this will be required just as in the LDP world.
I've not had this tooling in LDP world, and not anticipating to need it in SR world. But maybe I'm missing something, what kind of information do you need in LDP world which you need to develop tooling for, and how does the problem+solution translate to SR world? -- ++ytti
On Tue, May 22, 2018 at 9:59 AM Saku Ytti <saku@ytti.fi> wrote:
On 22 May 2018 at 17:43, steve ulrich <sulrich@botwerks.org> wrote:
Hey,
sorry, yes. i was referring to SRTE wrt the pop operation.
Yup RSVP=>SR is more ambiguous and debatable than LDP=>SR which is unambiguous win.
not labels but they are encoded as labels. i hope operators have the option to configure common/consistent label ranges, but i don't necessarily assume it. tooling to resolve this will be required just as in the LDP world.
I've not had this tooling in LDP world, and not anticipating to need it in SR world. But maybe I'm missing something, what kind of information do you need in LDP world which you need to develop tooling for, and how does the problem+solution translate to SR world?
in the day's of yore, i know a few folks who built tooling to validate and/or detect failure to sync between the IGP and LDP or detect data plane black holing behaviors caused by resolution in the RIB w/no complementary label allocation (or LDP convergence lagging significantly). implementations have come a long way since then. but yeah, IGP-LDP sync lag has been a thing for some folks. in a world of anycast/prefix-SIDs some of this doesn't necessarily go away, it just looks kind of different. though to be fair, this alignment improves (the IGP/LDP convergence sync case goes away) for all the reasons you've cited previously in this thread. -- steve ulrich (sulrich@botwerks.*)
in the day's of yore, i know a few folks who built tooling to validate and/or detect failure to sync between the IGP and LDP or detect data plane black holing behaviors caused by resolution in the RIB w/no complementary label allocation (or LDP convergence lagging significantly). implementations have come a long way since then. but yeah, IGP-LDP sync lag has been a thing for some folks.
No matter what the protocol, there will be occasional bugs, and we will continue to develop ad-hoc scripts to detect and workaround those when possible until such time that software upgrade is practical. None of these are practical to write ahead of time, as we won't know what the bug is we're trying to detect. This is not protocol discussion in itself, but we can make an argument that if there is bug probability per SLOC, less SLOC is less bugs, and label signalling in IGP is far simpler than LDP. -- ++ytti
I guess my point is why go through the extra config to program labels for each box when LDP does it for you? Why loose potential visibility to network traffic? Cisco sales and marketing is digging huge into the SR game for enterprise and SDWAN like backbone networking. They are touting about the whole industry changing, but I'm not seeing it anywhere in the large network or provider space. Hench my original question why SR over LDP? Seems SR is a lot of extra config to give you all the program options for white box like networking, when basic LDP in a Cisco variant works just fine. On Tue, May 22, 2018, 16:19 Saku Ytti <saku@ytti.fi> wrote:
Hey Steve,
the data plane behavior on LDP is swap oriented, while the data plane on SR is pop oriented. depending on the hardware capabilities in use this may have (subtle) traffic engineering or diagnostic implications at a minimum. folks will likely have to build tooling to address this.
I think you're thinking of SR-TE, SR in normal LDP-like use case would be single egress label with swap on LSRs.
Ingress PE would figure out label by using egress PE index as an offset to next-hop P's label range. Nexthop P would swap the label determining out label using same mechanism.
I practice operators would configure same label range in every box, so swap would be from same label to same label. But that is purely due to operator configuration, and it's still swap.
-- ++ytti
Hey Matt,
I guess my point is why go through the extra config to program labels for each box when LDP does it for you? Why loose potential visibility to network traffic? Cisco sales and marketing is digging huge into the SR game for enterprise and SDWAN like backbone networking. They are touting about the whole industry changing, but I'm not seeing it anywhere in the large network or provider space. Hench my original question why SR over LDP? Seems SR is a lot of extra config to give you all the program options for white box like networking, when basic LDP in a Cisco variant works just fine.
There isn't inherently anything you need to configure in SR, it's all implementation detail. Juniper requires you configure your 'index', but just as well 'index' could be inferred from your loopback0 or router-id. And indeed in your configuration generation where you generate your router-id, you can use static method to turn router-id into unique index and configure it once. Or you could ask vendor to implement feature to auto-assign index. Much like some devices can auto-assign unique RD to VRF, some require operator to assign them. Entirely implementation detail, not a valid argument between protocols. The upside of SR to LDP - removal of entire protocol - full-mesh visibility - guaranteed IGP+Label sync The amount of configuration needed to do SR like LDP should be less than LDP. Confusion may arise by looking at SR examples, as SR can also be used like RSVP, which indeed is far more complex use-case. -- ++ytti
Hi Saku gotcha and I see most config examples are RSVP/SR-TE like, where in most of the networks I have come across basic LDP is more than acceptable. On Tue, May 22, 2018, 17:48 Saku Ytti <saku@ytti.fi> wrote:
Hey Matt,
I guess my point is why go through the extra config to program labels for each box when LDP does it for you? Why loose potential visibility to network traffic? Cisco sales and marketing is digging huge into the SR game for enterprise and SDWAN like backbone networking. They are touting about the whole industry changing, but I'm not seeing it anywhere in the large network or provider space. Hench my original question why SR over LDP? Seems SR is a lot of extra config to give you all the program options for white box like networking, when basic LDP in a Cisco variant works just fine.
There isn't inherently anything you need to configure in SR, it's all implementation detail. Juniper requires you configure your 'index', but just as well 'index' could be inferred from your loopback0 or router-id.
And indeed in your configuration generation where you generate your router-id, you can use static method to turn router-id into unique index and configure it once. Or you could ask vendor to implement feature to auto-assign index.
Much like some devices can auto-assign unique RD to VRF, some require operator to assign them. Entirely implementation detail, not a valid argument between protocols.
The upside of SR to LDP - removal of entire protocol - full-mesh visibility - guaranteed IGP+Label sync
The amount of configuration needed to do SR like LDP should be less than LDP. Confusion may arise by looking at SR examples, as SR can also be used like RSVP, which indeed is far more complex use-case.
-- ++ytti
On 5/22/18 7:04 AM, steve ulrich wrote:
fwiw - there's a potentially significant loss of visibility w/SR from a traffic management perspective depending on how it's deployed. though, i doubt the OP is really driving at this point.
the data plane behavior on LDP is swap oriented, while the data plane on SR is pop oriented. depending on the hardware capabilities in use this may have (subtle) traffic engineering or diagnostic implications at a minimum. folks will likely have to build tooling to address this.
we're pushing the bubble of complexity around.
Moving the complexity to where it scales better is a win all by itself.
On Tue, May 22, 2018 at 8:47 AM Saku Ytti <saku@ytti.fi> wrote:
On 22 May 2018 at 11:19, Matt Geary <matt.geary@gmail.com> wrote:
really seeing the value of SR to replace LDP on my backbone. With some scripting and lots of software tools I can make it just like LDP, but why? So break the ease of LDP just to get label switching on my hub core not really seeing it, unless someone has done it and they are seeing the value.
Can you elaborate what scripting and software tools are needed? If you'd talk about RSVP particularly AutoBW and SR, then yeah, but SR on itself should be less of a chore than LDP.
SR is what MPLS was intended to be day1, it just wasn't very marketable idea to sell MPLS and sell need for changing all the IGPs as well. LDP is added state, added signalling, added complexity with reduced visibility. SR is like full-mesh LDP (everyone has everyone's label POV), while also removing one protocol entirely.
-- ++ytti
On 22 May 2018 at 09:14, Mark Tinka <mark.tinka@seacom.mu> wrote:
I'm more curious about use-cases for folk considering SR, than SR itself.
4 years on, and I still can't find a reason to replace my LDP network with SR.
Your use-case makes sense, as it sounds like Cisco deliberately left LDP out of your box, considering SR is in. But that's a whole other discussion :-)...
I'm also interested in the uses cases. As a "typical" service provider (whatever that means) who doesn't have any SR specific requirements such as service chaining, the only reason/feature SR has which currently makes me want to deploy it is TI-FLA (to improve our (r)LFA coverage) - but this is only for failure scenarios so under normal working conditions as far as I know, there is no benefit available to us right now. Cheers, James.
On 22/May/18 10:51, James Bensley wrote:
I'm also interested in the uses cases.
As a "typical" service provider (whatever that means) who doesn't have any SR specific requirements such as service chaining, the only reason/feature SR has which currently makes me want to deploy it is TI-FLA (to improve our (r)LFA coverage) - but this is only for failure scenarios so under normal working conditions as far as I know, there is no benefit available to us right now.
+1. I was excited about SR because I thought it would finally enable native MPLSv6 forwarding. But alas... I've heard of "quiet" tests going on within some operator networks, but if you look around, SR is being pushed by the vendors, and none of them can give me a concrete example of a deployment in the wild worth talking about. Of course, always open to correction... Mark.
On Tue, May 22, 2018 at 2:39 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 22/May/18 10:51, James Bensley wrote:
I'm also interested in the uses cases.
As a "typical" service provider (whatever that means) who doesn't have any SR specific requirements such as service chaining, the only reason/feature SR has which currently makes me want to deploy it is TI-FLA (to improve our (r)LFA coverage) - but this is only for failure scenarios so under normal working conditions as far as I know, there is no benefit available to us right now.
+1.
I was excited about SR because I thought it would finally enable native MPLSv6 forwarding. But alas...
I've heard of "quiet" tests going on within some operator networks, but if you look around, SR is being pushed by the vendors, and none of them can give me a concrete example of a deployment in the wild worth talking about.
Of course, always open to correction...
Well look at how many authors are on this rfc, that means it is super good right? More authors, more brains https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07 Actually it is just an embarasssing marketing technique. Sad!
Mark.
On 22/May/18 14:10, Ca By wrote:
Well look at how many authors are on this rfc, that means it is super good right? More authors, more brains
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07
Actually it is just an embarasssing marketing technique. Sad!
Let's hope it doesn't suffer the same fate as LDPv6 did, whose implementation across all platforms within one specific vendor is very poor, meaning you can't really use it in real life, never mind a multi-vendor network. Mark.
On 22 May 2018 at 12:36, Mark Tinka <mark.tinka@seacom.mu> wrote:
I was excited about SR because I thought it would finally enable native MPLSv6 forwarding. But alas...
Why 'alas'? In ISIS you're free to signal Prefix-SID on IPv4 or IPv6, there isn't anything inherently IPv4 in the standard. -- ++ytti
On 22/May/18 15:38, Saku Ytti wrote:
Why 'alas'? In ISIS you're free to signal Prefix-SID on IPv4 or IPv6, there isn't anything inherently IPv4 in the standard.
Can I use that to create MPLS LSP's to carry IPv6 traffic over an IPv6 next-hop, like LDPv6 has been designed to, i.e., not need for IPv4 in any way to forward MPLS frames carrying an IPv6 payload? Don't remember that being the case the last time I checked, but things could have moved on since then. Mark.
Hey Mark,
Can I use that to create MPLS LSP's to carry IPv6 traffic over an IPv6 next-hop, like LDPv6 has been designed to, i.e., not need for IPv4 in any way to forward MPLS frames carrying an IPv6 payload?
Yes. In ISIS you'd use Prefix-SID sTLV and attach it to TLV-236 (IPv6) or TLV-237 (Multitopo IPv6). The standard itself has not had any IPv4 bias, IPv6 has had first class support since first draft. -- ++ytti
On 22/May/18 16:14, Saku Ytti wrote:
Yes. In ISIS you'd use Prefix-SID sTLV and attach it to TLV-236 (IPv6) or TLV-237 (Multitopo IPv6).
The standard itself has not had any IPv4 bias, IPv6 has had first class support since first draft.
Have you seen an actual deployment in the field, forwarding IPv6 traffic inside MPLS? My use-case would be to remove BGPv6 in the core, the same way I removed BGPv4 from the core back in 2008. I know LDPv6 can do this, but support across multiple platforms is not where it needs to be yet, making network-wide deployment impractical. Mark.
On 22 May 2018 at 17:17, Mark Tinka <mark.tinka@seacom.mu> wrote:
Have you seen an actual deployment in the field, forwarding IPv6 traffic inside MPLS? My use-case would be to remove BGPv6 in the core, the same way I removed BGPv4 from the core back in 2008.
I have not, but I'm not good source as I don't track this. I'm just pointing out that LDP was/is IPv4 protocol, where as SR IGP extensions are from day1 IPv4+IPv6 with no particular bias. -- ++ytti
On 22/May/18 16:21, Saku Ytti wrote:
I have not, but I'm not good source as I don't track this.
This is what I'm struggling to find, as for me, this would be the ideal use-case for SR.
I'm just pointing out that LDP was/is IPv4 protocol, where as SR IGP extensions are from day1 IPv4+IPv6 with no particular bias.
RFC7552 has been shipping since 2015, and this I know works well. If it wasn't for Cisco's spotty support in the various platforms in their portfolio, I'd have taken BGPv6 out of my core ages ago, as Juniper (our other vendor) has had LDPv6 support for quite a while now. Mark.
On 22 May 2018 at 17:29, Mark Tinka <mark.tinka@seacom.mu> wrote:
This is what I'm struggling to find, as for me, this would be the ideal use-case for SR.
My first google hit shows IPv6 support: https://www.juniper.net/documentation/en_US/junos/topics/example/example-con... I think there may be some confusing with MPLS and IPv6 dataplane carrying IPv4/IPv6. MPLS dataplane seems to support in JunOS both IPv4 and IPV6 labeled prefixes. IPv6 dataplane I could not be less interested in, I think it's trash. -- ++ytti
On 22/May/18 16:35, Saku Ytti wrote:
My first google hit shows IPv6 support:
https://www.juniper.net/documentation/en_US/junos/topics/example/example-con...
I meant as a field deployment in an operator network, and not what documentation says code can do.
I think there may be some confusing with MPLS and IPv6 dataplane carrying IPv4/IPv6. MPLS dataplane seems to support in JunOS both IPv4 and IPV6 labeled prefixes. IPv6 dataplane I could not be less interested in, I think it's trash.
Well, I want to forward IPv6 traffic in an MPLS data plane, the same way I am currently forwarding IPv4 and Ethernet traffic in an MPLS data plane. And I want to do this as ships-in-the-night to avoid shared risk by combining 2 protocols into one (the way 6PE depends on IPv4, for example). If IPv6 traffic is being forwarded in the core purely on labels (generated purely either by LDPv6 or SRv6, and not by 6PE-and-friends-type sorcery), then I can disable BGPv6 in the core. Mark.
participants (8)
-
Ca By -
dip -
James Bensley -
Mark Tinka -
Matt Geary -
Saku Ytti -
Scott Whyte -
steve ulrich