Adding my perspective here. The fact that some proposals come on the table shows that we have something to optimize. So far there has been little feedback on sizes required in real deployments. Personally I have seen request for small (1-2 sids) to other cases which require up to 9-10 sids deep. We know certain HW cannot cope with some of these requests. I cannot judge on how many customers or in small to medium range but it would be good we can define a solution that works for the majority of customers.
Now given that this is going on for some time in IETF and we have deployments it would be bad if we change direction all of a sudden. So I propose to flush out what we have and where the limits are and figure out a way forward based on this. My 2 cents. From: spring <[email protected]> on behalf of Rob Shakir <[email protected]> Date: Sunday, 4 August 2019 at 22:04 To: SPRING WG List <[email protected]> Subject: [spring] Beyond SRv6. Hi SPRING WG, Over the last 5+ years, the IETF has developed Source Packet Routing in NetworkinG (SPRING) aka Segment Routing for both the MPLS (SR-MPLS) and IPv6 (SRv6) data planes. SR-MPLS may also be transported over IP in UDP or GRE. These encapsulations are past WG last call (in IESG or RFC Editor). During the SPRING WG meeting at IETF 105, two presentations were related to the reduction of the size of the SID for IPv6 dataplane: * * SRv6+ / CRH -- * https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-04 * * * uSID -- * https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01 * During the IETF week, two additional drafts have been proposed: * * https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00 * * * https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03 * As we expressed during the meeting, it is important for the WG to understand what the aims of additional encapsulations are. Thus, we think it is important that the WG should first get to a common understanding on the requirements for a new IPv6 data plane with a smaller SID - both from the perspective of operators that are looking to deploy these technologies, and from that of the software/hardware implementation. Therefore, we would like to solicit network operators interested in SR over the IPv6 data plane to briefly introduce their: * * use case (e.g. Fast Reroute, explicit routing/TE) * * * forwarding performance and scaling requirements * * * e.g., (number of nodes, network diameter, * number of SID required in max and average). For the latter, if possible using both SRv6 128-bit SIDs and shorter (e.g. 32-bit) SIDs as the number would typically be different (*). * * * if the existing SRv6 approach is not deployable * in their circumstances, details of the requirement of a different solution is required and whether this solution is needed for the short term only or for the long term. * As well as deployment limitations, we would like the SPRING community to briefly describe the platform limitations that they are seeing which limit the deployment of SRv6 In particular limitations related to the number of SIDs which can be pushed and forwarded and how much the use of shorter SIDs would improve the deployments . For both of these sets of feedback if possible, please post this to the SPRING WG. If the information cannot be shared publicly, please send it directly to the chairs & AD (Martin). This call for information will run for four weeks, up to 2019/09/03. As a reminder, you can reach the SPRING chairs via [email protected]<mailto:[email protected]> and ADs via [email protected]<mailto:[email protected]>. Thank you, -- Rob & Bruno (*) As expressed on the mailing list, a 128 bit SID can encode two instructions a node SID and an adjacency SID hence less SID may be required.
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
