Hi, As part of the 5G rollout, Softbank have deployed a nationwide SRv6 network carrying commercial traffic with the linerate performance using Merchant Silicon.
https://www.softbank.jp/corp/news/press/sbkk/2019/20190424_03/ # You can read it in your language through some translation service, e.g, google translation. draft-matsushima-spring-srv6-deployment-status captured that use case. Best regards, --satoru > 2019/08/31 6:05、Zafar Ali (zali) <[email protected]>のメール: > > Dear Chairs and the WG: > > The SRv6 network programming solution and its SRH encapsulation is > implemented on 12 hardware platforms including Merchant Silicon. > Multiple providers have deployed the SRv6 network programming solution and > its SRH encapsulation with line-rate performance carrying a significant > amount of commercial traffic. > Several independent interoperability reports documenting successful > interoperability of implementation from multiple vendors exist. > Implementation, deployment, and interoperability status is publicly > documented > inhttps://www.ietf.org/id/draft-matsushima-spring-srv6-deployment-status-01.txt. > > Most use-cases are expected to use very few SRv6 segments. > > In some specific use-cases, one may desire to optimize the MTU usage further. > The SRv6 network programming solution and its SRH encapsulation also support > for this Optimization, through the uSID network instruction. > > I do not see the need for any new encapsulation work. > > Thanks > > Regards … Zafar > > From: spring <[email protected]> on behalf of Rob Shakir > <[email protected]> > Date: Sunday, August 4, 2019 at 5:04 PM > 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 [email protected] and ADs > via [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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
