Hi Matthew, Thank you very much for the detailed review and great suggestions. As there were a lot of comments and some of them led to substantial editorial changes, it took a little while to come back to you – sorry about that !
On the topic of “restructuring”. I agree section 7 (recovery schemes) was tough to read. What do you think about the new -11 version? I hope things are more clear now as we start with explaining each scheme first and then go into PCEP vs BGP. Please find responses inline via [cs] and the changes Andrew Stone and I concluded on in the newly updated version -11 online Cheers Christian > On 07.08.2025, at 12:57, Matthew Bocci via Datatracker <[email protected]> > wrote: > > Document: draft-ietf-spring-cs-sr-policy > Title: Circuit Style Segment Routing Policy > Reviewer: Matthew Bocci > Review result: Not Ready > > Hi Authors, WG > > I am the RTG DIR reviewer for draft-ietf-spring-cs-sr-policy-10. I have > competed an early review for the draft. I have some concerns with the clarity > and terminology used, as well many editorial nits. > > As a general high-level comment, the term 'transport' is well used in the > IETF, > but what I think you are trying to do for SR Policy with an MPLS data plane is > very similar to packet transport a.k.a. MPLS-TP. I am not saying that you need > to use MPLS-TP concepts or protocol extensions here, but it would help at > least > of the terminology was consistent and there was some cross-referencing of > common architectural elements like bidirectional co-routed paths, some of the > OAM and protection requirements etc. Also, I think it would help with > readability of some of the sections were restructured in terms of > architecture, > then BGP protocol extensions, then PCEP extensions. They are interleaved in > the > current text and that makes it harder to follow. > > Since I have a fair number of comments, I have copied the complete text below > with comments prepended by 'MB>' in-line. > > Thanks > > Matthew > ======= > > Network Working Group C. Schmutzer, Ed. > Internet-Draft Z. Ali, Ed. > Intended status: Informational Cisco Systems, Inc. > Expires: 26 December 2025 P. Maheshwari > Airtel India > R. Rokui > Ciena > A. Stone > Nokia > 24 June 2025 > > Circuit Style Segment Routing Policy > draft-ietf-spring-cs-sr-policy-10 > > Abstract > > This document describes how Segment Routing (SR) policies can be used > to satisfy the requirements for bandwidth, end-to-end recovery and > persistent paths within a SR network. The association of two co- > routed unidirectional SR Policies satisfying these requirements is > called "circuit-style" SR Policy (CS-SR Policy). > > Status of This Memo > > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at https://datatracker.ietf.org/drafts/current/. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > This Internet-Draft will expire on 26 December 2025. > > Copyright Notice > > Copyright (c) 2025 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents (https://trustee.ietf.org/ > license-info) in effect on the date of publication of this document. > > Schmutzer, et al. Expires 26 December 2025 [Page 1] > > Internet-Draft CS-SR Policy June 2025 > > Please review these documents carefully, as they describe your rights > and restrictions with respect to this document. Code Components > extracted from this document must include Revised BSD License text as > described in Section 4.e of the Trust Legal Provisions and are > provided without warranty as described in the Revised BSD License. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 > 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 4. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 4 > 4.1. Managing Bandwidth . . . . . . . . . . . . . . . . . . . 6 > 5. CS-SR Policy Characteristics . . . . . . . . . . . . . . . . 8 > 6. CS-SR Policy Creation . . . . . . . . . . . . . . . . . . . . 8 > 6.1. Policy Creation when using PCEP . . . . . . . . . . . . . 8 > 6.1.1. PCC-initiated Mode . . . . . . . . . . . . . . . . . 9 > 6.1.2. PCE-initiated Mode . . . . . . . . . . . . . . . . . 10 > 6.2. Policy Creation when using BGP . . . . . . . . . . . . . 10 > 6.3. Maximum SID Depth Constraint . . . . . . . . . . . . . . 11 > 7. Recovery Schemes . . . . . . . . . . . . . . . . . . . . . . 12 > 7.1. Unprotected . . . . . . . . . . . . . . . . . . . . . . . 12 > 7.2. 1:1 Protection . . . . . . . . . . . . . . . . . . . . . 13 > 7.2.1. Reversion . . . . . . . . . . . . . . . . . . . . . . 15 > 7.3. Restoration . . . . . . . . . . . . . . . . . . . . . . . 15 > 7.3.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . 15 > 7.3.2. 1:1+R Restoration . . . . . . . . . . . . . . . . . . 18 > 8. Operations, Administration, and Maintenance (OAM) . . . . . . 19 > 8.1. Connectivity Verification . . . . . . . . . . . . . . . . 20 > 8.2. Performance Measurement . . . . . . . . . . . . . . . . . 20 > 8.3. Candidate Path Validity Verification . . . . . . . . . . 21 > 9. External Commands . . . . . . . . . . . . . . . . . . . . . . 21 > 9.1. Candidate Path Switchover . . . . . . . . . . . . . . . . 21 > 9.2. Candidate Path Re-computation . . . . . . . . . . . . . . 21 > 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 > 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 > 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 > 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 > 13.1. Normative References . . . . . . . . . . . . . . . . . . 23 > 13.2. Informative References . . . . . . . . . . . . . . . . . 26 > Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 29 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 > > Schmutzer, et al. Expires 26 December 2025 [Page 2] > > Internet-Draft CS-SR Policy June 2025 > > 1. Introduction > > IP services typically leverage ECMP and local protection. However > transport services (commonly referred to as "private lines") that are > delivered via pseudowires such as [RFC4448], [RFC4553], > [I-D.ietf-pals-ple], [RFC5086] and [RFC4842] for example, require: > > MB>Update ietf-pals-ple reference [cs] done > MB> I think you need to distinguish "transport" in this context from "packet > transport" as was defined in the context of MPLS-TP (see RFC5654), which also > defines bidirectional co-routed paths that meet the requirements below. [cs] I changed “transport services” to “packet transport services”, is this enough? > * Persistent end-to-end bidirectional traffic engineered paths that > provide predictable and identical latency in both directions > > * A requested amount of bandwidth per path that is assured > irrespective of changing network utilization other services > > * Fast end-to-end protection and restoration mechanisms > > * Monitoring and maintenance of path integrity > > * Data plane remaining up while control plane is down > > Such a "transport centric" behavior is referred to as "circuit-style" > in this document. > > This document describes how Segment Routing (SR) Policies [RFC9256] > and adjacency segment identifiers (adjacency-SIDs) defined in the SR > architecture [RFC8402] together with a centralised controller such as > a stateful Path Computation Element (PCE) [RFC8231] can be used to > satisfy those requirements. It includes how end-to-end recovery and > path integrity monitoring can be implemented. > > A "Circuit-Style" SR Policy (CS-SR Policy) is an association of two > co-routed unidirectional SR Policies satisfying the above > requirements and allowing for a single SR network to carry both > typical IP (connection-less) services and connection-oriented > transport services. > > 2. Requirements Notation > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. > > 3. Terminology > > * BSID : Binding Segment Identifier > > * CS-SR : Circuit-Style Segment Routing > > Schmutzer, et al. Expires 26 December 2025 [Page 3] > > Internet-Draft CS-SR Policy June 2025 > > * DWDM : Dense Wavelength Division Multiplexing > > * ID : Identifier > > * LSP : Label Switched Path > > * LSPA : LSP Attributes > > * NRP : Network Resource Partition > > * OAM : Operations, Administration and Maintenance > > * OF : Objective Function > > * PCE : Path Computation Element > > * PCEP : Path Computation Element Communication Protocol > > * PT : Protection Type > > * SID : Segment Identifier > > * SLA : Service Level Agreement > > * SDH : Synchronous Digital Hierarchy > > * SONET : Synchronous Optical Network > > * SR : Segment Routing > > * STAMP : Simple Two-Way Active Measurement Protocol > > * TI-LFA : Topology Independent Loop Free Alternate > > * TLV : Type Length Value > > 4. Reference Model > > The reference model for CS-SR Policies follows the SR architecture > [RFC8402] and SR Policy architecture [RFC9256] and is depicted in > Figure 1. > > Schmutzer, et al. Expires 26 December 2025 [Page 4] > > Internet-Draft CS-SR Policy June 2025 > > +----------------+ > +-------------->| controller |<------------+ > | +----------------+ | > PCEP/BGP/config PCEP/BGP/config > | | > v <<<<<<<<<<<<<< CS-SR Policy >>>>>>>>>>>>> v > +-------+ +-------+ > | |=========================================>| | > | A | SR Policy from A to Z | Z | > | |<=========================================| | > +-------+ SR Policy from Z to A +-------+ > > Figure 1: Circuit-style SR Policy Reference Model > > Given the nature of CS-SR Policies, paths are computed and maintained > by a centralized entity providing a consistent simple mechanism for > initializing the co-routed bidirectional end-to-end paths, performing > bandwidth allocation control, as well as monitoring facilities to > ensure SLA compliance for the live of the CS-SR Policy. > > CS-SR Policies can be instantiated in the headend routers using PCEP, > BGP or configuration. > > * When using PCEP as the communication protocol on the headend > > MB> I think you mean "communication protocol between the controller and the > headend routers" [cs] Yes, I reworded the this list and the previous sentence to hopfully make this more clear and uniform across the 3 options with as little repitition as possible > routers, the centralized entity is a stateful PCE defined in > [RFC8231]. When using SR-MPLS [RFC8660], PCEP extensions defined > in [RFC8664] are used. When using SRv6 [RFC8754] [RFC8986], PCEP > extensions defined in [RFC9603] are used. > > * When using BGP as the communication protocol on the headend > routers, the BGP extensions defined in > [I-D.ietf-idr-sr-policy-safi] are used. > > * When using configuration, the YANG model defined in > [I-D.ietf-spring-sr-policy-yang] does apply. > > MB> Why are you appearing to mandate this particular device model, when many > other industry standard models (such as OpenConfig) could apply? Also I find > the terminology "...does apply" to be imprecise. Perhaps you mean "MAY > apply."? [cs] Good point about being too particular. I reworded to be more generic and even added BGP-LS as a potential way to report state. > In order to satisfy the requirements of CS-SR Policies, each link in > the topology MUST have: > > * An adjacency-SID which is: > > - Manually assigned or auto-generated, but persistent: to ensure > that its value does not change after a node reload > > MB> I am ot sure that "node reload" is common terminology. Perhaps "node > reboot > or other event that may cause dynamic state changes in a node." [cs] reworded > - Non-protected: to avoid any local TI-LFA protection to happen > upon interface/link failures > > MB> Add a reference? [cs] added a link to the ti-lfa draft > * The bandwidth available for CS-SR Policies specified > > Schmutzer, et al. Expires 26 December 2025 [Page 5] > > Internet-Draft CS-SR Policy June 2025 > > * A per-hop behavior ([RFC3246] or [RFC2597]) that ensures that the > specified bandwidth is always available to CS-SR Policies > independent of any other traffic > > MB> I suggest added '.' to the end of each list item above, to be consistent. > This comment applies throughout the rest of the draft. Theer are also many > other sentences missing their full stop / period. [cs] done and will look for missing dots throughout > When using link bundles (i.e. [IEEE802.1AX]), parallel physical links > are only represented via a single adjacency. To ensure deterministic > traffic placement onto physical links, an adjacency-SID SHOULD be > assigned to each physical link (aka member-link) ([RFC8668], > [RFC9356]). Similarly, the use of adjacency-SIDs representing > parallel adjacencies Section 3.4.1 of [RFC8402] SHOULD also be > avoided. > > When using SR-MPLS [RFC8660], existing IGP extensions defined in > [RFC8667] and [RFC8665] and BGP-LS defined in [RFC9085] can be used > to distribute the topology information including those persistent and > unprotected adjacency-SIDs. > > When using SRv6 [RFC8754], the IGP extensions defined in [RFC9352] > and [RFC9513] and BGP-LS extensions in [RFC9514] apply. > > 4.1. Managing Bandwidth > > In a network, resources are represented by links of certain > bandwidth. In a circuit switched network such as SONET/SDH, OTN or > DWDM resources (timeslots or a wavelength) are allocated for a > provisioned connection at the time of reservation even if no > communication is present. In a packet switched network, resources > are only allocated when communication is present, i.e. packets are to > be sent. This allows for the total reservations to exceed the link > bandwidth as well in general for link congestion. > > To satisfy the bandwidth requirement for CS-SR Policies it must be > ensured that packets carried by CS-SR Policies can always be sent up > to the reserved bandwidth on each hop along the path. > > This is done by: > > * Firstly, CS-SR Policy bandwidth reservations per link must be > limited to equal or less than the physical link bandwidth. > > * Secondly, ensuring traffic for each CS-SR Policy is limited to the > bandwidth reserved for that CS-SR Policy by traffic policing or > shaping and admission control on the ingress of the pseudowire. > > * Thirdly, ensuring that during times of link congestion only non- > CS-SR Policy traffic is being buffered or dropped. > > For the third step several approaches can be considered: > > Schmutzer, et al. Expires 26 December 2025 [Page 6] > > Internet-Draft CS-SR Policy June 2025 > > * Allocate a dedicated physical link of bandwidth P to CS-SR > Policies and allow CS-SR reservations up to bandwidth C. Consider > bandwidth N allocated for network control, ensure that P - N >= C > > * Allocate a dedicate logical link (i.e. 801.q VLAN on ethernet) to > CS-SR Policies on a physical link of bandwidth P. Limit the total > utilization across all other logical links to bandwidth O by > traffic policing or shaping and ensure that P - N - O >= C > > * Allocate a dedicated Diffserv codepoint to map traffic of CS-SR > Policies into a specific queue not used by any other traffic > > * Use of dedicated persistent unprotected adjacency-SIDs that are > solely used by CS-SR traffic. These dedicated SIDs used by CS-SR > Policies MUST NOT be used by features such as TI-LFA > [I-D.ietf-rtgwg-segment-routing-ti-lfa] for defining the repair > path and microloop avoidance > [I-D.bashandy-rtgwg-segment-routing-uloop] for defining the loop- > free path. > > MB> For this: "Use of dedicated persistent unprotected adjacency-SIDs that are > solely used by CS-SR traffic" How would this work? I don't think there is > anything in a SID in a segment list that says it was originated by a > CS-SR Policy. And in principle an adjacency SID programmed at a router > can be used by any other kind of segment routing path. Perhaps you mean > that this is a network wide policy? [cs] yes it is a network wide “policy” / “design” wherein the “how” is out of scope for this document. Added wording to make it clear > The approach of allocating a Diffserv codepoint can leverage any of > the following Per-Hop Behavior (PHB) strategies below, where P is the > bandwidth of a physical link, N is the bandwidth allocated for > network control and C is the bandwidth reserved for CS-SR policies: > > * Use a Assured Forwarding (AF) class queue [RFC2597] for CS-SR > Policies and limit the total utilization across all other queues > to bandwidth O by traffic policing or shaping and ensure that P - > N - O >= C > > * Use a Expedited Forwarding (EF) class queue [RFC3246] for CS-SR > Policies and limit the total utilization across all other EF > queues of higher or equal priority to bandwidth O by traffic > policing or shaping and ensure that P - N - O >= C > > * Use a Expedited Forwarding (EF) class queue for CS-SR Policies > with a priority higher than all other EF queues and limit the > utilization of the CS-SR Policy EF queue by traffic policing to C > <= P - N > > The use of a dedicated Diffserv codepoint for CS-SR traffic requires > the marking of all traffic steered into CS-SR Policies on the ingress > with that specific codepoint consistently across the domain. > > Schmutzer, et al. Expires 26 December 2025 [Page 7] > > Internet-Draft CS-SR Policy June 2025 > > In addition, the headends may measure the actual bandwidth > utilization of a CS-SR Policy to raise alarms when bandwidth > utilization thresholds are passed or to request the reserved > bandwidth to be adjusted. Using telemetry collection the alarms or > bandwidth adjustments can also be triggered by the controller. > > MB> I suggest consistency in the sue of RFC2119 language (e.g. MAY vs may) [cs] done > 5. CS-SR Policy Characteristics > > A CS-SR Policy has the following characteristics: > > * Requested bandwidth: bandwidth to be reserved for the CS-SR Policy > > * Bidirectional co-routed: a CS-SR Policy between A and Z is an > association of an SR Policy from A to Z and an SR Policy from Z to > A following the same path(s) > > * Deterministic and persistent paths: segment lists with strict hops > using unprotected adjacency-SIDs > > * Not automatically recomputed or reoptimized: the SID list of a > candidate path MUST NOT change automatically to a SID list > representing a different path (for example upon topology change) > > * More than one candidate paths in case of protection/restoration: > > - Following the SR Policy architecture, the highest preference > valid path is carrying traffic > > - Depending on the protection/restoration scheme (Section 7), > lower priority candidate paths > > o may be pre-computed > > o may be pre-programmed > > o may have to be disjoint > > * Connectivity verification and performance measurement are > activated on each candidate path (Section 8) > > MB> Do you also need only one active segment list per candidate path, > otherwise > you may get load balancing across the segment lists, whihc I think you are > trying to avoid. [cs] CV and PM is done per segment list (this is described in later sections). Reworded the bullet to make this clear here upfront. Also added a bullet that it is recommended to only use one segment list to avoid the asymmetric load balancing concern you are raising. > 6. CS-SR Policy Creation > > 6.1. Policy Creation when using PCEP > > Schmutzer, et al. Expires 26 December 2025 [Page 8] > > Internet-Draft CS-SR Policy June 2025 > > 6.1.1. PCC-initiated Mode > > Considering the scenario illustrated in Figure 1 a CS-SR Policy > between A and Z is instantiated by configured a SR Policy on both > headend A (with Z as endpoint) and headend Z (with A as endpoint). > > Both nodes A and Z act as PCC and delegate path computation to the > PCE using PCEP with the procedure described in Section 5.7.1 of > [RFC8231]. For SR-MPLS the extensions defined in [RFC8664] are used. > And SRv6 specific extensions are defined in [RFC9603]. > > The PCRpt message sent from the headends to the PCE SHOULD contain > the following parameters: > > * BANDWIDTH object (Section 7.7 of [RFC5440]) : to indicate the > requested bandwidth > > * LSPA object (section 7.11 of [RFC5440]) : to indicate that no > local protection requirements > > - L flag set to 0 : no local protection > > - E flag set to 1 : protection enforcement (section 5 of > [RFC9488]) > > * ASSOCIATION object ([RFC8697]) : > > - Type : Double-sided Bidirectional with Reverse LSP Association > ([I-D.ietf-pce-sr-bidir-path]) > > - Bidirectional Association Group TLV ([RFC9059]) : > > o R flag is always set to 0 (forward path) > > o C flag is always set to 1 (co-routed) > > If the SR Policies are configured with more than one candidate path, > a PCEP request is sent per candidate path. Each PCEP request does > > MB> Can you be specific about which PCEP messages? Also, I assume 'does' means > 'MUST'. IF so, please clarify. [cs] changed to PCRpt. Will do accordingly in other sections as well > include the "SR Policy Association" object (type 6) as defined in > [I-D.ietf-pce-segment-routing-policy-cp] to make the PCE aware of the > candidate path belonging to the same policy. > > The signaling extensions described in > [I-D.ietf-pce-circuit-style-pcep-extensions] are used to ensure that > > MB> s/ensure that/ ensure that: [cs] done > * Path determinism is achieved by the PCE only using segment lists > representing a strict hop by hop path using unprotected adjacency- > SIDs. > > Schmutzer, et al. Expires 26 December 2025 [Page 9] > > Internet-Draft CS-SR Policy June 2025 > > * Path persistency across node reloads in the network is achieved by > the PCE only including manually configured adjacency-SIDs in its > path computation response. > > MB> PLease clarify what you mean by 'reload'. I assume you mean a 'restart' > that could flush or change dynamic state. Also, I believe 'static' is > typically > used as the term rather than 'manual' as manual implies human configuration, > which may not be the case. [cs] yes, same as before. I change the wording to be aligned with the earlier sentence. Also I realised we were using sometimes the term “router” and sometimes “node”, I change all to router for consistency > * Persistency across network changes is achieved by the PCE not > performing periodic nor network event triggered re-optimization. > > MB> s/periodic nor / periodic or / [cs] done > Bandwidth adjustment can be requested after initial creation by > signaling both requested and operational bandwidth in the BANDWIDTH > object but the PCE is not allowed to respond with a changed path. > > MB> 'not allowed' or 'MUST NOT'? [cs] MUST NOT indeed. Sorry, at some point I wasn’t sure whether normative language is supposed to be used in informational documents. Hence the inconsistency in various places. > As discussed in section 3.2 of [I-D.ietf-pce-multipath] it may be > necessary to use load-balancing across multiple paths to satisfy the > bandwidth requirement of a candidate path. In such a case the PCE > will notify the PCC to install multiple segment lists using the > signaling procedures described in section 5.3 of > [I-D.ietf-pce-multipath]. > > 6.1.2. PCE-initiated Mode > > The CS-SR Policy can be instantiated in the network between A and Z > by a PCE using PCE-initiated procedures. For PCE-initiated > procedures no SR Policy configuration is required on the PCC. The > PCE requests the PCC to initiate the candiate paths of the CS-SR > Policy. > > The PcInit message contains the same Bandwidth, LSPA, and ASSOCIATION > objects used in PCC-initiated mode. Following initiation, the > candidate paths are reported and updated following PCEP procedures > and share the same behavior as the PCC-initiated mode. > > MB> How does the PCE indicate to the PCC which proactive OAM or Performance > monitoring to use? I think this type of OAM (such as using seamless BFD to > rapidly detect failures) is very important for a transport service. If there > is > no standard mechanism today, then I suggest you explicitly state that. [cs] Added a sentence not that this is driven by local policy configuration and that there is no standard signalling mechanism available > 6.2. Policy Creation when using BGP > > Again, considering the scenario illustrated in Figure 1, instead of > configuring SR Policies on both headend A (with Z as endpoint) and > headend Z (with A as endpoint), a CS-SR Policy between A and Z is > instantiated by a request (e.g. application API call) to the > centralized controller. > > The controller does perform path computation and is requesting the > headends via BGP to instantiate the corresponding SR Policies on > them. > > MB> Suggest rephrasing to "The controller performs path computation and > advertises the corresponding SR Policies to the head end routers via BGP." [cs] reworded per suggestion > To instantiate the SR Policies in A and Z the BGP extensions defined > in [I-D.ietf-idr-sr-policy-safi] are used. > > No signaling extensions are required for the following: > > Schmutzer, et al. Expires 26 December 2025 [Page 10] > > Internet-Draft CS-SR Policy June 2025 > > * Path determinism is achieved by the controller only using segment > lists representing a strict hop by hop path using unprotected > adjacency-SIDs. > > MB> Suggest rephrasing to: "Path determinism is achieved by the controller > only > computing strict paths and only including unprotected adjacency SIDs in > segment > lists. Loose hops SHOULD NOT be used."" [cs] reworded > * Path persistency across node reloads in the network is achieved by > the controller only including manually configured adjacency-SIDs > in its path computation response. > > MB> As mentioned above, please clarify 'node reloads' [cs] aligned with previous instances > * Persistency across network changes is achieved by the controller > not performing periodic nor network event triggered re- > optimization. > > MB> s/the controller not performing periodic nor network event triggered re- > optimization. / he controller not performing periodic or network event > triggered re-optimization. [cs] done > MB> I actually don't quite get this point. If the head ends support MBB, and > the new paths can be computed to meet existing service constraints and traffic > moved seamlessly on to them, then what is wrong with that? Also, IP networks > reconverge all the time... are you really saying that you would never > reoptimize, even if all of the segment lists in the programmed SR Policies go > down? [cs] that is what operators have told me. They follow a “set and forget” philosophy for the working and protect path of a service/circuit. If a failure brings down the “working” path, protection or restoration is there to ensure traffic can still be transported. They don’t like “things moving around” without tight operator control. > If there are more than one candidate paths per SR Policy required, > multiple NLRIs with different distinguisher values (see section 2.1 > of [I-D.ietf-idr-sr-policy-safi]) have to be included in the BGP > UPDATE message. > > To achieve load-balancing across multiple paths to satisfy the > bandwidth requirement of a candidate path, multiple Segment List Sub- > TLVs have to be included in the SR Policy Sub-TLV. See section 2.1 > of [I-D.ietf-idr-sr-policy-safi] > > MB> s/ [I-D.ietf-idr-sr-policy-safi] / [I-D.ietf-idr-sr-policy-safi]. [cs] done. I really seem to dislike “.”s :-) > The headends A and Z report the SR Policy states back to the > centralized controller via BGP-LS using the extension defined in > [I-D.ietf-idr-bgp-ls-sr-policy]. > > MB> YANG state is an equally viable option, so I think it would be reasonable > to use that as well. [cs] yes, added > 6.3. Maximum SID Depth Constraint > > The segment lists used by CS-SR Policy candidate paths are > constrained by the maximum number of segments a router can impose > onto a packet. > > When using SR-MPLS this constraint is called "Base MPLS Imposition > MSD" and is advertised via IS-IS [RFC8491], OSPF [RFC8476], BGP-LS > [RFC8814] and PCEP [RFC8664]. > > When using SRv6 this constraint is called "SRH Max H.encaps MSD" and > is advertised via IS-IS [RFC9352], OSPF [RFC9513], BGP-LS [RFC9514] > and PCEP [RFC9603]. > > The MSD constraint is typically resolved by leveraging a segment list > reduction technique, such as using Node SIDs and/or BSIDs (SR > architecture [RFC8402]) in a segment list, which represents one or > many hops in a given path. > > Schmutzer, et al. Expires 26 December 2025 [Page 11] > > Internet-Draft CS-SR Policy June 2025 > > As described in Section 5, adjacency-SIDs without local protection > are to be used for CS-SR Policies to ensure no ECMP, no rerouting due > to topological changes nor localized protection is being invoked on > the traffic, as the alternate path may not be providing the desired > SLA. > > MB> Suggest rephrasing to: "As described in Section 5, adjacency-SIDs without > local protection are used in CS-SR Policies to ensure that there is no per-hop > ECMP, no localized rerouting due to topological changes, and no invocation of > localized protection mechanisms, as alternate paths may not meet the desired > SLA." [cs] reworded > If a CS-SR Policy path requires SID List reduction, a Node SID cannot > be utilized > > MB> I think you mean "...a Node SID cannot be used as the final SID in a > segment list..." but I am not sure the following always follows. So all you > need to say is that "If a CS-SR Policy path requires SID List reduction, a > binding SID (BSID) can be programmed to a transit node, if the following > requirements are met:" [cs] Good suggestion. The initial intent of this wording was to relate to the paragraph before “The MSD constraint is typically resolved …” … but I agree it makes the sentence harder to read or unclear. > as it is eligible for traffic rerouting following IGP re- > convergence. However, a BSID can be programmed to a transit node, if > the following requirements are met: > > * The BSID is unprotected, hence only has one candidate path > > * The BSID follows the rerouting and optimization characteristics > defined in Section 5 which implies the SID list of the candidate > path MUST only use unprotected adjacency-SIDs. > > MB> Please ensure that the usage of '.' at the end of each list item is > consistent. [cs] oh boy I am getting embarrassed > This ensures that any CS-SR Policies in which the BSID provides > transit for do not get rerouted due to topological changes or > protected due to failures. A BSID may be pre-programmed in the > network or automatically injected in the network by a PCE. > > MB> A BSID is a is fundamentally part of the SR Policy route or the > configuration of the SR Policy. ALso, it is not the BSID that provides transit > but rather the SR Policy that it is associated with at the transit router. I > suggest rephrasing the above to not imply that it is somehow independent of > the > SR Policy programmed at the transit router. [cs] good point, we are leasurely using BSID instead of SR policy here, even in the bulleted list and sentence before. I have changed this accordingly > 7. Recovery Schemes > > Various recovery (protection and restoration) schemes can be > implemented for a CS-SR Policy. As described in Section 4.3 of > [RFC4427], there is a subtle distinction between the terms > "protection" and "restoration" based on the resource allocation done > during the recovery path establishment. The same definitions apply > for CS-SR Policy recovery schemes, wherein: > > * Protection: another candidate path is computed and fully > established in the data plane and ready to carry traffic > > * Restoration: a candidate path may be computed and may be partially > established but is not ready to carry traffic > > The term "failure" is used to represent both "hard failures" such > complete loss of connectivity detected by connectivity verification > > MB> or continuity check... [cs] verify good catch! we mixed up “connectivity verification” and “continuity check”. Changing throughout the document > described in Section 8.1 or degradation, i.e., when the packet loss > ratio increased beyond a configured acceptable threshold. > > 7.1. Unprotected > > In the most basic scenario, no protection nor restoration is > required. The CS-SR Policy has only one candidate path configured. > This candidate path is established, activated and is carrying > traffic. > > Schmutzer, et al. Expires 26 December 2025 [Page 12] > > Internet-Draft CS-SR Policy June 2025 > > When using PCEP, a PCRpt message is sent from the PCC to the PCE with > the O field in the LSP object Section 7.3 of [RFC8231] set to 2 to > indicate the candidate path is active and carrying traffic. > > When using BGP, a BGP-LS update is sent from the headend to the > centralized controller with the SR Candidate Path State TLV of the SR > Policy Candidate Path NLRI having the > > * C-Flag set to 1 to indicate the candidate path was provisioned by > the controller > > * A-Flag set to 1 to indicate the candidate path is active and > carrying traffic > > In case of a failure along the path the CS-SR Policy will go down and > traffic will not be recovered. > > Typically, two CS-SR Policies are deployed either within the same > network with disjoint paths or in two separate networks and the > overlay service is responsible for traffic recovery. > > 7.2. 1:1 Protection > > For fast recovery against failures the CS-SR Policy has two candidate > paths. Both paths are established but only the candidate with higher > preference is activated and is carrying traffic. The second > candidate path is programmed as backup in the forwarding plane as > described in Section 9.3 of [RFC9256]. > > When using PCEP, the PCRpt message for the candidate path with higher > preference will have the O field in the LSP object set to 2 to > indicate the candidate path is active and carrying traffic. For the > candidate path with the lower preference the O field in the LSP > object is set to 1 to indicate the candidate path is signaled but not > carrying traffic. > > Appropriate diverse routing of the candidate path with lower > preference from the candidate path with higher preference can be > requested from the PCE by using the "Disjointness Association" object > (type 2) defined in [RFC8800] in the PCRpt messages. The disjoint > requirements are communicated in the "DISJOINTNESS-CONFIGURATION TLV" > > * L bit set to 1 for link diversity > > * N bit set to 1 for node diversity > > * S bit set to 1 for SRLG diversity > > Schmutzer, et al. Expires 26 December 2025 [Page 13] > > Internet-Draft CS-SR Policy June 2025 > > * T bit set to enforce strict diversity > > The P bit may be set for the candidate path with higher preference to > allow for finding the best path for it that does satisfy all > constraints without considering diversity to the candidate path with > the lower preference. > > The "Objective Function (OF) TLV" as defined in section 5.3 of > [RFC8800] may also be added to minimize the common shared resources. > > When using BGP, the controller is already aware of the disjoint > requirements and does consider them while computing both paths. Two > NLRIs with different distinguisher values and different preference > values are included in the BGP UPDATE sent to the headend routers. > > MB> Isn't this also the case for PCE initiated SR Policies. That is, the > controller is aware apriori of the candidate path diversity requirements? I > suggest reorganising this section, or making it clear which PCEP statements > apply to PCC initiated and which to PCE initiated cases. [cs] agree we missed that when adding PCE-init mode to the draft. I explicitly mention now PCC-initiated mode for the paragraph talking about diversity requirements > A BGP-LS update is sent to the controller with a SR Policy Candidate > Path NLRI for the candidate path with higher preference where the SR > Candidate Path State TLV is having the > > * C-Flag set to 1 to indicate that candidate path was provisioned by > the controller > > * A-Flag set to 1 to indicate the candidate path is active and > carrying traffic > > and another SR Policy Candidate Path NLRI for the candidate path with > lower preference where the SR Candidate Path State TLV is having the > > * C-Flag set to 1 to indicate the candidate path was provisioned by > the controller > > * B-Flag set to 1 to indicate the role of backup path > > MB> Isn't the above only needed if the controller did not program the SR > Policies , and they were originated by some other BGP speaker? [cs] the headends are controlling the candidate path state and need to stay in sync with the controller > Upon a failure impacting the candidate path with higher preference > carrying traffic, the candidate path with lower preference is > activated immediately and traffic is now sent across it. > > When using PCEP a PCRpt message for the higher preference candidate > path is sent to the PCE with the O field changed from 2 to 0 and a > PCRpt message for the lower preference candidate path with the O > field change from 1 to 2. > > When using BGP a BGP-LS update is sent to the controller with a SR > Policy Candidate Path NLRI for the candidate path with higher > preference with the SR Candidate Path State TLV having the A-Flag > cleared and another BGP-LS update for the candidate path with lower > preference with the SR Candidate Path State TLV having the B-Flag > cleared and A-Flag set to 1. > > Schmutzer, et al. Expires 26 December 2025 [Page 14] > > Internet-Draft CS-SR Policy June 2025 > > Protection switching is bidirectional. As described in Section 8.1, > both headends will generate and receive their own loopback mode test > packets, hence even a unidirectional failure will always be detected > by both headends without protection switch coordination required. > > 7.2.1. Reversion > > Two cases are to be considered when the failure(s) impacting a > candidate path with higher preference are cleared: > > * Revertive switching: re-activate the higher preference candidate > path and start sending traffic over it > > * Non-revertive switching: do not activate the higher preference > candidate path and keep sending traffic via the lower preference > candidate path > > When using PCEP, for revertive switching a PCRpt message for the > recovered higher preference candidate path is sent to the PCE with > the O field changed from 0 to 2 and send a PCRpt message for the > lower preference candidate path with the O field changed from 2 to 1. > For non-revertive switching only a PCRpt message for the recovered > higher preference candidate path with the O field set to 1 is sent. > > When using BGP and revertive switching a BGP-LS update is sent to the > controller with a SR Policy Candidate Path NLRI for the recovered > higher preference candidate path with the SR Candidate Path State TLV > having the A-Flag set to 1 and another BGP-LS update with a SR Policy > Candidate Path NLRI for the lower preference candidate path with the > SR Candidate Path State TLV having the A-Flag cleared and B-Flag set > to 1. For non-revertive switching only a BGP-LS update with a SR > Policy Candidate Path NLRI for the higher preference candidate path > with the SR Candidate Path State TLV having the B-Flag set to 1 is > sent. > > 7.3. Restoration > > 7.3.1. 1+R Restoration > > MB> I dont see 1+R defined in RFC4427 referenced above. Is this something new > to CS-SR Policy, or is there an external definition of the recovery > architecture that you can reference? I am not sure this is really any > different > from RFC4427 section 7.2.2 "LSP Soft Restoration", but the structure fo the > text below is a bit confusing. MB> Maybe you could explain more about he > recovery architecture and then go into the PCEP and BGP signaling details. > Also, you don't distinguish PCE Initiated from the PCC initiated case below. I > assume for PCE initiated the controller programs a new candidate path after > the > failure is detected, but in the PCC initiated case a candidate path is already > programmed but not activated, and then the router requests a new path from the > PCE after the failure is detected? [cs] 1+R is defined in RFC8131 and you are right is it pretty much what 7.2.2 is in RFC4427. Fyi, I had a reference to it in the past, but removed it at some point. Maybe to avoid confusion between 1+1+R defined in RFC8131 and 1:1+R as we define it in this document. When thinking about how to address your comment I realised maybe the follow structure per recovery scheme makes sense 1. Intro paragrap explaining the scheme 2. Three subsections explaing the protocol procedures a. Setup b. Failure c. Reversion What do you think about those changes? > Compared to 1:1 protection described in Section 7.2, this restoration > scheme avoids pre-allocating protection bandwidth in steady state, > while still being able to recover traffic flow in case of a network > failure in a deterministic way (maintain required bandwidth > commitment) > > MB> Suggest rephrasing to "(and therefore maintaining the required bandwidth > commitment)." [cs done > Schmutzer, et al. Expires 26 December 2025 [Page 15] > > Internet-Draft CS-SR Policy June 2025 > > When using PCEP, the CS-SR Policy is configured with two candidate > paths. The candidate path with higher preference is established, > activated (O field in LSP object is set to 2) and is carrying > traffic. > > The second candidate path with lower preference is only established > and activated (PCRpt message to the PCE with O field in LSP object is > set to 2) upon a failure impacting the first candidate path in order > to send traffic over an alternate path through the network around the > failure with potentially relaxed constraints but still satisfying the > bandwidth commitment. > > The second candidate path is generally only requested from the PCE > and activated after a failure, but may also be requested and pre- > established during CS-SR Policy creation with the downside of > bandwidth being set aside ahead of time. > > As soon as failure(s) that brought the first candidate path down are > cleared, the second candidate path is getting deactivated (PCRpt > message to the PCE with O field in LSP object is set to 1) or torn > down. The first candidate path is activated (PCRpt message to the > PCE with O field in LSP object is set to 2) and traffic sent across > it. > > When using BGP, the controller does compute one path and does include > one NLRI in the BGP UPDATE message sent to the headend routers to > instantiate the CS-SR Policy with one candidate path active and > carrying traffic. > > A BGP-LS update with a SR Policy Candidate Path NLRI is sent to the > controller with the SR Candidate Path State TLV having the > > * C-Flag set to 1 to indicate the candidate path was provisioned by > the controller > > * A-Flag set to 1 to indicate the candidate path is active and > carrying traffic > > Upon the controller detecting the failure of the CS-SR Policy's > candidate path, another path is computed and added as second > candidate path to the CS-SR Policy by sending a BGP UPDATE message to > the headend routers with a SR Policy Candidate Path NLRI where the > distinguisher value being different and preference being lower > compared to the first candidate path. > > A BGP-LS update with a SR Policy Candidate Path NLRI for the > candidate path with higher preference is sent to the controller with > the SR Candidate Path State TLV having the > > Schmutzer, et al. Expires 26 December 2025 [Page 16] > > Internet-Draft CS-SR Policy June 2025 > > * A-Flag is cleared to indicate the candidate path is no longer > active and not carrying traffic anymore > > and another SR Policy Candidate Path NLRI for the candidate path with > lower preference with the SR Candidate Path State TLV having the > > * C-Flag set to 1 to indicate the candidate path was provisioned by > the controller > > * A-Flag set to 1 to indicate the candidate path is active and > carrying traffic > > The second candidate path is generally only instantiated by the > controller and activated after a failure, but may also be > instantiated and pre-established during CS-SR Policy creation with > the downside of bandwidth being set aside ahead of time. If so, a > BGP-LS update with a SR Policy Candidate Path NLRI is sent to the > controller with the SR Candidate Path State TLV having the > > * C-Flag set to 1 to indicate the candidate path was provisioned by > the controller > > * B-Flag set to 1 to indicate the role of backup path > > Once the controller has detected the failure(s) that brought the > first candidate path down are cleared, a BGP-LS update with a SR > Policy Candidate Path NLRI for the first candidate path is sent to > the controller with the SR Candidate Path State TLV having the > > * A-Flag set to 1 to indicate the candidate path became active and > is carrying traffic again > > The second candidate path is getting removed by a BGP UPDATE message > withdrawing the SR Policy Candidate Path NLRI of the second candidate > path. > > Restoration and reversion behavior is bidirectional. As described in > Section 8.1, both headends use connectivity verification in loopback > mode and therefore even in case of unidirectional failures both > headends will detect the failure or clearance of the failure and > switch traffic away from the failed or to the recovered candidate > path. > > Schmutzer, et al. Expires 26 December 2025 [Page 17] > > Internet-Draft CS-SR Policy June 2025 > > 7.3.2. 1:1+R Restoration > > For further resiliency in case of multiple concurrent failures that > could affect both candidate paths of 1:1 protection described in > Section 7.2, a third candidate path with a preference lower than the > other two candidate paths is added to the CS-SR Policy to enable > restoration. > > When using PCEP, the third candidate path will generally only be > established, activated (PCRpt message to the PCE with O field in LSP > object is set to 2) and carry traffic after failure(s) have impacted > both the candidate path with highest and second highest preference. > > The third candidate path may also be requested and pre-computed > already whenever either the first or second candidate path went down > due to a failure with the downside of bandwidth being set aside ahead > of time. > > As soon as failure(s) that brought either the first or second > candidate path down are cleared, the affected candidate path is > activated again (PCRpt message to the PCE with O field in LSP object > is set to 2). The third candidate path is to be deactivated (PCRpt > message to the PCE with O field in LSP object is set to 1). > > When using BGP, the third candidate path will generally only be > instantiated by the controller and activated after failure(s) have > impacted both the candidate path with highest and second highest > preference, but may also be instantiated and pre-established during > CS-SR Policy creation with the downside of bandwidth being set aside > ahead of time. > > Assuming the case where both candidate paths are down, a BGP-LS > update is sent with SR Policy Candidate Path NLRIs for the first and > second candidate path with the SR Candidate Path State TLV having the > > * A-Flag cleared > > and a SR Policy Candidate Path NLRI for the third candidate path with > the SR Candidate Path State TLV having the > > * C-Flag set to 1 to indicate the candidate path was provisioned by > the controller > > * A-Flag set to 1 to indicate the candidate path is active and > carrying traffic > > Schmutzer, et al. Expires 26 December 2025 [Page 18] > > Internet-Draft CS-SR Policy June 2025 > > Assuming the case where only one candidate path is down, a BGP-LS > update is sent with a SR Policy Candidate Path NLRI for the failed > candidate path with the SR Candidate Path State TLV having the > > * A-Flag cleared > > a SR Policy Candidate Path NLRI for the second candidate path with > the SR Candidate Path State TLV having the > > * A-Flag set to 1 to indicate it is active and carrying traffic > network > > and another SR Policy Candidate Path NLRI for the newly installed > third candidate path with the SR Candidate Path State TLV having the > > * C-Flag set to 1 to indicate the candidate path was provisioned by > the controller > > * B-Flag set to 1 to indicate the role of backup path > > Once the controller has detected the failure(s) that brought either > the first or the second candidate path down are cleared, a BGP-LS > update with a SR Policy Candidate Path NLRI for the affected > candidate path is sent to the controller with the SR Candidate Path > State TLV having the > > * A-Flag set to 1 to indicate the candidate path became active again > > The third candidate path is getting removed by a BGP UPDATE message > withdrawing the SR Policy Candidate Path NLRI of the third candidate > path. > > Again, restoration and reversion behavior is bidirectional. As > described in Section 8.1, both headends use connectivity verification > in loopback mode and therefore even in case of unidirectional > failures both headends will detect the failure or clearance of the > failure and switch traffic away from the failed or to the recovered > candidate path. > > 8. Operations, Administration, and Maintenance (OAM) > > Schmutzer, et al. Expires 26 December 2025 [Page 19] > > Internet-Draft CS-SR Policy June 2025 > > 8.1. Connectivity Verification > > The connectivity verification for each segment list on both headends > MAY be done using the Simple Two-Way Active Measurement Protocol > (STAMP) (in loopback measurement mode as described in section 6 of > [I-D.ietf-spring-stamp-srpm]) or Bidirectional Forwarding Detection > (BFD) [RFC5880]. The use of STAMP is RECOMMENDED as it leverages a > single protocol session to be used for both connectivity verification > and performance measurement (see Section 8.2 of this document). > > MB> You don't mention seamless BFD here, but that is commonly used for CC as > it > is lightweight and allows extremely rapid detection of failures (<50ms) which > is a requirement of transport services. I would suggest adding that as an > option. [cs] good point, I added it > As the STAMP test packets are including both the segment list of the > forward and reverse path, standard segment routing data plane > operations will make those packets get forwarded along the forward > path to the tailend and along the reverse path back to the headend. > > In order to be able to send STAMP test packets for loopback > measurement mode, the STAMP Session-Sender (i.e., the headend) needs > to acquire the segment list information of the reverse path: > > * When using PCEP, the headend forms the bidirectional SR Policy > association using the procedure described in > [I-D.ietf-pce-sr-bidir-path] and receives the information about > the reverse segment list from the PCE as described in section 4.5 > of [I-D.ietf-pce-multipath] > > * When using BGP, the controller does inform the headend routers > about the reverse segment list using the Reverse Segment List Sub- > TLV defined in section 4.1 of > [I-D.ietf-idr-sr-policy-path-segment]. > > For cases where multiple segment lists are used by a candidate path, > the headends will declare a candidate path down after connectivity > verification has failed for one or more segment lists because the > bandwidth requirement of the candidate path can no longer be met. > > 8.2. Performance Measurement > > The same STAMP session used for connectivity verification is used to > estimate round-trip loss as described in section 5 of > [I-D.ietf-spring-stamp-srpm] and can be used to measure delay as > well. > > As loopback mode is used, only round-trip delay can be measured. > Considering that candidate paths are co-routed, the delay in the > forward and reverse direction can be assumed to be identical. Under > this assumption, one-way can be derived by dividing the round-trip > delay by two. > > Schmutzer, et al. Expires 26 December 2025 [Page 20] > > Internet-Draft CS-SR Policy June 2025 > > 8.3. Candidate Path Validity Verification > > A stateful PCE/controller is in sync with the headend routers in the > network topology and the CS-SR Policies provisioned on them. As > described in Section 5 a path MUST NOT be automatically recomputed > after or optimized for topology changes. > > MB> Do you mean automatically recomputed by the network or the controller? [cs] I added “by the controller” to be clear. > If > the controller, then surely this is contradicts the following paragraph? [cs] tearing down a path is fine, re-computing not (except restoration paths … added this now). What this sentence is trying to say is that there may be cases where the headends can’t detect that the requirements are no longer met. Imagine a case where PCE identifies the paths are violating some form of SLA that is not understood by the headend or needs to make higher priority traffic use the capacity. The PCE cannot move the path, but it is permitted to tear it down. > However, there may be a requirement for the stateful PCE/controller > to tear down a path if the path no longer satisfies the original > requirements, as detected by the stateful PCE/controller, such as > insufficient bandwidth, diversity constraint no longer met or latency > constraint exceeded. > > For a CS-SR Policy configured with multiple candidate paths, a > headend may switch to another candidate path if the stateful PCE/ > controller decided to tear down the active candidate path. > > 9. External Commands > > External commands are typically issued by an operator to control the > candidate path state of a CS-SR Policy using the management interface > of: > > * Headends: When the CS-SR Policy was instantiated via configuration > or PCEP PCC-initiated mode > > * PCE/controller: When the CS-SR Policy was instantiated via BGP or > PCEP PCE-initiated mode > > 9.1. Candidate Path Switchover > > It is very common to allow operators to trigger a switch between > candidate paths even if no failure is present, e.g., to proactively > drain a resource for maintenance purposes. > > A operator triggered switching request between candidate paths on a > headend is unidirectional and SHOULD be requested on both headends. > > MB> I assume you also mean simultaneously? [cs] it doesn’t need to be simultaneously (exact at the same time), but you want to get back to a state where traffic is co-routed again. I reworded to make this more clear > 9.2. Candidate Path Re-computation > > While no automatic re-optimization or pre-computation of CS-SR Policy > candidate paths is allowed as specified in Section 5, network > operators trying to optimize network utilization may explicitly > request a candidate path to be re-computed at a certain point in > time. > > Schmutzer, et al. Expires 26 December 2025 [Page 21] > > Internet-Draft CS-SR Policy June 2025 > > 10. Security Considerations > > This document does provide guidance on how to implement a CS-SR > Policy leveraging existing mechanisms and protocol extensions. As > such, it does not introduce any new security considerations. > > Security considerations for the SR Policy Architecture defined in > Section 10 of [RFC9256] do apply to this document. > > Depending on how a CS-SR Policy is instantiated and reported, the > following security considerations do apply > > * PCEP: > > - Section 7 of [RFC8664] > > - Section 6 of [RFC9603] > > - Section 8 of [I-D.ietf-pce-segment-routing-policy-cp] > > - Section 6 of [I-D.ietf-pce-sr-bidir-path] > > - Section 7 of [I-D.ietf-pce-circuit-style-pcep-extensions] > > - Section 10 of [I-D.ietf-pce-multipath] > > - Section 8 of [I-D.ietf-idr-sr-policy-path-segment] > > * BGP: > > - Section 7 of [I-D.ietf-idr-sr-policy-safi] > > - Section 9 of [I-D.ietf-idr-bgp-ls-sr-policy] > > * Configuration: > > - Section 8 of [I-D.ietf-spring-sr-policy-yang] > > Depending on the protocol used for OAM, the following security > considerations do apply > > * STAMP: Section 15 of [I-D.ietf-spring-stamp-srpm] > > * BFD: Section 9 of [RFC5880] > > Schmutzer, et al. Expires 26 December 2025 [Page 22] > > Internet-Draft CS-SR Policy June 2025 > > 11. IANA Considerations > > This document has no IANA actions. > > 12. Acknowledgements > > The author's want to thank Samuel Sidor, Mike Koldychev, Rakesh > Gandhi, Alexander Vainshtein, Tarek Saad, Ketan Talaulikar and Yao > Liu for providing their review comments, Yao Liu for her very > detailed shepherd review and all contributors for their inputs and > support. > > 13. References > > 13.1. Normative References > > [I-D.ietf-idr-bgp-ls-sr-policy] > Previdi, S., Talaulikar, K., Dong, J., Gredler, H., and J. > Tantsura, "Advertisement of Segment Routing Policies using > BGP Link-State", Work in Progress, Internet-Draft, draft- > ietf-idr-bgp-ls-sr-policy-17, 6 March 2025, > <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp- > ls-sr-policy-17>. > > [I-D.ietf-idr-sr-policy-path-segment] > Li, C., Li, Z., Yin, Y., Cheng, W., and K. Talaulikar, "SR > Policy Extensions for Path Segment and Bidirectional > Path", Work in Progress, Internet-Draft, draft-ietf-idr- > sr-policy-path-segment-13, 2 October 2024, > <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr- > policy-path-segment-13>. > > [I-D.ietf-idr-sr-policy-safi] > Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and > D. Jain, "Advertising Segment Routing Policies in BGP", > Work in Progress, Internet-Draft, draft-ietf-idr-sr- > policy-safi-13, 6 February 2025, > <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr- > policy-safi-13>. > > [I-D.ietf-pce-circuit-style-pcep-extensions] > Sidor, S., Maheshwari, P., Stone, A., Jalil, L., and S. > Peng, "Path Computation Element Communication Protocol > (PCEP) extensions for Circuit Style Policies", Work in > Progress, Internet-Draft, draft-ietf-pce-circuit-style- > pcep-extensions-08, 5 May 2025, > <https://datatracker.ietf.org/doc/html/draft-ietf-pce- > circuit-style-pcep-extensions-08>. > > Schmutzer, et al. Expires 26 December 2025 [Page 23] > > Internet-Draft CS-SR Policy June 2025 > > [I-D.ietf-pce-multipath] > Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., > Bidgoli, H., Yadav, B., Peng, S., and G. S. Mishra, "PCEP > Extensions for Signaling Multipath Information", Work in > Progress, Internet-Draft, draft-ietf-pce-multipath-13, 9 > April 2025, <https://datatracker.ietf.org/doc/html/draft- > ietf-pce-multipath-13>. > > [I-D.ietf-pce-segment-routing-policy-cp] > Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng, > S., and H. Bidgoli, "Path Computation Element > Communication Protocol (PCEP) Extensions for Segment > Routing (SR) Policy Candidate Paths", Work in Progress, > Internet-Draft, draft-ietf-pce-segment-routing-policy-cp- > 27, 4 April 2025, <https://datatracker.ietf.org/doc/html/ > draft-ietf-pce-segment-routing-policy-cp-27>. > > [I-D.ietf-pce-sr-bidir-path] > Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, > "Path Computation Element Communication Protocol (PCEP) > Extensions for Associated Bidirectional Segment Routing > (SR) Paths", Work in Progress, Internet-Draft, draft-ietf- > pce-sr-bidir-path-15, 13 February 2025, > <https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr- > bidir-path-15>. > > [I-D.ietf-spring-sr-policy-yang] > Raza, S. K., Saleh, T., Zhuang, S., Voyer, D., Durrani, > M., Matsushima, S., and V. P. Beeram, "YANG Data Model for > Segment Routing Policy", Work in Progress, Internet-Draft, > draft-ietf-spring-sr-policy-yang-05, 25 May 2025, > <https://datatracker.ietf.org/doc/html/draft-ietf-spring- > sr-policy-yang-05>. > > [I-D.ietf-spring-stamp-srpm] > Gandhi, R., Filsfils, C., Janssens, B., Chen, M., and R. > F. Foote, "Performance Measurement Using Simple Two-Way > Active Measurement Protocol (STAMP) for Segment Routing > Networks", Work in Progress, Internet-Draft, draft-ietf- > spring-stamp-srpm-19, 20 June 2025, > <https://datatracker.ietf.org/doc/html/draft-ietf-spring- > stamp-srpm-19>. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, > <https://www.rfc-editor.org/rfc/rfc2119>. > > Schmutzer, et al. Expires 26 December 2025 [Page 24] > > Internet-Draft CS-SR Policy June 2025 > > [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation > Element (PCE) Communication Protocol (PCEP)", RFC 5440, > DOI 10.17487/RFC5440, March 2009, > <https://www.rfc-editor.org/rfc/rfc5440>. > > [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC > 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, > May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. > > [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path > Computation Element Communication Protocol (PCEP) > Extensions for Stateful PCE", RFC 8231, > DOI 10.17487/RFC8231, September 2017, > <https://www.rfc-editor.org/rfc/rfc8231>. > > [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., > Decraene, B., Litkowski, S., and R. Shakir, "Segment > Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, > July 2018, <https://www.rfc-editor.org/rfc/rfc8402>. > > [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., > Decraene, B., Litkowski, S., and R. Shakir, "Segment > Routing with the MPLS Data Plane", RFC 8660, > DOI 10.17487/RFC8660, December 2019, > <https://www.rfc-editor.org/rfc/rfc8660>. > > [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., > and J. Hardwick, "Path Computation Element Communication > Protocol (PCEP) Extensions for Segment Routing", RFC 8664, > DOI 10.17487/RFC8664, December 2019, > <https://www.rfc-editor.org/rfc/rfc8664>. > > [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., > Dhody, D., and Y. Tanaka, "Path Computation Element > Communication Protocol (PCEP) Extensions for Establishing > Relationships between Sets of Label Switched Paths > (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, > <https://www.rfc-editor.org/rfc/rfc8697>. > > [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., > Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header > (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, > <https://www.rfc-editor.org/rfc/rfc8754>. > > Schmutzer, et al. Expires 26 December 2025 [Page 25] > > Internet-Draft CS-SR Policy June 2025 > > [RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, > "Path Computation Element Communication Protocol (PCEP) > Extension for Label Switched Path (LSP) Diversity > Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800, > July 2020, <https://www.rfc-editor.org/rfc/rfc8800>. > > [RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation > Element Communication Protocol (PCEP) Extensions for > Associated Bidirectional Label Switched Paths (LSPs)", > RFC 9059, DOI 10.17487/RFC9059, June 2021, > <https://www.rfc-editor.org/rfc/rfc9059>. > > [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, > A., and P. Mattes, "Segment Routing Policy Architecture", > RFC 9256, DOI 10.17487/RFC9256, July 2022, > <https://www.rfc-editor.org/rfc/rfc9256>. > > [RFC9488] Stone, A., Aissaoui, M., Sidor, S., and S. Sivabalan, > "Local Protection Enforcement in the Path Computation > Element Communication Protocol (PCEP)", RFC 9488, > DOI 10.17487/RFC9488, October 2023, > <https://www.rfc-editor.org/rfc/rfc9488>. > > [RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M., > and Y. Zhu, "Path Computation Element Communication > Protocol (PCEP) Extensions for IPv6 Segment Routing", > RFC 9603, DOI 10.17487/RFC9603, July 2024, > <https://www.rfc-editor.org/rfc/rfc9603>. > > 13.2. Informative References > > [I-D.bashandy-rtgwg-segment-routing-uloop] > Bashandy, A., Filsfils, C., Litkowski, S., Decraene, B., > Francois, P., and P. Psenak, "Loop avoidance using Segment > Routing", Work in Progress, Internet-Draft, draft- > bashandy-rtgwg-segment-routing-uloop-17, 29 June 2024, > <https://datatracker.ietf.org/doc/html/draft-bashandy- > rtgwg-segment-routing-uloop-17>. > > [I-D.ietf-pals-ple] > Gringeri, S., Whittaker, J., Leymann, N., Schmutzer, C., > and C. Brown, "Private Line Emulation over Packet Switched > Networks", Work in Progress, Internet-Draft, draft-ietf- > pals-ple-15, 12 February 2025, > <https://datatracker.ietf.org/doc/html/draft-ietf-pals- > ple-15>. > > Schmutzer, et al. Expires 26 December 2025 [Page 26] > > Internet-Draft CS-SR Policy June 2025 > > [I-D.ietf-rtgwg-segment-routing-ti-lfa] > Bashandy, A., Litkowski, S., Filsfils, C., Francois, P., > Decraene, B., and D. Voyer, "Topology Independent Fast > Reroute using Segment Routing", Work in Progress, > Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- > 21, 12 February 2025, > <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg- > segment-routing-ti-lfa-21>. > > [IEEE802.1AX] > IEEE, "IEEE Standard for Ethernet", May 2020, > <https://ieeexplore.ieee.org/document/9105034>. > > [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, > "Assured Forwarding PHB Group", RFC 2597, > DOI 10.17487/RFC2597, June 1999, > <https://www.rfc-editor.org/rfc/rfc2597>. > > [RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le > Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. > Stiliadis, "An Expedited Forwarding PHB (Per-Hop > Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, > <https://www.rfc-editor.org/rfc/rfc3246>. > > [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery > (Protection and Restoration) Terminology for Generalized > Multi-Protocol Label Switching (GMPLS)", RFC 4427, > DOI 10.17487/RFC4427, March 2006, > <https://www.rfc-editor.org/rfc/rfc4427>. > > [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, > "Encapsulation Methods for Transport of Ethernet over MPLS > Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, > <https://www.rfc-editor.org/rfc/rfc4448>. > > [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- > Agnostic Time Division Multiplexing (TDM) over Packet > (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, > <https://www.rfc-editor.org/rfc/rfc4553>. > > [RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, > "Synchronous Optical Network/Synchronous Digital Hierarchy > (SONET/SDH) Circuit Emulation over Packet (CEP)", > RFC 4842, DOI 10.17487/RFC4842, April 2007, > <https://www.rfc-editor.org/rfc/rfc4842>. > > Schmutzer, et al. Expires 26 December 2025 [Page 27] > > Internet-Draft CS-SR Policy June 2025 > > [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and > P. Pate, "Structure-Aware Time Division Multiplexed (TDM) > Circuit Emulation Service over Packet Switched Network > (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, > <https://www.rfc-editor.org/rfc/rfc5086>. > > [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection > (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, > <https://www.rfc-editor.org/rfc/rfc5880>. > > [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, > "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, > DOI 10.17487/RFC8476, December 2018, > <https://www.rfc-editor.org/rfc/rfc8476>. > > [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, > "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, > DOI 10.17487/RFC8491, November 2018, > <https://www.rfc-editor.org/rfc/rfc8491>. > > [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, > H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF > Extensions for Segment Routing", RFC 8665, > DOI 10.17487/RFC8665, December 2019, > <https://www.rfc-editor.org/rfc/rfc8665>. > > [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., > Bashandy, A., Gredler, H., and B. Decraene, "IS-IS > Extensions for Segment Routing", RFC 8667, > DOI 10.17487/RFC8667, December 2019, > <https://www.rfc-editor.org/rfc/rfc8667>. > > [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, > M., and E. Aries, "Advertising Layer 2 Bundle Member Link > Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, > December 2019, <https://www.rfc-editor.org/rfc/rfc8668>. > > [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., > and N. Triantafillis, "Signaling Maximum SID Depth (MSD) > Using the Border Gateway Protocol - Link State", RFC 8814, > DOI 10.17487/RFC8814, August 2020, > <https://www.rfc-editor.org/rfc/rfc8814>. > > [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, > D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 > (SRv6) Network Programming", RFC 8986, > DOI 10.17487/RFC8986, February 2021, > <https://www.rfc-editor.org/rfc/rfc8986>. > > Schmutzer, et al. Expires 26 December 2025 [Page 28] > > Internet-Draft CS-SR Policy June 2025 > > [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, > H., and M. Chen, "Border Gateway Protocol - Link State > (BGP-LS) Extensions for Segment Routing", RFC 9085, > DOI 10.17487/RFC9085, August 2021, > <https://www.rfc-editor.org/rfc/rfc9085>. > > [RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., > and Z. Hu, "IS-IS Extensions to Support Segment Routing > over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, > February 2023, <https://www.rfc-editor.org/rfc/rfc9352>. > > [RFC9356] Talaulikar, K., Ed. and P. Psenak, "Advertising Layer 2 > Bundle Member Link Attributes in OSPF", RFC 9356, > DOI 10.17487/RFC9356, January 2023, > <https://www.rfc-editor.org/rfc/rfc9356>. > > [RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak, > "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)", > RFC 9513, DOI 10.17487/RFC9513, December 2023, > <https://www.rfc-editor.org/rfc/rfc9513>. > > [RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., > Bernier, D., and B. Decraene, "Border Gateway Protocol - > Link State (BGP-LS) Extensions for Segment Routing over > IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December > 2023, <https://www.rfc-editor.org/rfc/rfc9514>. > > Contributors > > Daniel Voyer > Bell Canada > Email: [email protected] > > Luay Jalil > Verizon > Email: [email protected] > > Shuping Peng > Huawei Technologies > Email: [email protected] > > Clarence Filsfils > Cisco Systems, Inc. > Email: [email protected] > > Schmutzer, et al. Expires 26 December 2025 [Page 29] > > Internet-Draft CS-SR Policy June 2025 > > Francois Clad > Cisco Systems, Inc. > Email: [email protected] > > Tarek Saad > Cisco Systems, Inc. > Email: [email protected] > > Brent Foster > Cisco Systems, Inc. > Email: [email protected] > > Bertrand Duvivier > Cisco Systems, Inc. > Email: [email protected] > > Stephane Litkowski > Cisco Systems, Inc. > Email: [email protected] > > Jie Dong > Huawei Technologies > Email: [email protected] > > Authors' Addresses > > Christian Schmutzer (editor) > Cisco Systems, Inc. > Email: [email protected] > > Zafar Ali (editor) > Cisco Systems, Inc. > Email: [email protected] > > Praveen Maheshwari > Airtel India > Email: [email protected] > > Schmutzer, et al. Expires 26 December 2025 [Page 30] > > Internet-Draft CS-SR Policy June 2025 > > Reza Rokui > Ciena > Email: [email protected] > > Andrew Stone > Nokia > Email: [email protected] > > Schmutzer, et al. Expires 26 December 2025 [Page 31] > > > > _______________________________________________ > spring mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
