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 <rbon...@juniper.net> 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 <jefftant.i...@gmail.com> > Sent: Thursday, September 5, 2019 2:10 PM > To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; Rob Shakir > <ro...@google.com>; bruno.decra...@orange.com; Ron Bonica > <rbon...@juniper.net> > Cc: SPRING WG List <spring@ietf.org> > 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=40juniper....@dmarc.ietf.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 <spring-boun...@ietf.org> On Behalf Of Alexander Vainshtein > Sent: Wednesday, September 4, 2019 6:49 AM > To: Rob Shakir <ro...@google.com>; bruno.decra...@orange..com > Cc: SPRING WG List <spring@ietf.org> > 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: alexander.vainsht...@ecitele.com > > From: spring <spring-boun...@ietf.org> On Behalf Of Nick Hilliard > Sent: Tuesday, September 3, 2019 9:22 PM > To: Rob Shakir <ro...@google.com> > Cc: SPRING WG List <spring@ietf.org>; 6...@ietf.org > 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 <fg...@si6networks.com> > Sent: Saturday, August 31, 2019 4:53 PM > To: Ron Bonica <rbon...@juniper.net>; Rob Shakir <ro...@google.com>; SPRING > WG List <spring@ietf.org>; 6...@ietf.org > 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: fg...@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > 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 <spring-boun...@ietf.org> On Behalf Of Rob Shakir > Sent: Sunday, August 4, 2019 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 via spring-cha...@ietf.org and ADs > via 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. > > > Juniper Business Use Only > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > 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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
