The introduction of alternatives was prompted by a number of concerns,
not just the encapsulation overhead.
Having said that, we as a group have not adopted the uSID approach, and
many of us have serious concerns about that. Claiming that uSID is
agreed and solves the size problems seems not to align with my
understanding of the situation.
Yours,
Joel
On 9/1/2019 10:20 AM, Dirk Steinberg wrote:
Hi,
the introduction of SRv6 as alternate data plane in addition to MPLS
has been an important step in SPRING, providing an encapsulation
for SPRING traffic that is native to IPv6.
The question about the necessity of work on alternate encapsulations
was fueled by concerns about encapsulation overhead when using
full 128 bit SIDs in the SRv6 SRH.
Through the introduction of the uSID network instruction in SRv6
these concerns are now properly addressed and SRv6 with uSID
can now also be deployed in a very MTU-efficient manner.
Therefore I do not see a necessity for any additional encapsulations.
Cheers
Dirk
Am 31.08.2019 um 06:05 schrieb Zafar Ali (zali) <z...@cisco.com
<mailto: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
<mailto:spring-boun...@ietf.org>> on behalf of Rob Shakir
<robjs=40google....@dmarc.ietf.org
<mailto:robjs=40google....@dmarc.ietf.org>>
*Date:*Sunday, August 4, 2019 at 5:04 PM
*To:*SPRING WG List <spring@ietf.org <mailto: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
*
o
o e.g., (number of nodes, network diameter,
o 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 (*).
o
*
* 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 <mailto:spring-cha...@ietf.org>and ADs
viaspring-...@ietf.org <mailto: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 <mailto: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
