Hi, We deployed SRv6 as part of our new mobile network in Italy (Iliad Italy). SRv6 with SRH is carrying commercial traffic of millions of subscribers for several months, with line-rate performance and on several platforms and operating systems. We also started to extend our deployment to our national network in France (Free & Free Mobile), we already have significant inter-AS SRv6 traffic.
You can also read draft-matsushima-spring-srv6-deployment-status-01 section 2.3. Best regards, Sébastien ----- Mail original ----- > De: "Satoru Matsushima" <satoru.matsush...@gmail.com> > À: "SPRING WG List" <spring@ietf.org> > Cc: "Zafar Ali, zali" <z...@cisco.com>, "Rob Shakir" > <robjs=40google....@dmarc.ietf.org> > Envoyé: Samedi 31 Août 2019 15:41:43 > Objet: Re: [spring] Beyond SRv6. > 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) <z...@cisco.com>のメール: >> >> 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 <spring-boun...@ietf.org> on behalf of Rob Shakir >> <robjs=40google....@dmarc.ietf.org> >> Date: Sunday, August 4, 2019 at 5:04 PM >> To: SPRING WG List <spring@ietf.org> >> 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 viaspring-cha...@ietf.org and ADs >> via >> spring-...@ietf.org. >> >> 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 >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
