Re: [spring] Beyond SRv6.

[Tarek Saad <[e-mail]>]

Hi WG,

RFC8200 (section 4.4) defines the Routing Header as merely means to steer packets across topological elements. My understanding of the SRv6+’s proposal is that it strictly adheres to this and leaves any service or function instructions to be carried in other parts of IPv6 header. This (among other advantages) provides a clean delineation of the different layers of the network (underlay transport from overlay/services) and allows for possibility of different overlay technologies to be seamlessly carried over SRv6+.

This is in contrast to exposing overlays to a specific underlay technology and forcing it to understand and encode the required bits of information it requires within it. Feel free to correct me if I got it wrong.

Regards,
Tarek


From: spring <[e-mail]> on behalf of Ron Bonica <rbonica=[e-mail]>
Date: Monday, September 2, 2019 at 9:23 AM
To: Rob Shakir <robjs=[e-mail]>, SPRING WG List <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [spring] Beyond SRv6.

Rob,

There may be an elephant in the room that needs addressing….

Over the years, the IPv6 community has specified a very tight architecture that encodes some information in IPv6 addresses, other information in Routing headers, and still other information in Destination Options headers. SRv6+ adheres strictly to this architecture. Because it reuses IPv6 machinery, its specification promises it be painless and its deployment promises to be safe. To date, there has been no significant technical criticism of SRv6+. Only a claim that SRv6 is nearly complete and good enough. (Both of those claims may require scrutiny).

By contrast, SRv6 varies from the spirit, if not the letter of the IPv6 architecture. It encodes things in IPv6 address that have never been encoded in IPv6 addresses before. It attempts to encode everything else in the Routing header, as if the other IPv6 extension headers didn’t exist. It frequently tests the limits of RFC 8200 compliance.

This creates a situation in which each variance from IPv6 orthodoxy requires another. For example, because SRv6 encodes instructions in IPv6 addresses, draft-ali-6man-spring-srv6-oam is required. And now, draft-ali-6man-spring-srv6-oam creates its own variances from the IPv6 orthodoxy. OAM information is encoded in the Routing header and the Routing header must be examined, even when Segment Left is equal to zero.

I invite everyone to consider how TI-LFA an uSID will interact.

So, why would the IETF would want to prevent work on the more conservative, SRv6+ approach?  This brings us to the back to the elephant in the room…..

Until very recently, relatively few router vendors have supported IPv6 extension headers in ASICs. If an IPv6 packet contained any extension headers at all, it was sent to the slow path.

SRv6+ encourages router vendors to support both the Routing and Destination Options header in ASICs. This sets vendors on a path on a path towards more complete implementation of the architecture that the IPv6 community has developed so carefully over the years. It encourages vendors to commit more and more of RFC 8200 to ASICs.

SRv6 encourages router vendors to support the Routing header in ASICs, while doing everything possible to mitigate the need to support Destination Options in ASICs. This may be a necessary expedient for many platforms. However, it should not be the only approach, or even the long-term approach for the IETF.

                                                                                                                                   Ron




From: spring <[e-mail]> On Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List <[e-mail]>
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbonica-2Dspring-2Dsrv6-2Dplus-2D04&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=KUhAfjVsx_wK645uJk0FHzs2vxiAVr-CskMPAaEhEQQ&e=>
·         uSID -- https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D01&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=Aq1DK7fu73axZ1PXLIE8xnHE2AhTtNZy9LTHgWqx4CQ&e=>


During the IETF week, two additional drafts have been proposed:
·         https://tools.ietf.org/html/draft-li-spring-compressed-srv6-np-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Dspring-2Dcompressed-2Dsrv6-2Dnp-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=XWUDAD2FMhWLfeT5sgUb1lgthJhugcyT98GJ2N-CrKs&e=>
·         https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmirsky-2D6man-2Dunified-2Did-2Dsr-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ackZC9evRf_LWYu2a-1NaGRDJKdxnE2ieIC4dD_FL6s&s=gcbkHYxXm7FU7vblOB1vI58SDaaWf62pa7YvLmsP4nI&e=>


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    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 via [e-mail]<mailto:[e-mail]> and ADs via [e-mail]<mailto:[e-mail]>.


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.



Juniper Business Use Only