Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

[Ron Bonica <[e-mail]>]

Cheng,

Please see my response to Jeff.

                     Ron




Juniper Business Use Only
From: Chengli (Cheng Li) <[e-mail]>
Sent: Friday, September 6, 2019 10:57 AM
To: Ketan Talaulikar (ketant) <[e-mail]>; Jeff Tantsura <[e-mail]>; Ron Bonica <[e-mail]>
Cc: Rob Shakir <[e-mail]>; bruno.decraene <[e-mail]>; SPRING WG List <[e-mail]>; Alexander Vainshtein <[e-mail]>
Subject: RE: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

Correct, that is what I want to say. Thanks Ketan for your information.

I think Ron understands the usage of Binding SID very well, but I am very curious about why he said there is no need to have a binding SID.
________________________________
Cheng Li
Email: [e-mail]<mailto:[e-mail]>

From: Ketan Talaulikar (ketant)<[e-mail]<mailto:[e-mail]>>
To: Jeff Tantsura<[e-mail]<mailto:[e-mail]>>;Ron Bonica<[e-mail]<mailto:[e-mail]>>
Cc: Rob Shakir<[e-mail]<mailto:[e-mail]>>;bruno.decraene<[e-mail]<mailto:[e-mail]>>;SPRING WG List<[e-mail]<mailto:[e-mail]>>;Alexander Vainshtein<[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)
Time: 2019-09-06 13:59:51

I think the key point here is that BSID is not only as a means of “a shorthand that can be used to represent a list of SIDs”. Please see draft-ietf-spring-segment-routing-policy for the use-cases for BSID (including the one pointed by Jeff).

Besides BSID, we also have TI-LFA (draft-ietf-rtgwg-segment-routing-ti-lfa) and Microloop Avoidance (draft-bashandy-rtgwg-segment-routing-uloop) that require imposition of SID stack. This is for both SR/MPLS and SRv6.

For SRv6, we’ve always had the encap option for such imposition scenarios in draft-ietf-spring-srv6-network-programming and suggesting that is nothing new.

In fact, the most widely expected use-case for SRv6 is within a SR domain to transport customer packets transparently from an ingress PE to an Egress PE. This implies that the customer packets are encapsulated with an outer IPv6 header (managed by the Service Provider). Insertion is discussed only in this context for this outer encap for BSID, TI-LFA, etc. and is something that is requested by operators within their network boundaries (e.g. see Robert’s emails explaining details). These considerations apply to SRv6 as well as other variants.

We (SPRING WG) have obviously to work with 6man to address the issues/concerns with IPv6 protocol related to SRH insertion and the authors have indicated the same (see Darren’s emails) and Bruno has clearly spelt out the agreement between WGs on this matter and the path forward (https://mailarchive.ietf.org/arch/msg/spring/ZFm_bQP1-C2f9xJuXtvEd9mLoxU<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/ZFm_bQP1-C2f9xJuXtvEd9mLoxU__;!8WoA6RjC81c!ULvljRiG4AhbysSeaX7YvDEnLU4zipuDd91uSS4KdRkJMkye19e3rev9n5Z8LZ9e$>). Let’s allow this work to progress in 6man.

Either the above points have not been understood or are being ignored and this whole insertion debate at this juncture and on this thread seems motivated to digress from the key questions polled by the WG chairs to operators. Seems more like an attempt to provoke the so-called “IPv6 orthodoxy” in 6man … which I say seem to have met with some success 😉

Thanks,
Ketan

From: spring <[e-mail]<mailto:[e-mail]>> On Behalf Of Jeff Tantsura
Sent: 06 September 2019 10:37
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
Cc: Rob Shakir <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; SPRING WG List <[e-mail]<mailto:[e-mail]>>; Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

Thanks Ron!

I realize that, my intention was to bring up the case where BSID is currently used.
Regards,
Jeff

On Sep 5, 2019, at 21:15, Ron Bonica <[e-mail]<mailto:[e-mail]>> wrote:
Jeff,

In SRv6+ you can achieve this abstraction without a new SID type. In order to do this, network operators:

  *   Associate an IPv6 address with the abstract segment
  *   Instantiate policy on abstract segment ingress nodes. The policy causes the abstract segment ingress nodes to encapsulate packets destined for the above mentioned IPv6 address in an IPv6 header with its own CRH. This IPv6 header and CRH define the abstracted segment
Now, the only problem is to get packets to the abstract segment ingress node with the right IPv6 destination address. This can be achieved by associated a node SID in the original packet with the above mentioned IPv6 address.

And again, if network operators object to this approach, it would be easy enough to add a binding SID to SRv6+. However, to date, no operator has expressed interest.

                                                                                                    Ron



Juniper Business Use Only
From: Jeff Tantsura <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, September 5, 2019 2:10 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; Rob Shakir <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Ron Bonica <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG List <spring@ietf..org<mailto:[e-mail]>>
Subject: Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

Ron,

another, and quite important use of BSID in SR-MPLS is to provide an anchor point to another domain/layer and an abstraction to program this layer without understanding its semantics.
SR/RSVP-TE or IP/Opto would be a perfect example of that, draft-anand-spring-poi-sr describes such case.

Cheers,
Jeff
On Sep 5, 2019, 10:39 AM -0700, Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]..org>>, wrote:
Hi Alexander,

SRv6+ does not currently define a binding SID. If one were ever needed, it would be easy enough to specify and implement. When a segment endpoint encountered a binding SID, it would:


  *   Decrement Segments Left
  *   Copy an IPv6 address from the SFIB to the IPv6 destination address
  *   Prepend an IPv6 header with its own CRH to the packet. Information required build that header and CRH would be found in the SFIB

However, I don’t think that SRv6+ will ever need a binding SID. A binding SID is a shorthand that can be used to represent a list of SIDs. Since SRv6+ SIDs are already short, this shorthand isn’t needed.

But, again, if we ever needed a binding SID for another reason, we could add it.

                                                                                               Ron




Juniper Business Use Only
From: spring <[e-mail]<mailto:[e-mail]>> On Behalf Of Alexander Vainshtein
Sent: Wednesday, September 4, 2019 6:49 AM
To: Rob Shakir <[e-mail]<mailto:[e-mail]>>; bruno.decraene@orange..com<mailto:bruno.decraene@orange..com>
Cc: SPRING WG List <spring@ietf..org<mailto:[e-mail]>>
Subject: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

Rob, Bruno and all,
I have a naive question based, most probably, on insufficient understanding of SRv6 (not to mention SRv6+).
This question has been prompted by the complaints (on the Beyond SRv6 thread) about problems with supporting long lists of 128-bits of SIDs in the IPv6 Segment Routing Headers, and various approaches to mitigating these complaints.



Section 5 of RFC 8402<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8402-23section-2D5&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=4Pw59S_7ctGrITQ1UDr9pRLX3wSiw8AIep6o351bwAU&e=> defines Binding Segments (BSIDs) and says that “he BSID is bound to an SR Policy, instantiation of which may involve a list of SIDs.”   It also explains that BSIDs facilitate better scalability (among other things) of SR.  And, as is appropriate for the architecture document, RFC 8402 does not differentiate between SR-MPLS and SRv6 in the definition of Binding segments.



The SR-MPLS<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dspring-2Dsegment-2Drouting-2Dmpls-2D22&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=20cuMhbB0Wd1mo1ubF9TATo4O_xDH5x814ul0VlQnz4&e=> draft (already approved for publication as an RFC)  mentions (e.g., in the example in Section A.3.2) that the node that has allocated a BSID label 1023 for a specific SR policy FEC-1 for which it is the head-end “installs a transit MPLS forwarding entry to SWAP incoming label=1023, with outgoing labels and outgoing interface determined by the SID-List for FEC1”. This explanation is fully compatible with the MPLS architecture where the top label of the label stack can be swapped with multiple new labels.



Can somebody please explain how (if at all) are Binding Segments going to be supported in SRv6 and/or in SRv6+?

To the best of my (admittedly, limited) understanding of IPv6, no equivalent of the SR-MPLS handling of the BSID is allowed with the IPv6 routing headers as per RFC 8200<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8200&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=17YIL2k_NBYLoWTSab6OcrfhMvYxxfelVsE-dFUZNPU&e=>. For the reference, the IPv6 Segment Routing Header<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2D6man-2Dsegment-2Drouting-2Dheader-2D22&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=Xbus4FkiatrdR0m5qVakZ652C8lrEl-aXXF1KGxPVAE&e=> draft does not mention Binding SIDs at all..



From my POV, if Binding segments cannot be supported with SRv6 or SRv6+, a Technical Erratum on 8402 should posted..

Did I miss something here?

Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: spring <[e-mail]<mailto:[e-mail]>> On Behalf Of Nick Hilliard
Sent: Tuesday, September 3, 2019 9:22 PM
To: Rob Shakir <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG List <spring@ietf..org<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [spring] Beyond SRv6.

Rob,

Clarifying what I wrote previously, I don't think it would be appropriate for draft-filsfils-spring-net-pgm-extension-srv6-usid to progress further unless the authors can demonstrate that the volume of IPv6 addressing required can be satisfied in a way that works within the constraints that the operational community operates within..

If there is an expectation that this address space will be assigned from the global unicast address block via standard RIR allocation policies, then the authors will need to demonstrate that the RIRs are going to be comfortable changing their allocation policies to accommodate this.

Nick
Ron Bonica<mailto:rbonica=[e-mail]>
1 September 2019 at 22:10
Hi Fernando,

6man participants should look at the following:

- https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_3XtGMsvx1pLfDs2UgbiiJSG6H2-3Fu-3Dhttps-253A-252F-252Ftools.ietf.org-252Fhtml-252Fdraft-2Dietf-2Dspring-2Dsrv6-2Dnetwork-2Dprogramming-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=O66WGTcEG9ZY70Ry9qIdBNJuDMT7o1CzvozI7in8tH4&e=> (In particular, Sections 4 and 5)
- https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_3GTugpKX6MEkQtxjkPN4sFA6H2-3Fu-3Dhttps-253A-252F-252Ftools.ietf.org-252Fhtml-252Fdraft-2Dfilsfils-2Dspring-2Dnet-2Dpgm-2Dextension-2Dsrv6-2Dusid-2D02&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=U-KuSOWhXTpyxiMVvcwTKU2Eonbtqs8iI_oxIEppZ4s&e=>

Ron


Juniper Business Use Only

-----Original Message-----
From: Fernando Gont <[e-mail]><mailto:[e-mail]>
Sent: Saturday, August 31, 2019 4:53 PM
To: Ron Bonica <[e-mail]><mailto:[e-mail]>; Rob Shakir <[e-mail]><mailto:[e-mail]>; SPRING WG List <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [spring] Beyond SRv6.

Hi, Ron,

For those 6man-ers that have not been following the sprin work, could you please clarify what do you mean by "stretching the interpretation of
RFC8200 or RFC4291"?

In the past we have seen outright violation of RFC8200 (formerly RFC2460), so I'm curious if there are any documents trying to do the same, or what.

Thanks!

Cheers,
Fernando


--
Fernando Gont
SI6 Networks
e-mail: [e-mail]<mailto:[e-mail]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492



--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_33tKyquDDwPJxhZF9gfXr6D6H2-3Fu-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fipv6&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=3aBOOwc2ATKc146Ok72cTJF2S-mXQaXO6cVBYn9jeQA&e=>
--------------------------------------------------------------------
Fernando Gont<mailto:[e-mail]>
31 August 2019 at 21:53
Hi, Ron,

For those 6man-ers that have not been following the sprin work, could
you please clarify what do you mean by "stretching the interpretation of
RFC8200 or RFC4291"?

In the past we have seen outright violation of RFC8200 (formerly
RFC2460), so I'm curious if there are any documents trying to do the
same, or what.

Thanks!

Cheers,
Fernando

Ron Bonica<mailto:rbonica=[e-mail]>
31 August 2019 at 21:33
Rob,

The following are arguments for proceeding with SRv6+:


  *   Efficient forwarding with deep SID lists
  *   Operational Simplicity
  *   SRv6+ work may finish before SRv6

Efficient forwarding with deep SID Lists
----------------------------------------------------

SR customers have stated a firm requirement to support SR paths that contain 8 to 12 segments. They have also stated a requirement for implementations to forward at line speed  and without consuming excessive overhead bandwidth.

SRv6, as defined in draft-ietf-6man-segment-routing-header, cannot satisfy these requirements. In order to support an SR path with 8 segments, SRv6 would require a 128-byte SRH. Even if ASICs could process such a long SRH at line speed, the bandwidth overhead would be prohibitive.

Therefore, one of the four solutions  that you mention below is required to make SRv6 deployable. While draft-ietf-6man-segment-routing-header is close to maturity, the four competing solutions mentioned below are equally mature and should be given equal consideration.


The four solutions are SRv6+, uSID, draft-li and draft-mirsky.

Operational Simplicity
-----------------------------
Network operators strive for operational simplicity. By loosely interpreting (and sometimes bending) the requirements of RFCs 4291 and RFC 8200, SRv6 introduces architectural quirks that introduce operational complexity. The following are architectural quirks of  draft-ietf-6man-segment-routing-header:


  *   The Segment Routing Header (SRH) serves purposes other than routing. Therefore, the SRH is sometimes required for packets that traverse the least-cost path from source to destination
  *   The SRH and the IPv6 Authentication Header are incompatible.
  *   The IPv6 destination address determines whether an SRH is valid and how it is processed. For example, if the IPv6 destination address contains one locally instantiated value, the SRH might be processed in one particular way, while if the IPv6 destination address contains another locally instantiated value, the SRH might be totally invalid.

Draft-ietf-spring-srv6-network-programming  promises more architectural quirks. For example:


  *   Segment endpoints can insert and/or delete IPv6 extension headers
  *   An IPv6 packet can contain two Segment Routing headers
  *   IPv6 packets are no longer self-describing. For example, the Next Header Field in the SRH can carry a value of No Next Header, even though the SRH is followed by Ethernet payload.

Other emerging drafts promise still more architectural quirks. For example, in draft-ali-6man-spring-srv6-oam, implementations need to examine the SRH even when Segment Left equals zero. This is because the SRH has been overloaded to carry OAM as well as routing information.

Furthermore, draft-filsfils-spring-net-pgm-extension-srv6-usid requires network operators to obtain address space and number their networks in a particular way to make routing work.

SRv6+ Work May Finish Before SRv6 work
--------------------------------------------------------
SRv6+  has been implemented on LINUX and is being implemented on JUNOS. Implementation experience demonstrates that specification is fairly complete. For example, there is no need for an SRv6+ OAM document. It’s just IPv6 and IPv6 OAM just works.

Furthermore, the SRv6+ specifications adhere to a strict interpretation of RFC 8200. Therefore, as they progress through the working group, they won’t need to overcome the objections that are inevitably encountered when stretching the interpretation of a specification that is so fundamental as RFC 8200.

                                                                                                      Thanks,
                                                                                                          Ron








From: spring <[e-mail]><mailto:[e-mail]> On Behalf Of Rob Shakir
Sent: Sunday, August 4, 2019 5:04 PM
To: SPRING WG List <spring@ietf..org><mailto:[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__clicktime.symantec.com_3XuwzQk4bWzHWmJ3PNZzRWh6H2-3Fu-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Dbonica-2D2Dspring-2D2Dsrv6-2D2Dplus-2D2D04-2526d-253DDwMFaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DFch9FQ82sir-2DBoLx84hKuKwl-2DAWF2EfpHcAwrDThKP8-2526m-253DackZC9evRf-5FLWYu2a-2D1NaGRDJKdxnE2ieIC4dD-5FFL6s-2526s-253DKUhAfjVsx-5FwK645uJk0FHzs2vxiAVr-2DCskMPAaEhEQQ-2526e-253D&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=ZeNvkiTiz_G_r9MTMnyueTmhcdc2r68VTgfzWbPH6RQ&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__clicktime.symantec.com_3XUeUBC1vrovLBUoCPCKDzD6H2-3Fu-3Dhttps-253A-252F-252Furldefense.proofpoint..com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Dfilsfils-2D2Dspring-2D2Dnet-2D2Dpgm-2D2Dextension-2D2Dsrv6-2D2Dusid-2D2D01-2526d-253DDwMFaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DFch9FQ82sir-2DBoLx84hKuKwl-2DAWF2EfpHcAwrDThKP8-2526m-253DackZC9evRf-5FLWYu2a-2D1NaGRDJKdxnE2ieIC4dD-5FFL6s-2526s-253DAq1DK7fu73axZ1PXLIE8xnHE2AhTtNZy9LTHgWqx4CQ-2526e-253D&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=DAgTYMJJScz3Mrfl9s0dqH2s4LNiTzArv-gmKKQHVqw&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__clicktime.symantec.com_3RsA24LYYDz2wXB3s3USU4K6H2-3Fu-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Dli-2D2Dspring-2D2Dcompressed-2D2Dsrv6-2D2Dnp-2D2D00-2526d-253DDwMFaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DFch9FQ82sir-2DBoLx84hKuKwl-2DAWF2EfpHcAwrDThKP8-2526m-253DackZC9evRf-5FLWYu2a-2D1NaGRDJKdxnE2ieIC4dD-5FFL6s-2526s-253DXWUDAD2FMhWLfeT5sgUb1lgthJhugcyT98GJ2N-2DCrKs-2526e-253D&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=YwO2-hrzdxaWDQyHCQVkn-pOoJ1S3Ce0TLYcxRlBtV4&e=>
  *   https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_3QHabsdCZRy35Awz9b6QUCR6H2-3Fu-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Dmirsky-2D2D6man-2D2Dunified-2D2Did-2D2Dsr-2D2D03-2526d-253DDwMFaQ-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DFch9FQ82sir-2DBoLx84hKuKwl-2DAWF2EfpHcAwrDThKP8-2526m-253DackZC9evRf-5FLWYu2a-2D1NaGRDJKdxnE2ieIC4dD-5FFL6s-2526s-253DgcbkHYxXm7FU7vblOB1vI58SDaaWf62pa7YvLmsP4nI-2526e-253D&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=FUOxxgQDJZ4MkDXlR7jfAPv725rDj8H66uW4UFt3fZo&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

     *   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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_33tKyquDDwPJxhZF9gfXr6D6H2-3Fu-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fipv6&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=JrElhnt820GdSRCJ_8J_DhpMn_7LkjyBe4welpUifuc&s=3aBOOwc2ATKc146Ok72cTJF2S-mXQaXO6cVBYn9jeQA&e=>
--------------------------------------------------------------------


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!ULvljRiG4AhbysSeaX7YvDEnLU4zipuDd91uSS4KdRkJMkye19e3rev9n52JszXy$>