< draft-schmutzer-pce-cs-sr-policy-01.txt   draft-schmutzer-pce-cs-sr-policy-02.txt >
Network Working Group C. Schmutzer, Ed. Network Working Group C. Schmutzer, Ed.
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Informational Z. Ali, Ed. Intended status: Informational Z. Ali, Ed.
Expires: 8 September 2022 F. Clad Expires: 6 November 2022 F. Clad
Cisco Systems, Inc. Cisco Systems, Inc.
P. Maheshwari P. Maheshwari
Airtel India Airtel India
7 March 2022 R. Rokui
Ciena
A. Stone
Nokia
L. Jalil
Verizon
S. Peng
Huawei Technologies
T. Saad
Juniper Networks
D. Voyer
Bell Canada
5 May 2022
Circuit Style Segment Routing Policies Circuit Style Segment Routing Policies
draft-schmutzer-pce-cs-sr-policy-01 draft-schmutzer-pce-cs-sr-policy-02
Abstract Abstract
This document describes how Segment Routing (SR) policies can be used This document describes how Segment Routing (SR) policies can be used
to satisfy the requirements for strict bandwidth guarantees, end-to- to satisfy the requirements for strict bandwidth guarantees, end-to-
end recovery and persistent paths within a segment routing network. end recovery and persistent paths within a segment routing network.
SR policies satisfying these requirements are called "circuit-style" SR policies satisfying these requirements are called "circuit-style"
SR policies (CS-SR policies). SR policies (CS-SR policies).
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 November 2022.
This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 4 3. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. CS-SR Policy Characteristics . . . . . . . . . . . . . . . . 5 4. CS-SR Policy Characteristics . . . . . . . . . . . . . . . . 5
5. CS-SR Policy Creation . . . . . . . . . . . . . . . . . . . . 5 5. CS-SR Policy Creation . . . . . . . . . . . . . . . . . . . . 6
6. Operations, Administration, and Maintenance (OAM) . . . . . . 6 5.1. Maximum Segment Depth . . . . . . . . . . . . . . . . . . 7
6.1. Liveness . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Recovery Schemes . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Performance Measurement . . . . . . . . . . . . . . . . . 7 6.1. Unprotected . . . . . . . . . . . . . . . . . . . . . . . 8
7. Recovery Schemes . . . . . . . . . . . . . . . . . . . . . . 7 6.2. 1:1 Protection . . . . . . . . . . . . . . . . . . . . . 9
7.1. Unprotected . . . . . . . . . . . . . . . . . . . . . . . 7 6.3. Restoration . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. 1+R Restoration . . . . . . . . . . . . . . . . . . . . . 8 6.3.1. 1+R Restoration . . . . . . . . . . . . . . . . . . . 10
7.3. 1:1 Protection . . . . . . . . . . . . . . . . . . . . . 8 6.3.2. 1:1+R Restoration . . . . . . . . . . . . . . . . . . 10
7.4. 1:1+R Protection . . . . . . . . . . . . . . . . . . . . 9 7. Operations, Administration, and Maintenance (OAM) . . . . . . 11
7.5. External Commands . . . . . . . . . . . . . . . . . . . . 10 7.1. Connectivity Verification . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.2. Performance Measurement . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7.3. Candidate Path Validity Verification . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. External Commands . . . . . . . . . . . . . . . . . . . . . . 12
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Candidate Path Switchover . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Candidate Path Recomputation . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Segment routing does allow for a single network to carry both typical Segment routing does allow for a single network to carry both typical
IP (connection-less) services and connection-oriented transport IP (connection-less) services and connection-oriented transport
services. IP services required ECMP and TI-LFA, while transport services commonly referred to as "private lines". IP services
services that normally are delivered via dedicated circuit-switched typically require ECMP and TI-LFA, while transport services that
SONET/SDH or OTN networks do require: normally are delivered via dedicated circuit-switched SONET/SDH or
OTN networks do require:
* Persistent end2end traffic engineered paths that provide * Persistent end-to-end traffic engineered paths that provide
predictable and identical latency in both directions predictable and identical latency in both directions
* Strict bandwidth commitment per path to ensure no impact on the * Strict bandwidth commitment per path to ensure no impact on the
Service Level Agreement (SLA) due to changing network load from Service Level Agreement (SLA) due to changing network load from
other services other services
* End2end protection (<50msec protection switching) and restoration * End-to-end protection (<50msec protection switching) and
mechanisms restoration mechanisms
* Monitoring and maintenance of path integrity * Monitoring and maintenance of path integrity
* Data plane remaining up while control plane is down * Data plane remaining up while control plane is down
Such a "transport centric" behaviour is referred to as "circuit- Such a "transport centric" behavior is referred to as "circuit-style"
style" in this document. in this document.
This document describes how SR policies This document describes how SR policies
[I-D.ietf-spring-segment-routing-policy] and adjacency-SIDs defined [I-D.ietf-spring-segment-routing-policy] and the use of adjacency-
in the SR architecture [RFC8402] together with a stateful Path SIDs defined in the SR architecture [RFC8402] together with a
Computation Element (PCE) [RFC8231] can be used to satisfy those stateful Path Computation Element (PCE) [RFC8231] can be used to
requirements. It includes how end-to-end recovery and path integrity satisfy those requirements. It includes how end-to-end recovery and
monitoring can be implemented. path integrity monitoring can be implemented.
SR policies that satisfy those requirements are called "circuit- SR policies that satisfy those requirements are called "circuit-
style" SR policies (CS-SR policies). style" SR policies (CS-SR policies).
2. Terminology 2. Terminology
* BSID : Binding Segment Identifier
* CS-SR : Circuit-Style Segment Routing * CS-SR : Circuit-Style Segment Routing
* ID : Identifier * ID : Identifier
* LSP : Label Switched Path * LSP : Label Switched Path
* LSPA : LSP attributes * LSPA : LSP attributes
* OAM : Operations, Administration and Maintenance * OAM : Operations, Administration and Maintenance
* OF : Objective Function * OF : Objective Function
* PCE : Path Computation Element * PCE : Path Computation Element
* PCEP : Path Computation Element Communication Protocol * PCEP : Path Computation Element Communication Protocol
* PT : Protection Type * PT : Protection Type
skipping to change at page 4, line 7 skipping to change at page 4, line 28
* SR : Segment Routing * SR : Segment Routing
* STAMP : Simple Two-Way Active Measurement Protocol * STAMP : Simple Two-Way Active Measurement Protocol
* TI-LFA : Topology Independent Loop Free Alternate * TI-LFA : Topology Independent Loop Free Alternate
* TLV : Type Length Value * TLV : Type Length Value
3. Reference Model 3. Reference Model
The reference model for CS-SR policies is following the segment The reference model for CS-SR policies is following the Segment
routing architecture [RFC8402] and SR policy architecture Routing Architecture [RFC8402] and SR Policy Architecture
[I-D.ietf-spring-segment-routing-policy] and is depicted in Figure 1. [I-D.ietf-spring-segment-routing-policy] and is depicted in Figure 1.
+--------------+ +--------------+
+-------------->| PCE |<--------------+ +-------------->| PCE |<--------------+
| +--------------+ | | +--------------+ |
| | | |
| | | |
v <<<<<<<<<<<<<< CS-SR Policy >>>>>>>>>>>>> v v <<<<<<<<<<<<<< CS-SR Policy >>>>>>>>>>>>> v
+-------+ +-------+ +-------+ +-------+
| |=========================================>| | | |=========================================>| |
| A | SR-policy from A to Z | Z | | A | SR-policy from A to Z | Z |
| |<=========================================| | | |<=========================================| |
+-------+ SR-policy from Z to A +-------+ +-------+ SR-policy from Z to A +-------+
Figure 1: Circuit-style SR Policy Architecture Figure 1: Circuit-style SR Policy Reference Model
By nature of CS-SR policies, paths will be computed and maintained by By nature of CS-SR policies, paths will be computed and maintained by
a stateful PCE defined in [RFC8231]. When using a MPLS data plane a stateful PCE defined in [RFC8231]. The stateful PCE provides 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. When using a MPLS data plane
[RFC8660], PCEP extensions defined in [RFC8664] will be used. When [RFC8660], PCEP extensions defined in [RFC8664] will be used. When
using a SRv6 data plane [RFC8754], PCEP extensions defined in using a SRv6 data plane [RFC8754], PCEP extensions defined in
[I-D.ietf-pce-segment-routing-ipv6] will be used. [I-D.ietf-pce-segment-routing-ipv6] will be used.
In order to satisfy the requirements of CS-SR policies, each link in In order to satisfy the requirements of CS-SR policies, each link in
the topology MUST have: the topology MUST have:
* An adjacency-SID which is: * An adjacency-SID which is:
- Manually allocated or persistent : to ensure that its value - Manually allocated or persistent : to ensure that its value
does not change after a node reload does not change after a node reload
- Non-protected : to avoid any local TI-LFA protection to happen - Non-protected : to avoid any local TI-LFA protection to happen
upon interface/link failures upon interface/link failures
* The bandwidth available for CS-SR policies * The bandwidth available for CS-SR policies specified
* A per-hop behavior ([RFC3246] or [RFC2597]) that ensures that the
specified bandwidth is available to CS-SR policies at all times
independent of any other traffic
When using a MPLS data plane [RFC8660] existing IGP extensions When using a MPLS data plane [RFC8660] existing IGP extensions
defined in [RFC8667] and [RFC8665] and BGP-LS defined in [RFC9085] defined in [RFC8667] and [RFC8665] and BGP-LS defined in [RFC9085]
can be used to distribute the topology information including those can be used to distribute the topology information including those
persistent and unprotected Adj-SIDs. persistent and unprotected adjacency-SIDs.
When using a SRv6 data plane [RFC8754] the IGP extensions defined in When using a SRv6 data plane [RFC8754] the IGP extensions defined in
[I-D.ietf-lsr-isis-srv6-extensions] and [I-D.ietf-lsr-isis-srv6-extensions] and
[I-D.ietf-lsr-ospfv3-srv6-extensions] and BGP-LS extensions in [I-D.ietf-lsr-ospfv3-srv6-extensions] and BGP-LS extensions in
[I-D.ietf-idr-bgpls-srv6-ext] apply. [I-D.ietf-idr-bgpls-srv6-ext] apply.
4. CS-SR Policy Characteristics 4. CS-SR Policy Characteristics
A CS-SR policy has the following characteristics: A CS-SR policy has the following characteristics:
skipping to change at page 5, line 20 skipping to change at page 5, line 51
policy policy
* Bidirectional co-routed : a CS-SR policy between A and Z is an * 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 association of an SR-Policy from A to Z and an SR-Policy from Z to
A following the same path(s) A following the same path(s)
* Deterministic and persistent paths : segment lists with strict * Deterministic and persistent paths : segment lists with strict
hops using unprotected adjacency-SIDs hops using unprotected adjacency-SIDs
* Not automatically recomputed or reoptimized : the SID list of a * Not automatically recomputed or reoptimized : the SID list of a
candidate path must not change automatically (for example upon candidate path must not change automatically to a SID list
topology change) representing a different path (for example upon topology change)
* Multiple candidate paths in case of protection/restoration: * Multiple candidate paths in case of protection/restoration:
- Following the SR policy architecture, the highest preference - Following the SR policy architecture, the highest preference
valid path is carrying traffic valid path is carrying traffic
- Depending on the protection/restoration scheme (Section 7), - Depending on the protection/restoration scheme (Section 6),
lower priority candidate paths lower priority candidate paths
o may be pre-computed o may be pre-computed
o may be pre-programmed o may be pre-programmed
o may have to be disjoint o may have to be disjoint
* Liveness and performance measurement is activated on each * Connectivity verification and performance measurement is activated
candidate path (Section 6) on each candidate path (Section 7)
5. CS-SR Policy Creation 5. CS-SR Policy Creation
A CS-SR policy between A and Z is configured both on A (with Z as A CS-SR policy between A and Z is configured both on A (with Z as
endpoint) and Z (with A as endpoint) as shown in Figure 1. endpoint) and Z (with A as endpoint) as shown in Figure 1.
Both nodes A and Z act as PCC and delegate path computation to the Both nodes A and Z act as PCC and delegate path computation to the
PCE using the extensions defined in [RFC8664]. The PCRpt message PCE using the extensions defined in [RFC8664]. The PCRpt message
sent from the headends to the PCE contains the following parameters: sent from the headends to the PCE contains the following parameters:
skipping to change at page 6, line 38 skipping to change at page 7, line 19
candidate path belonging to the same policy. candidate path belonging to the same policy.
The signaling extensions described in The signaling extensions described in
[I-D.sidor-pce-circuit-style-pcep-extensions] are used to ensure that [I-D.sidor-pce-circuit-style-pcep-extensions] are used to ensure that
* Path determinism is achieved by the PCE only using segment lists * Path determinism is achieved by the PCE only using segment lists
representing a strict hop by hop path using unprotected adjacency- representing a strict hop by hop path using unprotected adjacency-
SIDs. SIDs.
* Path persistency across node reloads in the network is achieved by * Path persistency across node reloads in the network is achieved by
the PCE only including manually configured adj-SIDs in its path the PCE only including manually configured adjacency-SIDs in its
computation response. path computation response.
* Persistency across network changes is achieved by the PCE not * Persistency across network changes is achieved by the PCE not
performing periodic nor network event triggered re-optimization. performing periodic nor network event triggered re-optimization.
Bandwidth adjustment can be requested after initial creation by Bandwidth adjustment can be requested after initial creation by
signaling both requested and operational bandwidth in the BANDWIDTH signaling both requested and operational bandwidth in the BANDWIDTH
object but the PCE is not allowed to respond with a changed path. object but the PCE is not allowed to respond with a changed path.
6. Operations, Administration, and Maintenance (OAM) As discussed in section 3.2 of [I-D.ietf-pce-multipath] it may be
6.1. Liveness 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].
The proper operation of each segment list is validated by both 5.1. Maximum Segment Depth
headends using STAMP in loopback measurement mode as described in
section 4.2.3 of [I-D.ietf-spring-stamp-srpm].
As the STAMP test packets are including both the segment list of the A Segment Routed path defined by a segment list is constrained by
forward and reverse path, standard segment routing data plane maximum segment depth (MSD), which is the maximum number of segments
operations will make those packets get switched along the forward a router can impose onto a packet. [RFC8491], [RFC8476], [RFC8814]
path to the tailend and along the reverse path back to the headend. and [RFC8664] provide the necessary capabilities for a PCE to
determine the MSD capability of a router. The MSD constraint is
typically resolved by leveraging a label stack 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.
The headend forms the bidirectional SR Policy association using the As described in Section 4, adjacency-SIDs without local protection
procedure described in [I-D.ietf-pce-sr-bidir-path] and receives the are to be used for CS-SR policies to ensure no ECMP, no rerouting due
information about the reverse segment list from the PCE as described to topological changes nor localized protection is being invoked on
in section 4.5 of [I-D.ietf-pce-multipath] the traffic, as the alternate path may not be providing the desired
SLA.
6.2. Performance Measurement If a CS-SR Policy path requires SID List reduction, a Node SID cannot
be utilized 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 same STAMP session used for liveliness monitoring can be used to * The BSID is unprotected, hence only has one candidate path
measure delay. As loopback mode is used only round-trip delay is
measured and one-way has to be derived by dividing the round-trip
delay by two.
The same STAMP session can also be used to estimate round-trip loss * The BSID follows the rerouting and optimization characteristics
as described in section 5 of [I-D.ietf-spring-stamp-srpm]. defined in Section 4 which implies the SID list of the candidate
path MUST only use unprotected adjacency-SIDs.
7. Recovery Schemes 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.
6. Recovery Schemes
Various protection and restoration schemes can be implemented. The Various protection and restoration schemes can be implemented. The
terms "protection" and "restoration" are used with same subtle terms "protection" and "restoration" are used with the same subtle
distinctions outlined in section 1 of [RFC4872], [RFC4427] and distinctions outlined in section 1 of [RFC4872], [RFC4427] and
[RFC3386] respectively. [RFC3386] respectively.
* Protection : another candidate path is computed and fully * Protection : another candidate path is computed and fully
established in the data plane and ready to carry traffic established in the data plane and ready to carry traffic
* Restoration : a candidate path may be computed and may be * Restoration : a candidate path may be computed and may be
partially established but is not ready to carry traffic partially established but is not ready to carry traffic
7.1. Unprotected The term "failure" is used to represent both "hard failures" such
complete loss of connectivity detected by Section 7.1 or degradation,
a packet loss ratio, beyond a configured acceptable threshold.
6.1. Unprotected
In the most basic scenario no protection nor restoration is required. In the most basic scenario no protection nor restoration is required.
The CS-SR policy has only one candidate path configured. This The CS-SR policy has only one candidate path configured. This
candidate path is established, activated (O field in LSP object is candidate path is established, activated (O field in LSP object is
set to 2) and is carrying traffic. set to 2) and is carrying traffic.
In case of a failure the CS-SR policy will go down and traffic will In case of a failure the CS-SR policy will go down and traffic will
not be recovered. not be recovered.
Typically two CS-SR policies are deployed either within the same Typically two CS-SR policies are deployed either within the same
network with disjoint paths or in two completely separate networks network with disjoint paths or in two completely separate networks
and the overlay service is responsible for traffic recovery. and the overlay service is responsible for traffic recovery.
7.2. 1+R Restoration 6.2. 1:1 Protection
To avoid pre-allocating protection bandwidth in steady state
(Section 7.3) but still be able to react to network failures and
recover traffic flow in a deterministic way (maintain required
bandwidth commitment) 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 (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 the failure that brought the first candidate path down is
cleared, the second candidate path is getting deactivated (O field in
LSP object is set to 1) or torn down. The first candidate path is
activated (O field in LSP object is set to 2) and traffic sent across
it.
Restoration and reversion behavior is bidirectional. As described in
Section 6.1, both headends use liveness 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.
7.3. 1:1 Protection
For fast recovery against failures the CS-SR policy is configured For fast recovery against failures the CS-SR policy is configured
with two candidate paths. Both paths are established but only the with two candidate paths. Both paths are established but only the
candidate with higher preference is activated (O field in LSP object candidate with higher preference is activated (O field in LSP object
is set to 2) and is carrying traffic. The candidate path with lower is set to 2) and is carrying traffic. The candidate path with lower
preference has its O field in LSP object set to 1. preference has its O field in LSP object set to 1.
Appropriate routing of the protect path diverse from the working path Appropriate routing of the protect path diverse from the working path
can be requested from the PCE by using the "Disjointness Association" can be requested from the PCE by using the "Disjointness Association"
object (type 2) defined in [RFC8800] in the PCRpt messages. The object (type 2) defined in [RFC8800] in the PCRpt messages. The
skipping to change at page 9, line 30 skipping to change at page 9, line 38
the best working path that does satisfy all constraints without the best working path that does satisfy all constraints without
considering diversity to the protect path. considering diversity to the protect path.
The "Objective Function (OF) TLV" as defined in section 5.3 of The "Objective Function (OF) TLV" as defined in section 5.3 of
[RFC8800] may also be added to minimize the common shared resources. [RFC8800] may also be added to minimize the common shared resources.
Upon a failure impacting the candidate path with higher preference Upon a failure impacting the candidate path with higher preference
carrying traffic, the candidate path with lower preference is carrying traffic, the candidate path with lower preference is
activated immediately and traffic is now sent across it. activated immediately and traffic is now sent across it.
Protection switching is bidirectional. As described in Section 6.1, Protection switching is bidirectional. As described in Section 7.1,
both headends will generate and receive their own loopback mode test both headends will generate and receive their own loopback mode test
packets, hence even a unidirectional failure will always be detected packets, hence even a unidirectional failure will always be detected
by both headends without protection switch coordination required. by both headends without protection switch coordination required.
Two cases are to be considered when the failure impacting the Two cases are to be considered when the failure impacting the
candidate path with higher preference is cleared: candidate path with higher preference is cleared:
* Revertive switching : re-activate the candidate path, change O * Revertive switching : re-activate the candidate path, change O
field from 0 to 2 and start sending traffic over it field from 0 to 2 and start sending traffic over it
* Non-revertive switching : do not activate the candidate path, * Non-revertive switching : do not activate the candidate path,
change O field from 0 to 1, keep the second candidate path active change O field from 0 to 1, keep the second candidate path active
with O field set to 2 and continue sending traffic over it with O field set to 2 and continue sending traffic over it
7.4. 1:1+R Protection 6.3. Restoration
6.3.1. 1+R Restoration
Compared to 1:1 protection described in Section 6.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)
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 (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 (O field in
LSP object is set to 1) or torn down. The first candidate path is
activated (O field in LSP object is set to 2) and traffic sent across
it.
Restoration and reversion behavior is bidirectional. As described in
Section 7.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.
6.3.2. 1:1+R Restoration
For further resiliency in case of multiple concurrent failures that For further resiliency in case of multiple concurrent failures that
could affect both candidate paths in a Section 7.3 scenario the CS-SR could affect both candidate paths of 1:1 protection described in
policy is configured with three candidate paths with decreasing Section 6.2, a third candidate path with a preference lower than the
preference. other two candidate paths is added to the CS-SR policy.
The third candidate path enables restoration and will generally only The third candidate path enables restoration and will generally only
be established, activated (O field in LSP object is set to 2) and be established, activated (O field in LSP object is set to 2) and
carry traffic after failure(s) have impacted both the candidate path carry traffic after failure(s) have impacted both the candidate path
with highest and second highest preference. with highest and second highest preference.
The third candidate path may also be requested and pre-computed The third candidate path may also be requested and pre-computed
already whenever either the first or second candidate path went down already whenever either the first or second candidate path went down
due to a failure with the downside of bandwidth being set aside ahead due to a failure with the downside of bandwidth being set aside ahead
of time. of time.
As soon as failure(s) that brought either the first or second As soon as failure(s) that brought either the first or second
candidate path down is cleared the third candidate path is getting candidate path down are cleared the third candidate path is getting
deactivated (O field in LSP object is set to 1), the candidate path deactivated (O field in LSP object is set to 1), the candidate path
that recovered is activated (O field in LSP object is set to 2) and that recovered is activated (O field in LSP object is set to 2) and
traffic sent across it. traffic sent across it.
Protection switching, restoration and reversion behavior is Again restoration and reversion behavior is bidirectional. As
bidirectional. As described in Section 6.1, both headends use described in Section 7.1, both headends use connectivity verification
liveness in loopback mode and therefore even in case of in loopback mode and therefore even in case of unidirectional
unidirectional failures both headends will detect the failure or failures both headends will detect the failure or clearance of the
clearance of the failure and switch traffic away from the failed or failure and switch traffic away from the failed or to the recovered
to the recovered candidate path. candidate path.
7.5. External Commands 7. Operations, Administration, and Maintenance (OAM)
7.1. Connectivity Verification
The proper operation of each segment list is validated by both
headends using STAMP in loopback measurement mode as described in
section 4.2.3 of [I-D.ietf-spring-stamp-srpm].
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 switched along the forward
path to the tailend and along the reverse path back to the headend.
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]
7.2. Performance Measurement
The same STAMP session is used to estimate round-trip loss as
described in section 5 of [I-D.ietf-spring-stamp-srpm].
The same STAMP session used for connectivity verification can be used
to measure delay. As loopback mode is used only round-trip delay is
measured and one-way has to be derived by dividing the round-trip
delay by two.
7.3. Candidate Path Validity Verification
A stateful PCE is in sync with the network topology and the CS-SR
Policies provisioned on the headend routers. As described in
Section 4 a path must not be automatically recomputed after or
optimized for topology changes. However there may be a requirement
for a PCE to tear down a path if the path no longer satisfies the
original requirements, detected by PCE, such as insufficient
bandwidth, diversity constraint no longer met or latency constraint
exceeded.
The PCC may measure the actual bandwidth utilization of a CS-SR
policy and report it to the PCE in order for the PCE to take an
appropriate action if necessary.
For a CS-SR policy configured with multiple candidate paths, a PCC
may switch to another candidate path if the PCE decided to tear down
the active candidate path.
8. External Commands
8.1. Candidate Path Switchover
It is very common to allow operators to trigger a switch between It is very common to allow operators to trigger a switch between
candidate paths even no failure is present. I.e. to proactively candidate paths even if no failure is present. I.e. to proactively
drain a resource for maintenance purposes. Operator triggered drain a resource for maintenance purposes. Operator triggered
switching between candidate paths is unidirectional and has to be switching between candidate paths is unidirectional and has to be
requested on both headends. requested on both headends.
8. Security Considerations 8.2. Candidate Path Recomputation
While no automatic re-optimization or pre-computation of CS-SR policy
candidate paths is allowed as specified in Section 4, network
operators trying to optimize network utilization may explicitly
request a candidate path to be re-computed at a certain point in
time.
9. Security Considerations
TO BE ADDED TO BE ADDED
9. IANA Considerations 10. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. Acknowledgements 11. Acknowledgements
The author's want to thank Samuel Sidor, Mike Koldychev, Rakesh The author's want to thank Samuel Sidor, Mike Koldychev, Rakesh
Gandhi for providing their review comments. Gandhi and Tarek Saad for providing their review comments.
11. Contributors 12. Contributors
Contributors' Addresses Contributors' Addresses
Brent Foster Brent Foster
Cisco Systems, Inc. Cisco Systems, Inc.
Email: brfoster@cisco.com Email: brfoster@cisco.com
Bertrand Duvivier Bertrand Duvivier
Cisco System, Inc. Cisco System, Inc.
Email: bduvivie@cisco.com Email: bduvivie@cisco.com
Stephane Litkowski Stephane Litkowski
Cisco Systems, Inc. Cisco Systems, Inc.
Email: slitkows@cisco.com Email: slitkows@cisco.com
12. References Jie Dong
Huawei Technologies
Email: jie.dong@huawei.com
12.1. Normative References 13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
12.2. Informative References 13.2. Informative References
[I-D.ietf-idr-bgpls-srv6-ext] [I-D.ietf-idr-bgpls-srv6-ext]
Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., Dawra, G., Filsfils, C., Talaulikar, K., Chen, M.,
Bernier, D., and B. Decraene, "BGP Link State Extensions Bernier, D., and B. Decraene, "BGP Link State Extensions
for SRv6", Work in Progress, Internet-Draft, draft-ietf- for SRv6", Work in Progress, Internet-Draft, draft-ietf-
idr-bgpls-srv6-ext-09, 10 November 2021, idr-bgpls-srv6-ext-09, 10 November 2021,
<https://www.ietf.org/archive/id/draft-ietf-idr-bgpls- <https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-
srv6-ext-09.txt>. srv6-ext-09.txt>.
[I-D.ietf-lsr-isis-srv6-extensions] [I-D.ietf-lsr-isis-srv6-extensions]
skipping to change at page 12, line 9 skipping to change at page 14, line 24
Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
"OSPFv3 Extensions for SRv6", Work in Progress, Internet- "OSPFv3 Extensions for SRv6", Work in Progress, Internet-
Draft, draft-ietf-lsr-ospfv3-srv6-extensions-03, 19 Draft, draft-ietf-lsr-ospfv3-srv6-extensions-03, 19
November 2021, <https://www.ietf.org/archive/id/draft- November 2021, <https://www.ietf.org/archive/id/draft-
ietf-lsr-ospfv3-srv6-extensions-03.txt>. ietf-lsr-ospfv3-srv6-extensions-03.txt>.
[I-D.ietf-pce-local-protection-enforcement] [I-D.ietf-pce-local-protection-enforcement]
Stone, A., Aissaoui, M., Sidor, S., and S. Sivabalan, Stone, A., Aissaoui, M., Sidor, S., and S. Sivabalan,
"Local Protection Enforcement in PCEP", Work in Progress, "Local Protection Enforcement in PCEP", Work in Progress,
Internet-Draft, draft-ietf-pce-local-protection- Internet-Draft, draft-ietf-pce-local-protection-
enforcement-04, 30 January 2022, enforcement-05, 4 May 2022,
<https://www.ietf.org/archive/id/draft-ietf-pce-local- <https://www.ietf.org/archive/id/draft-ietf-pce-local-
protection-enforcement-04.txt>. protection-enforcement-05.txt>.
[I-D.ietf-pce-multipath] [I-D.ietf-pce-multipath]
Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P.,
Bidgoli, H., Yadav, B., Peng, S., and G. Mishra, "PCEP Bidgoli, H., Yadav, B., Peng, S., and G. Mishra, "PCEP
Extensions for Signaling Multipath Information", Work in Extensions for Signaling Multipath Information", Work in
Progress, Internet-Draft, draft-ietf-pce-multipath-04, 25 Progress, Internet-Draft, draft-ietf-pce-multipath-05, 30
February 2022, <https://www.ietf.org/archive/id/draft- March 2022, <https://www.ietf.org/archive/id/draft-ietf-
ietf-pce-multipath-04.txt>. pce-multipath-05.txt>.
[I-D.ietf-pce-segment-routing-ipv6] [I-D.ietf-pce-segment-routing-ipv6]
Li, C., Negi, M., Sivabalan, S., Koldychev, M., Li, C., Negi, M., Sivabalan, S., Koldychev, M.,
Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment
Routing leveraging the IPv6 data plane", Work in Progress, Routing leveraging the IPv6 data plane", Work in Progress,
Internet-Draft, draft-ietf-pce-segment-routing-ipv6-12, 6 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-13, 1
March 2022, <https://www.ietf.org/internet-drafts/draft- April 2022, <https://www.ietf.org/internet-drafts/draft-
ietf-pce-segment-routing-ipv6-12.txt>. ietf-pce-segment-routing-ipv6-13.txt>.
[I-D.ietf-pce-segment-routing-policy-cp] [I-D.ietf-pce-segment-routing-policy-cp]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
Bidgoli, "PCEP extension to support Segment Routing Policy Bidgoli, "PCEP extension to support Segment Routing Policy
Candidate Paths", Work in Progress, Internet-Draft, draft- Candidate Paths", Work in Progress, Internet-Draft, draft-
ietf-pce-segment-routing-policy-cp-06, 22 October 2021, ietf-pce-segment-routing-policy-cp-07, 21 April 2022,
<https://www.ietf.org/archive/id/draft-ietf-pce-segment- <https://www.ietf.org/archive/id/draft-ietf-pce-segment-
routing-policy-cp-06.txt>. routing-policy-cp-07.txt>.
[I-D.ietf-pce-sr-bidir-path] [I-D.ietf-pce-sr-bidir-path]
Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong,
"Path Computation Element Communication Protocol (PCEP) "Path Computation Element Communication Protocol (PCEP)
Extensions for Associated Bidirectional Segment Routing Extensions for Associated Bidirectional Segment Routing
(SR) Paths", Work in Progress, Internet-Draft, draft-ietf- (SR) Paths", Work in Progress, Internet-Draft, draft-ietf-
pce-sr-bidir-path-09, 6 March 2022, pce-sr-bidir-path-09, 6 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir- <https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-
path-09.txt>. path-09.txt>.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", Work in P. Mattes, "Segment Routing Policy Architecture", Work in
Progress, Internet-Draft, draft-ietf-spring-segment- Progress, Internet-Draft, draft-ietf-spring-segment-
routing-policy-20, 6 March 2022, routing-policy-22, 22 March 2022,
<https://www.ietf.org/archive/id/draft-ietf-spring- <https://www.ietf.org/archive/id/draft-ietf-spring-
segment-routing-policy-20.txt>. segment-routing-policy-22.txt>.
[I-D.ietf-spring-stamp-srpm] [I-D.ietf-spring-stamp-srpm]
Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens, Gandhi, R., Filsfils, C., Voyer, D., Chen, M., Janssens,
B., and R. Foote, "Performance Measurement Using Simple B., and R. Foote, "Performance Measurement Using Simple
TWAMP (STAMP) for Segment Routing Networks", Work in TWAMP (STAMP) for Segment Routing Networks", Work in
Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-03, Progress, Internet-Draft, draft-ietf-spring-stamp-srpm-03,
1 February 2022, <https://www.ietf.org/archive/id/draft- 1 February 2022, <https://www.ietf.org/archive/id/draft-
ietf-spring-stamp-srpm-03.txt>. ietf-spring-stamp-srpm-03.txt>.
[I-D.sidor-pce-circuit-style-pcep-extensions] [I-D.sidor-pce-circuit-style-pcep-extensions]
Sidor, S., Ali, Z., and P. Maheshwari, "PCEP extensions Sidor, S., Ali, Z., and P. Maheshwari, "PCEP extensions
for Circuit Style Policies", Work in Progress, Internet- for Circuit Style Policies", Work in Progress, Internet-
Draft, draft-sidor-pce-circuit-style-pcep-extensions-00, 7 Draft, draft-sidor-pce-circuit-style-pcep-extensions-00, 7
March 2022, <https://www.ietf.org/archive/id/draft-sidor- March 2022, <https://www.ietf.org/archive/id/draft-sidor-
pce-circuit-style-pcep-extensions-00.txt>. pce-circuit-style-pcep-extensions-00.txt>.
[RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925,
DOI 10.17487/RFC1925, April 1996, DOI 10.17487/RFC1925, April 1996,
<https://www.rfc-editor.org/info/rfc1925>. <https://www.rfc-editor.org/info/rfc1925>.
[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/info/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/info/rfc3246>.
[RFC3386] Lai, W., Ed. and D. McDysan, Ed., "Network Hierarchy and [RFC3386] Lai, W., Ed. and D. McDysan, Ed., "Network Hierarchy and
Multilayer Survivability", RFC 3386, DOI 10.17487/RFC3386, Multilayer Survivability", RFC 3386, DOI 10.17487/RFC3386,
November 2002, <https://www.rfc-editor.org/info/rfc3386>. November 2002, <https://www.rfc-editor.org/info/rfc3386>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized (Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006, DOI 10.17487/RFC4427, March 2006,
<https://www.rfc-editor.org/info/rfc4427>. <https://www.rfc-editor.org/info/rfc4427>.
skipping to change at page 14, line 10 skipping to change at page 16, line 37
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[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/info/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/info/rfc8491>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019, DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>. <https://www.rfc-editor.org/info/rfc8660>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664, Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019, DOI 10.17487/RFC8664, December 2019,
skipping to change at page 15, line 5 skipping to change at page 17, line 41
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
[RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, [RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
"Path Computation Element Communication Protocol (PCEP) "Path Computation Element Communication Protocol (PCEP)
Extension for Label Switched Path (LSP) Diversity Extension for Label Switched Path (LSP) Diversity
Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800, Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800,
July 2020, <https://www.rfc-editor.org/info/rfc8800>. July 2020, <https://www.rfc-editor.org/info/rfc8800>.
[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/info/rfc8814>.
[RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation [RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation
Element Communication Protocol (PCEP) Extensions for Element Communication Protocol (PCEP) Extensions for
Associated Bidirectional Label Switched Paths (LSPs)", Associated Bidirectional Label Switched Paths (LSPs)",
RFC 9059, DOI 10.17487/RFC9059, June 2021, RFC 9059, DOI 10.17487/RFC9059, June 2021,
<https://www.rfc-editor.org/info/rfc9059>. <https://www.rfc-editor.org/info/rfc9059>.
[RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler,
H., and M. Chen, "Border Gateway Protocol - Link State H., and M. Chen, "Border Gateway Protocol - Link State
(BGP-LS) Extensions for Segment Routing", RFC 9085, (BGP-LS) Extensions for Segment Routing", RFC 9085,
DOI 10.17487/RFC9085, August 2021, DOI 10.17487/RFC9085, August 2021,
skipping to change at line 695 skipping to change at page 18, line 32
Cisco Systems, Inc. Cisco Systems, Inc.
Email: zali@cisco.com Email: zali@cisco.com
Francois Clad Francois Clad
Cisco Systems, Inc. Cisco Systems, Inc.
Email: fclad@cisco.com Email: fclad@cisco.com
Praveen Maheshwari Praveen Maheshwari
Airtel India Airtel India
Email: Praveen.Maheshwari@airtel.com Email: Praveen.Maheshwari@airtel.com
Reza Rokui
Ciena
Email: rrokui@ciena.com
Andrew Stone
Nokia
Email: andrew.stone@nokia.com
Luay Jalil
Verizon
Email: luay.jalil@verizon.com
Shuping Peng
Huawei Technologies
Email: pengshuping@huawei.com
Tarek Saad
Juniper Networks
Email: tsaad@juniper.net
Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca
 End of changes. 62 change blocks. 
144 lines changed or deleted 282 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/