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 protected] | https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
