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
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.
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.
SR as a replacement for LDP, but SR-LDP imterop is imteresting too. Do.you
have any experience with that?
Matt,
Just to clarify, Are you asking for SR and LDP interop or SR over LDP? Two
different things.
Thanks
Dip
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.
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.
+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.
> 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
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.
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 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.
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.
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.
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.
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.
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.
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.