Re: [spring] Beyond SRv6.

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 <sparisot@free-mobile.fr> 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" <satoru.matsushima@gmail.com>
>> À: "SPRING WG List" <spring@ietf.org>
>> Cc: "Zafar Ali, zali" <zali@cisco.com>, "Rob Shakir" <robjs=40google.com@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) <zali@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-bounces@ietf.org> on behalf of Rob Shakir
>>> <robjs=40google.com@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-chairs@ietf.org and ADs via
>>> spring-ads@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