Re: Segment Routing

[steve ulrich]

On Tue, May 22, 2018 at 9:59 AM Saku Ytti  wrote:

> On 22 May 2018 at 17:43, steve ulrich  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.*)

Re: Segment Routing

[Saku Ytti]

> 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

Re: Segment Routing

[Scott Whyte]

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  wrote:


On 22 May 2018 at 11:19, Matt Geary  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

Re: Segment Routing

[steve ulrich]

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  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.*)

Re: Segment Routing

[steve ulrich]

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  wrote:

> On 22 May 2018 at 11:19, Matt Geary  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.*)

RE: Segment Routing

[Jakob Heitz (jheitz)]

Nexus supports LDP.

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/mpls/configuration/guide/mpls_cg/mp_ldp_overview.html


Regards,
Jakob

Re: Segment Routing

[Matt Geary]

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  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
>

Re: Segment Routing

[Saku 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

Re: Segment Routing

[Matt Geary]

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  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
>

Re: Segment Routing

[Saku Ytti]

On 22 May 2018 at 17:43, steve ulrich  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

Re: Segment Routing

[Mark Tinka]

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-configuring-spring-srgb.html

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.

Re: Segment Routing

[Saku Ytti]

On 22 May 2018 at 17:29, Mark Tinka  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-configuring-spring-srgb.html

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

Re: Segment Routing

[Mark Tinka]

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.

Re: Segment Routing

[Saku Ytti]

On 22 May 2018 at 17:17, Mark Tinka  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

Re: Segment Routing

[Saku Ytti]

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

Re: Segment Routing

[Mark Tinka]

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.

Re: Segment Routing

[Saku Ytti]

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

Re: Segment Routing

[Mark Tinka]

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.

Re: Segment Routing

[Saku Ytti]

On 22 May 2018 at 11:19, Matt Geary  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

Re: Segment Routing

[Saku Ytti]

On 22 May 2018 at 12:36, Mark Tinka  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

Re: Segment Routing

[Matt Geary]

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"  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  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

Re: Segment Routing

[Matt Geary]

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  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.
>

Re: Segment Routing

[Matt Geary]

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  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.
>

Re: Segment Routing

[Mark Tinka]

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.

Re: Segment Routing

[Ca By]

On Tue, May 22, 2018 at 2:39 AM Mark Tinka  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.
>

Re: Segment Routing

[Mark Tinka]

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.

Re: Segment Routing

[Mark Tinka]

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.

Re: Segment Routing

[James Bensley]

On 22 May 2018 at 09:14, Mark Tinka  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.

Re: Segment Routing

[Mark Tinka]

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.

Re: Segment Routing

[Mark Tinka]

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.

Re: Segment Routing

[dip]

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  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

Re: Segment Routing for L2VPN?

[Anoop Ghanwani]

It depends on what type of L2VPN we are talking about.

If we are talking about VPLS (where we learn from the data path) changes
are needed in order to make it work with segment routing.  Basically, the
VC label must be assigned and used in such a way that it indicates not only
the service for the packet, but also the PE from which it originated.  That
is because with SR, we would have lost the path (PW) that the packet used
to get to the destination PE.

If we are talking about BGP E-VPN where data path learning is not used,
then it should work with segment routing without any changes.

Anoop

On Mon, Sep 21, 2015 at 11:32 AM, Jeff Tantsura <jeff.tants...@ericsson.com>
wrote:

> Hi,
>
> In most well designed IP routing stacks the way to get to a labeled
> (tunneled) next hop is decoupled from a service, so if a service requires
> such next hop it is upto (usually RIB) to return one (best, multiple might
> exist) which would be used for forwarding. If it is a Segment Routed one
> so it will then be used.
>
> Cheers,
> Jeff
>
> -Original Message-
> From: Mohan Nanduri <mohan.nand...@gmail.com>
> Date: Sunday, September 20, 2015 at 12:59 PM
> To: Jason Lixfeld <ja...@lixfeld.ca>
> Cc: "nanog@nanog.org" <nanog@nanog.org>
> Subject: Re: Segment Routing for L2VPN?
>
> >No, it works with L2VPNs also. Outer label is going to be SR label and
> >inner label is your L2VPN label.
> >
> >Cheers,
> >-Mohan
> >
> >
> >On Sun, Sep 20, 2015 at 3:23 PM, Jason Lixfeld <ja...@lixfeld.ca> wrote:
> >> Hello!
> >>
> >> I've been doing some reading recently on Segment Routing.  By all
> >>accounts, it seems that the (only?) implementation for SR supports
> >>L3VPN.  Am I dumb and just missing the L2VPN bits, or is L3VPN simply
> >>the extent of the first generation?
> >>
> >> Sent from my iPhone
>
>

Re: Segment Routing for L2VPN?

[Jeff Tantsura]

Hi,

In most well designed IP routing stacks the way to get to a labeled
(tunneled) next hop is decoupled from a service, so if a service requires
such next hop it is upto (usually RIB) to return one (best, multiple might
exist) which would be used for forwarding. If it is a Segment Routed one
so it will then be used.

Cheers,
Jeff

-Original Message-
From: Mohan Nanduri <mohan.nand...@gmail.com>
Date: Sunday, September 20, 2015 at 12:59 PM
To: Jason Lixfeld <ja...@lixfeld.ca>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Subject: Re: Segment Routing for L2VPN?

>No, it works with L2VPNs also. Outer label is going to be SR label and
>inner label is your L2VPN label.
>
>Cheers,
>-Mohan
>
>
>On Sun, Sep 20, 2015 at 3:23 PM, Jason Lixfeld <ja...@lixfeld.ca> wrote:
>> Hello!
>>
>> I've been doing some reading recently on Segment Routing.  By all
>>accounts, it seems that the (only?) implementation for SR supports
>>L3VPN.  Am I dumb and just missing the L2VPN bits, or is L3VPN simply
>>the extent of the first generation?
>>
>> Sent from my iPhone

Re: Segment Routing for L2VPN?

[Mohan Nanduri]

No, it works with L2VPNs also. Outer label is going to be SR label and
inner label is your L2VPN label.

Cheers,
-Mohan


On Sun, Sep 20, 2015 at 3:23 PM, Jason Lixfeld  wrote:
> Hello!
>
> I've been doing some reading recently on Segment Routing.  By all accounts, 
> it seems that the (only?) implementation for SR supports L3VPN.  Am I dumb 
> and just missing the L2VPN bits, or is L3VPN simply the extent of the first 
> generation?
>
> Sent from my iPhone