Subject: [spring] anycast segments and indexed SIDs

From: Martin Horneffer <[email-masked]>
Date: Fri, 15 May 2015 10:20:21 +0300

Hello everyone,

there is a problem for networks that use spring on the MPLS forwarding 
plane: It seems it would not be feasible to use anycast segments for 
traffic engineering since we introduced indexed SIDs.

I would really like to use of some well-defined anycast addresses to 
solve a number of traffic engineering use cases. I.e. an anycast address 
would stand for a certain property of possible paths and segment routing 
would be responsible to apply this property to the traffic which needs 
it. In other words I want to use a path with one anycast segment, 
followed by the usual node segment to the actual destination (typically 
an egress LER).

The anycast segment itself is fine: it can be built in the usual way.
However for the following node segment the spring source node cannot 
calculate the label value. The stack PUSHing router would not know at 
which node the second segment would actually start, and thus which SRGB 
to apply.

If needed I could make a drawing to illustrate this problem.

As I see it, there would be three different options to address this problem:

1) Abandon anycast segments completely.
This would greatly reduce the usefulness of segment routing in my opinion.

2) Use a homogeneous SRGB, so that label values would effectively be the 
same for all nodes.
But in this case, why did we introduce indexes at all?

3) Use a context label. E.g. as defined in 
draft-raszuk-mpls-domain-wide-labels.

Since I really hate to add more labels to the stack than really needed, 
could we think of a way to only use context labels where needed?
As far as I can see this would only be relevant for the segment 
immediately following an anycast segment.

Are there any other options?

Best regards, Martin

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 15 May 2015 08:34:19 +0000

On May 15, 2015, at 9:20 AM, Martin Horneffer <[email-masked]> wrote:
> Hello everyone,
> 
> there is a problem for networks that use spring on the MPLS forwarding plane: It seems it would not be feasible to use anycast segments for traffic engineering since we introduced indexed SIDs.

well, yes, that's the price to pay if you can't use the same SRGB everywhere.

> I would really like to use of some well-defined anycast addresses to solve a number of traffic engineering use cases. I.e. an anycast address would stand for a certain property of possible paths and segment routing would be responsible to apply this property to the traffic which needs it. In other words I want to use a path with one anycast segment, followed by the usual node segment to the actual destination (typically an egress LER).
> 
> However for the following node segment the spring source node cannot calculate the label value. The stack PUSHing router would not know at which node the second segment would actually start, and thus which SRGB to apply.
> 
> 2) Use a homogeneous SRGB, so that label values would effectively be the same for all nodes.

that's definitely the option I'd recommend, not to mention the simplicity of operations.

> But in this case, why did we introduce indexes at all?

because not all vendors have been capable of producing implementations using the common SRGB. So far we have many vendors that agreed on using 16000-23999 but not all...

s.

> 
> 3) Use a context label. E.g. as defined in draft-raszuk-mpls-domain-wide-labels.
> 
> Since I really hate to add more labels to the stack than really needed, could we think of a way to only use context labels where needed?
> As far as I can see this would only be relevant for the segment immediately following an anycast segment.
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 15 May 2015 10:39:07 +0200

hi martin,

IMO context labels are the agreed-upon vehicle to disambiguate label-space.
in the past we have used that e.g. for egress-protection and upstream label-allocation.

/hannes

On Fri, May 15, 2015 at 10:20:21AM +0300, Martin Horneffer wrote:
| Hello everyone,
| 
| there is a problem for networks that use spring on the MPLS forwarding
| plane: It seems it would not be feasible to use anycast segments for traffic
| engineering since we introduced indexed SIDs.
| 
| I would really like to use of some well-defined anycast addresses to solve a
| number of traffic engineering use cases. I.e. an anycast address would stand
| for a certain property of possible paths and segment routing would be
| responsible to apply this property to the traffic which needs it. In other
| words I want to use a path with one anycast segment, followed by the usual
| node segment to the actual destination (typically an egress LER).
| 
| The anycast segment itself is fine: it can be built in the usual way.
| However for the following node segment the spring source node cannot
| calculate the label value. The stack PUSHing router would not know at which
| node the second segment would actually start, and thus which SRGB to apply.
| 
| If needed I could make a drawing to illustrate this problem.
| 
| As I see it, there would be three different options to address this problem:
| 
| 1) Abandon anycast segments completely.
| This would greatly reduce the usefulness of segment routing in my opinion.
| 
| 2) Use a homogeneous SRGB, so that label values would effectively be the
| same for all nodes.
| But in this case, why did we introduce indexes at all?
| 
| 3) Use a context label. E.g. as defined in
| draft-raszuk-mpls-domain-wide-labels.
| 
| Since I really hate to add more labels to the stack than really needed,
| could we think of a way to only use context labels where needed?
| As far as I can see this would only be relevant for the segment immediately
| following an anycast segment.
| 
| Are there any other options?
| 
| Best regards, Martin
| 
| _______________________________________________
| spring mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 15 May 2015 10:42:18 +0200

I agree.

I think introducing indexes especially that they do not solve all problems
is not so great of an idea.

That is why I proposed a new clean complete label space for SR in
draft-raszuk-mpls-domain-wide-labels.

Of course an alternative is not to use mpls as a transport at all :-))

Cheers,
R.