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 <[email protected]>, 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 <[email protected]> On Behalf Of Alexander Vainshtein > Sent: Wednesday, September 4, 2019 6:49 AM > To: Rob Shakir <[email protected]>; [email protected] > Cc: SPRING WG List <[email protected]> > 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 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 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. For the reference, the IPv6 Segment Routing Header 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: +972-39266302 > Cell: +972-549266302 > Email: [email protected] > > From: spring <[email protected]> On Behalf Of Nick Hilliard > Sent: Tuesday, September 3, 2019 9:22 PM > To: Rob Shakir <[email protected]> > Cc: SPRING WG List <[email protected]>; [email protected] > 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 > > 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 > > (In particular, Sections 4 and 5) > > - > > https://tools.ietf.org/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-02 > > > > Ron > > > > > > Juniper Business Use Only > > > > -----Original Message----- > > From: Fernando Gont <[email protected]> > > Sent: Saturday, August 31, 2019 4:53 PM > > To: Ron Bonica <[email protected]>; Rob Shakir <[email protected]>; SPRING > > WG List <[email protected]>; [email protected] > > 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: [email protected] > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > Fernando Gont > > 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 > > 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 <[email protected]> On Behalf Of Rob Shakir > > Sent: Sunday, August 4, 2019 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 via [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.. > > > > > > Juniper Business Use Only > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > ___________________________________________________________________________ > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
