Hi, We are interested in the SRv6 solution as standardized by the working group. Thanks! We see SRv6 solution may align with some of our production requirements for TE(and other use-cases) while potentially being inline within our needs for simplicity, performance, MTU overhead optimizations etc
Gaurav > On Sep 1, 2019, at 1:19 AM, Sébastien Parisot <[email protected]> wrote: > > 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" <[email protected]> >> À: "SPRING WG List" <[email protected]> >> Cc: "Zafar Ali, zali" <[email protected]>, "Rob Shakir" >> <[email protected]> >> 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) <[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 > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
