There’s no objection against policies installed at ingress interfaces to an SR domain. Rob correctly states, that the SR architecture does not require per path state at transit nodes. And that’s good and correct. I’d like to see the number of signaling protocols in the SR core network being reduced as compared with today’s MPLS network, not increased.
There’s RSVP-TE for MPLS, which can be deployed for services requiring per path state at transit nodes. Regards, Ruediger Von: spring [mailto:spring-boun...@ietf.org] Im Auftrag von Stewart Bryant Gesendet: Dienstag, 19. Juni 2018 13:19 An: Rob Shakir <robjs=40google....@dmarc.ietf.org>; SPRING WG List <spring@ietf.org> Betreff: Re: [spring] Updating the SPRING WG Charter On 01/06/2018 17:05, Rob Shakir wrote: The SPRING WG defines procedures that allow a node to steer a packet through an SR Policy instantiated as an ordered list of instructions called segments and without the need for per-path state information to be held at transit nodes. I am not sure where the line gets drawn with the per-path state statement. If I introduce a binding-SID to allow the creation of a path, have I introduced per-path state or not? In practise a management entity will choose between the infinity of possible binding-SIDs by considering the need to create specific paths and I would imagine that many will be instantiated just-in-time. I think that the key point is that the ingress creates the path by using SIDs to create a concatenation of paths, policies and resources. However it could be argued that as soon as we introduced Binding SIDs we introduced per-path state. I think we might be best served by deleting the text I have highlighted. - Stewart
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
