On May 15, 2015, at 9:20 AM, Martin Horneffer <[email protected]> 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). > > 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. 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. > > 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
