idnits 2.17.1 draft-chunduri-rtgwg-preferred-path-routing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 25, 2021) is 915 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-07 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-09 -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG S. Bryant, Ed. 3 Internet-Draft University of Surrey 5GIC 4 Intended status: Standards Track U. Chunduri, Ed. 5 Expires: April 28, 2022 Intel Corporation 6 A. Clemm 7 Futurewei 8 October 25, 2021 10 Preferred Path Routing Framework 11 draft-chunduri-rtgwg-preferred-path-routing-01 13 Abstract 15 Capacity demands, Traffic Engineering (TE) and determinism are some 16 of key requirements for various cellular, edge and industrial 17 deployments. These deployments span from many underlying data pane 18 technologies including native IPv4, native IPv6 along with MPLS and 19 Segment Routing (SR). 21 This document provides a framework for Preferred Path Routing (PPR). 22 PPR is a method of providing path based dynamic routing for a number 23 of packet types including IPv4, IPv6 and MPLS. This seamlessly works 24 with a controller plane which holds both complete network view of 25 operator policies, while distributed control plane providing self- 26 healing benefits in a near-real time fashion. 28 PPR builds on existing encapsulations at the edge nodes to add path 29 identity to the packet. This reduces the per packet overhead 30 required for path steering and therefore has a smaller impact on both 31 packet MTU, data plane processing and overall goodput for small 32 payload packets, while extending path steering benefits to any 33 existing data plane. 34 A number of extensions that allow expansion of use beyond simple 35 point-to-point-paths are also described in this memo. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 28, 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Relation to Segment Routing . . . . . . . . . . . . . . . 4 73 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 74 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Applicability and Key use cases . . . . . . . . . . . . . . . 5 76 2.1. XHaul Transport . . . . . . . . . . . . . . . . . . . . . 6 77 2.2. PPR as VPN+ Underlay and Network Slicing . . . . . . . . 7 78 2.3. PPR as FRR Solution . . . . . . . . . . . . . . . . . . . 7 79 2.4. Extensible alternative to Flex Algo . . . . . . . . . . . 8 80 2.5. PPR for energy-optimized networks . . . . . . . . . . . . 8 81 3. Preferred Path Routing (PPR) . . . . . . . . . . . . . . . . 9 82 3.1. PPR Data Plane aspects . . . . . . . . . . . . . . . . . 11 83 3.1.1. PPR Native IP Data Planes . . . . . . . . . . . . . . 11 84 3.1.2. SR-MPLS with PPR . . . . . . . . . . . . . . . . . . 13 85 3.1.3. SRv6, Network Programming and PPR . . . . . . . . . . 13 86 3.2. PPR Control Plane aspects . . . . . . . . . . . . . . . . 14 87 3.2.1. PPR-ID and Data Plane Extensibility . . . . . . . . . 14 88 3.2.2. PPR Path Description Elements (PDEs) . . . . . . . . 14 89 3.2.3. ECMP Considerations . . . . . . . . . . . . . . . . . 15 90 3.2.4. PPR Services along the Path . . . . . . . . . . . . . 15 91 3.2.5. PPR Graphs . . . . . . . . . . . . . . . . . . . . . 15 92 3.2.6. PPR Multi-Domain Scenarios . . . . . . . . . . . . . 17 93 3.3. PPR Management Plane Aspects . . . . . . . . . . . . . . 18 94 3.3.1. IGP Metric Independent Paths/Graphs . . . . . . . . . 18 95 3.3.2. Granular OAM . . . . . . . . . . . . . . . . . . . . 19 96 4. Preferred Path Loop Free Alternatives (pLFA ) . . . . . . . . 20 97 5. Traffic Engineering Attributes . . . . . . . . . . . . . . . 21 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 102 8.2. Informative References . . . . . . . . . . . . . . . . . 22 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 105 1. Introduction 107 With the deployments of more advanced services, such as 5G and 108 beyond, the need for Traffic Engineering (TE) with deterministic 109 services become more important. Especially in many edge networks 110 where stringent requirements must be met in terms of latency, 111 throughput, packet loss and packet error rate. Traffic steering 112 provides a base to build some of these capabilities to serve various 113 cellular, edge and vertical industries. Additionally, diverse data 114 planes are used in various deployments and parts of the network, 115 including Ethernet, MPLS, and native IP (IPv4/IPv6) needs some of 116 these capabilities. 118 This document provides a framework for Preferred Path Routing (PPR). 119 PPR is a method of adding explicit paths to a network using link- 120 state routing protocols. Such a path, which may be a strict or loose 121 and can be any loop-free path between two points in the network. A 122 node makes an on-path check to determine if it is on the path, and, 123 if so, adds a FIB entry with NextHop (NH) (computed from the SPF 124 tree) set to the next element in the path description. 126 The Preferred Path Route Identifier (PPR-ID) in the packet is used to 127 map the packet to the PPR path, and hence to identify resources and 128 the NH. In other words, PPR-ID is the path identity to the packet 129 and routing and forwarding happens based on this identifier while 130 providing various services to all the flows mapped to the path. 132 As described, PPR is forwarding plane agnostic, and may be used with 133 any packet technology in which the packet carries an identifier that 134 is unique within the PPR domain. PPR may hence be used to add 135 explicit path and resource mapping functionality with inherent TE 136 properties in IPv4, IPv6, MPLS, Ethernet or similar networks. It 137 also has a smaller impact on both packet MTU and data plane 138 processing. PPR uses an IGP control plane based approach for dynamic 139 path steering. 141 Applications and key use case scenarios for PPR are described further 142 in Section 2. 143 PPR itself is described in further detail in Section 3. 145 Section 3.1,Section 3.2, Section 3.3 describe various data, control 146 and management plane functionalities of PPR respectively. A number 147 of extensions that allow expansion of use beyond simple point-to- 148 point- paths, TE aware loop-free-alternatives and path related 149 services to the flows are also described in this memo. 151 1.1. Relation to Segment Routing 153 Segment Routing (SR) [RFC8402] enables packet steering by including 154 set of Segment Identifiers (SIDs) in the packet that the packet must 155 traverse or be processed by. In an MPLS network this is done by 156 mapping the SIDs to MPLS labels and then pushing the required labels 157 on the packet [RFC8660]. In SRv6, [RFC8754] defines a segment 158 routing extension header (SRH) to be carried in the packet which 159 contains a list of the segments. The usefulness of PPR with SR and 160 inter- working scenarios are described in Section 3.1.2 and 161 Section 3.1.3. 163 SR also defines Binding SIDs (BSIDs) [RFC8402] which are SIDs pre- 164 positioned in the network to either allow the number of SIDs in the 165 packet to be reduced, or provide a method of translating from an edge 166 imposed SID to a SID that the network prefers. One use of BSIDs is 167 to define a path by associating an out-bound SID on every node along 168 the path in which case the packet can be steered by swapping the 169 incoming active SID on the packet with a BSID. For both SR-MPLS and 170 SRv6, PPR can reduce the number of touch points needed with BSIDs by 171 dynamically signaling the path and associating the path with an 172 abstract data plane identifier. 174 With PPR as a data packet carries a PPR-ID Section 3.1 instead of 175 individual SIDs, it avoids exposing the path; thus it avoids 176 revealing topology, traffic flow and service usage, if a packet is 177 snooped. This is described as "Topology Disclosure" security 178 consideration in [RFC8754]. 180 1.2. Requirements Language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC2119 [RFC2119], 185 RFC8174 [RFC8174] when, and only when they appear in all capitals, as 186 shown here. 188 1.3. Acronyms 189 +-----------+-------------------------------------------------------+ 190 | Term | Definition | 191 +-----------+-------------------------------------------------------+ 192 | GTP | GPRS Tunneling Protocol (3GPP) | 193 | | | 194 | IS-IS LSP | IS-IS Link State PDU | 195 | | | 196 | IPFRR | IP FastReRoute | 197 | | | 198 | MPLS | Multi-Protocol Label Switching | 199 | | | 200 | MTU | Maximum Transferable Unit | 201 | | | 202 | NH | NextHop | 203 | | | 204 | PDE | Path Description Element of the Preferred path | 205 | | | 206 | PE | Provider Edge | 207 | | | 208 | PPR | Preferred Path Routing/Route | 209 | | | 210 | PPR-ID | Preferred Path Route Identifier, a data plane | 211 | | identifier | 212 | | | 213 | (R)AN | 5G Radio Access Network (3GPP REL15) | 214 | | | 215 | SID | Segment Identifier | 216 | | | 217 | SPF | Shortest Path First | 218 | | | 219 | SR-MPLS | Segment Routing with MPLS data plane | 220 | | | 221 | SRH | Segment Routing Header - IPv6 routing Extension | 222 | | header | 223 | | | 224 | SRv6 | Segment Routing with IPv6 data plane with SRH | 225 | | | 226 | TE | Traffic Engineering | 227 | | | 228 | UPF | User Plane Function (3GPP REL15) | 229 +-----------+-------------------------------------------------------+ 231 2. Applicability and Key use cases 232 2.1. XHaul Transport 234 Cellular networks predominantly use both IP and MPLS data planes in 235 the transport part of the network. For the cellular transport to 236 evolve for 5G, certain underlay network requirements need to be met 237 (for slices other than enhanced Mobile Broadband (eMBB)). PPR is a 238 mechanism to achieve this, as it provides dynamic path based routing 239 and traffic steering for any underlying data plane (IPv4/IPv6/MPLS) 240 used, without any additional control plane protocol in the network. 241 PPR acts as an underlay mechanism in cellular XHaul (N3/N9 interfaces 242 below) and hence can work with any overlay mechanism including GPRS 243 Tunneling Protocol (GTP). 245 +--------+ 246 +------+ +-------+ +------+ +------+ / Cellular \ 247 |(R)AN)|===|CSR/PE |--N3--|PE+UPF|--N9--|PE+UPF|+ Core + 248 +------+ +-------+ +------+ +------+ \ Network / 249 +--------+ 250 === : Front and Layer2/Layer3-MidHaul (F1 Interface) 251 --- : Backhaul (N3/N9 Interfaces) 253 Figure 1: Cellular Transport Network 255 Figure 1 depicts a high level view of cellular XHaul network. 256 Fronthaul is generally a point-to-point link, midhaul uses Layer-2/ 257 IP and backhaul is an IP/MPLS network. For the end-to-end slicing in 258 these deployments, both midhaul and backhaul need to have traffic 259 engineering as well as underlay QoS capabilities. 261 In many cellular deployments connectivity for various 5G nodes on F1, 262 N3 and N9 interfaces, topologies for example, range from subtended 263 rings to Leaf- Spine Fabric (LS-Fabric) in edge deployments. While 264 there is no limitation w.r.t topologies where PPR is applicable, for 265 some of these deployments PPR is more suitable for providing Traffic 266 Engineering for high volume traffic with no path overhead in the 267 underlying data plane. PPR augments the SR-MPLS deployments with low 268 data plane overhead and high reliability with TE aware fast reroute 269 (PLFA) as described in Section 3.2.2. In the overlay or virtual 270 router environment, PPR provides lightweight service chaining with 271 non-topological Path Description Element (PDEs) Section 3.2.2 along 272 the preferred path. PPR helps to achieve OAM capabilities at the 273 path granularity without any additional per packet information. 275 Some edge deployment underlays are predominantly IP (IPv4/IPv6) 276 based. If IGP based underlay control plane is in use, PPR can 277 provide the required flexibility for creating TE paths, where native 278 IP data planes (IPv4/IPv6) are used. PPR can help operators to 279 mitigate the congestion in the underlay and path related services for 280 critical servers in the edge networks dynamically. 282 2.2. PPR as VPN+ Underlay and Network Slicing 284 There is a need to support the requirements of new applications, 285 particularly applications that are associated with 5G services. An 286 approach to supporting these needs is described in 287 [I-D.ietf-teas-enhanced-vpn]. This approach utilizes existing VPN 288 and TE technologies and adds features that specific services require 289 over and above traditional VPNs. The document describes a framework 290 for using existing, modified and potential new networking 291 technologies as components to provide an Enhanced Virtual Private 292 Network (VPN+) service. 294 Typically, VPN+ will be used to form the underpinning of network 295 slicing, but could also be of use in its own right. It is not 296 envisaged that large numbers of VPN+ instances will be deployed in a 297 network and, in particular, it is not intended that all VPNs 298 supported by a network will use VPN+ techniques. 300 Such networks potentially need large numbers of paths each with 301 individually allocated resources at each link and node. A segment 302 routing approach has the potential to require large numbers of SIDs 303 in each packet; and the paths become strict source routed through 304 end-to-end set of resources needed to create the VPN+ paths. By 305 using PPR, the number of segments needed in packets is reduced, and 306 the management overhead of installing the large numbers of BSIDs is 307 reduced. 309 2.3. PPR as FRR Solution 311 PPR may be used in a network as a method of providing IP Fast-ReRoute 312 (IPFRR). This is independent of whether PPR is used in the network 313 for other traffic steering purposes. It can be used to create 314 optimal paths or paths congruent with the post convergence path from 315 the point of local repair (PLR) as is proposed in TI-LFA 316 [I-D.ietf-rtgwg-segment-routing-ti-lfa]. Unlike TI-LFA PPR may be 317 used in IPv4 networks. This is discussed further in Section 4. The 318 approach has the further intrinsic advantage that no matter how 319 complex the repair path, only a single header (or MPLS label) needs 320 to be pushed onto the packet which may assist routers that find it 321 difficult to push large headers. 323 2.4. Extensible alternative to Flex Algo 325 Flex-Algorithm [I-D.ietf-lsr-flex-algo] is a method that is sometimes 326 used to create paths between Segment Routing (SR) nodes when it is 327 required that packets traverse a path other than the shortest path 328 that the SPF of the underlying IGP would naturally install. There is 329 a limit of 128 algorithms that can be installed in a network. Flex- 330 Algorithm is a cost based approach to creating a path which means 331 that a path or pathlet is indirectly created by manipulating the 332 metrics of the links. These metrics affect all the paths within the 333 scope of the Flex-Algorithm number (instance). The traffic steering 334 properties of Flex-Algorithm required for SR can be achieved directly 335 with PPR with several advantages: 337 o The scope of a PPR path is strictly limited to the sub-path 338 between the SR nodes. 340 o The path can be directly specifies rather than implicitly through 341 metrics 343 o Resources (such as specialist queues etc.) may be directly mapped 344 to the PPR path and hence to the SR sub-path. 346 2.5. PPR for energy-optimized networks 348 Improving energy efficiency and reducing power consumption are 349 becoming of increasing importance for many industries, which includes 350 network operators as well as users and providers of networking 351 services. Network providers can contribute to addressing those 352 challenges by making their networks more energy-efficient. This 353 includes the support of power saving schemes that guide traffic along 354 paths deemed particularly "energy efficient". 356 A significant opportunity to reduce power consumption concerns 357 powering down (or putting into power saving mode) equipment 358 (including line card, ports, etc.) that may not be currently needed. 359 At the same time, the incremental power consumption for additional 360 traffic on ports and equipment already under power is for all 361 practical purposes negligible. Optimizing energy efficiency thus 362 involves directing traffic in such a way that it allows for isolation 363 of equipment that may at the moment not be needed so that it could be 364 powered down or brought into power-saving mode. 366 This implies that power efficiency of networks can be greatly 367 affected by the paths along which traffic is directed at any 368 particular point in time. Proper engineering of those paths and the 369 ability to configure them effectively thus becomes an important tool 370 to optimize power usage of networks and make them more energy 371 efficient. PPR provides a mechanism that enables this, allowing to 372 engineer dynamic paths that optimize the network from an energy 373 savings perspective as one important set of criteria for any 374 underlying data plane in the network. 376 3. Preferred Path Routing (PPR) 378 PPR allows the direction of traffic along an engineered path through 379 the network by replacing the SID label stack or the SID list with a 380 single PPR-ID. The PPR-ID may either be a single label (MPLS) or a 381 native destination prefix (IPv4/IPv6). This enables the use of a 382 single data plane identifier to describe an entire path. 384 A PPR path could be an (Segmented Routed) SR path, a traffic 385 engineered path computed based on some constraints, an explicitly 386 provisioned Fast Re-Route (FRR) path or a service chained path. A 387 PPR path can be signaled by any node, computed by a central 388 controller, or manually configured by an operator. PPR extends the 389 source routing and path steering capabilities to native IP (IPv4 and 390 IPv6) data planes without hardware upgrades; see Section 3.1. 392 (PE) (P) (PE) 393 R1---------R2----------R3 r3' 394 | \ |\ | 395 | \ | \L26 | 396 | \ | \ | 397 | \ | \ | 398 | 10\ | 10\ | 399 | \ | \ | 400 | \ | \ | 401 | \ | \ | 402 | \ | 10 \ | 403 R4---------R5---------R6 r6' 404 (P) (P) (PE) 405 PATH-1: R1-R2-L26-R6-R3 : PPR-ID=r3' 406 PATH-2: R1-R5-R6 : PPR-ID=r6' 408 Figure 2: IGP Network 410 In the Figure 2, consider node R1 as an ingress node, or a head-end 411 node, and the node R3 may be an egress node or another head-end node. 412 The numbers shown on links between nodes indicate the bi-directional 413 IGP metric as provisioned (no number indicates a metric of 1). R1 414 may be configured to receive TE source routed path information from a 415 central entity (PCE [RFC5440], Netconf [RFC6241] or a Controller) 416 that comprises PPR information which relates to sources that are 417 attached to R1. It is also possible to have a PPR provisioned 418 locally by the operator for non-TE needs (e.g., FRR or for chaining 419 certain services). 421 The PPR is encoded as an ordered list of path elements from source to 422 a destination node in the network and is represented with a PPR-ID to 423 represent the path. The path can represent both topological and non- 424 topological elements (for example, links, nodes, queues, priority and 425 processing actions) and specifies the actual path towards the egress 426 node. 428 o The shortest path towards R3 from R1 is through the following 429 sequence of nodes: R1-R2-R3 based on the provisioned IGP metrics. 431 o The central entity in this example, can define a PPRs from R1 to 432 R3 and R1 to R6 that deviate from the shortest path based on other 433 network characteristic requirements as requested by an application 434 or service. For example, the network characteristics or 435 performance requirements may include bandwidth, jitter, latency, 436 throughput, error rate, etc. 438 o In a VPN setup, nodes R1, R3 and R6 are PE nodes and other nodes 439 are P nodes. User traffic entering at the ingress PE nodes gets 440 encapsulated (e.g., MPLS, GRE, GTP, IP-IN-IP, GUE) and will be 441 delivered to the egress PE. 443 Consider two paths in the above network: 445 o PATH-1: A first PPR may be identified by PPR-ID = r3' with the 446 path description R1-R2-L26-R6-R3 for a Prefix advertised by R3. 447 This is an example of a strict path with a combination of links 448 and nodes. 450 o PATH-2: A second PPR may be identified by PPR-ID = r6' with the 451 path description R1-R5-R6. This is an example of a loose path. 452 Though this example shows PPRs with node identifiers it is 453 possible to have a PPR with a combination of Non-Topological 454 elements along the path. 456 The first topological element relative to the beginning of PPR Path 457 descriptor contains the information about the first node in the path 458 that the packet must pass through (e.g. equivalent to the top label 459 in SR-MPLS and the first SID in an SRv6 SRH). The last topological 460 sub-object or PDE contains information about the last node (e.g. in 461 SR-MPLS it is equivalent to the bottom SR label). 463 Each IGP node receiving a complete path description, determines 464 whether the node is on the advertised PPR path. This is called the 465 PPR on-path check. It then determines whether it is included more 466 than once on that path. This PPR validation prevents the formation 467 of a routing loop. If the path is looped, no further processing of 468 the PPR is undertaken. (Note that even if it is invalid, the PPR 469 descriptor must still be flooded to preserve the consistency of the 470 underlying routing protocol). If the validation succeeds, the 471 receiving IGP node installs a Forwarding Information dataBase (FIB) 472 entry for the PPR-ID with the NextHop (NH) required to take the 473 packet to the next topological path element in the path description. 474 Processing of PPRs may be done at the end of the IGP SPF computation. 476 Consider PPR path PATH-1 in Figure 2. When node R5 receives the PPR 477 (PATH-1) information it does not install a FIB entry for PATH-1 478 because this PPR does not include node R5 in the path description/ 479 ordered path list. 481 However, node R5 determines that the second PPR (PATH-2), does 482 include the node R5 in its path description (the on-path check 483 passes). Therefore, node R5 updates its FIB to include an entry for 484 the destination address that R6 indicates (PPR-ID) along with path 485 description. This allows the forwarding of data packets with the 486 PPR-ID (r6') to the next element along the path, and hence towards 487 node R6. 489 To summarize the control plane processing, the receiving IGP node 490 determines if it is on the path by checking the node's topological 491 elements in the path list. If it is, it adds/adjusts the PPR-ID's 492 shortest path NH towards the next topological path element in the 493 PPR's path list. This process continues at every IGP node as 494 specified in the path description TLV. 496 3.1. PPR Data Plane aspects 498 Data plane type for PPR-ID is selected by the entity (e.g., a 499 controller, locally provisioned by operator), which selects a 500 particular PPR in the network. 502 3.1.1. PPR Native IP Data Planes 504 In an IPv4 network, source routing and packet steering with PPR can 505 be done by selecting the IPv4 data plane type (PPR-IPv4), in PPR Path 506 description with a corresponding IPv4 address/prefix as PPR-ID while 507 signaling the path description in the control plane Section 3.2. 508 Forwarding is done by setting the destination IP address of the 509 packet as PPR-ID at the ingress node of the network. In this case 510 this is an IPv4 address in the tunneled/encapsulated user packet. 511 There is no data plane change or upgrade needed to support this 512 functionality. 514 Similarly, for an IPv6 network source routing and packet steering can 515 be done in IPv6 data plane type (PPR-IPv6), along the path as 516 described in PPR Path description with a corresponding IPv6 address/ 517 prefix as PPR-ID in the control plane Section 3.2. Whatever 518 specified above for IPv4 applies here too, except that destination IP 519 address of the encapsulated data packet at the edge node is an IPv6 520 Address (PPR-ID). This doesn't require any IPv6 extension headers 521 (EH). 523 For a loose path in an IPv4 or IPv6 network (Native IPv4 or IPv6 data 524 planes respectively) the packet has to be encapsulated using the 525 capabilities (either dynamically signaled through 526 [I-D.ietf-isis-encapsulation-cap] or statically provisioned on the 527 nodes) of the next loose PDE in the path description. 529 Consider the network fragment shown in Figure 3 which further 530 illustrates loose routing, and consider PATH-3. Node R2 can reach R5 531 ECMP through R2->R3->R4, and R2->R6->R4, both at cost 2. The path 532 R2->R7->R8->R4 is longer (cost 3) and is not a path that R2 would 533 choose to use it to reach R4. Node R2 (start of the loose segment) 534 is programmed to encapsulate a data packet towards the next loose 535 topological PPR-PDE in the path, which is R4. The NH computed at R1 536 (for PPR-ID r5') would be the shortest path towards R5 i.e., the 537 interfaces towards R2. R2 has an ECMP towards R3 and R6 to reach R4 538 (next PDE in the loose segment), as packet would be encapsulated at 539 R2 for R4 as the destination. R7 and R8 are not involved in this PPR 540 path and so do not need a FIB entry for PPR-ID r5' (the on-path check 541 for PATH-3 fails at these nodes). 543 +---R7-----R8--+ 544 | | 545 | | r5' 546 R1-----R2-----R3------R4-----R5 547 | | r5'' 548 | | 549 +------R6------+ 551 All costs are 1 552 PATH-3: R1-R2-R4-R5 : PPR-ID=r5' 553 PATH-4: R1-R2-R3-R4-R5 : PPR-ID=r5'' 555 Figure 3: Network with Loose Path 557 In a strict path, for example, PATH-4 in Figure 3, PPR-ID is 558 programmed on the data plane at each node of the path, with NH set to 559 the shortest path towards the next topological PPR-PDE. In this 560 case, no further encapsulation of the data packet is required. 562 3.1.2. SR-MPLS with PPR 564 PPR is fully backward compatible with the SR data plane. As control 565 plane PDEs can be extensible and particular data plane identifiers 566 can be expressed to describe the path, in SR case PDEs can contain 567 the SR SIDs. 569 In SR-MPLS, a data packet contains the stack of labels (path steering 570 instructions) which guides the packet traversal in the network. For 571 SR-MPLS data plane, the complete set of label stack is represented 572 with a unique SR SID/Label, PPR-ID, to represent the path. The PPR- 573 ID gets programmed on the data plane of each node, with the 574 appropriate NH computed as specified in Section 3. PPR-ID here is a 575 label/index from the SRGB (like another node SID or global ADJ-SID). 576 PPR path description in the control plane is a set of ordered SIDs 577 represented with PPR-PDEs. Non-Topological segments described along 578 with the topological PDEs can also be programmed in the forwarding 579 plane to enable specific function/service, when the data packet hits 580 with corresponding PPR-ID. 582 For SR-MPLS data plane, either 1 label or 2 labels need to be 583 provisioned on individual nodes on the path description. In the 584 example network Figure 2, for PATH-2 (a loose path), during control 585 plane processing, node R1 programs the bottom label as PPR-ID and the 586 top label as the next topological PPR-PDE in the path, which is a 587 node SID of R5. In the control plane, the NH computed at R1 would be 588 the shortest path towards R5 i.e., the interfaces towards R2 and R4 589 (ECMP). For strict paths, a single label (PPR-ID) is programmed on 590 the data plane along the path, with NH set to the shortest path 591 towards the next topological PPR-PDE in the path description. 593 3.1.3. SRv6, Network Programming and PPR 595 One of the key benefits PPR offers for SRv6 data plane is an 596 optimized data plane as individual path steering SIDs in the data 597 packet is replaced with a path identifier (PPR-ID). Thus potentially 598 avoids MTU, hardware incompatibilities and processing overhead. Few 599 PPR and SRv6 inter working scenarios are listed below. 601 In a simple encapsulation mode without SRH [RFC8754], an SRv6 SID can 602 be used as PPR-ID. With this approach path steering can be brought 603 in with PPR and some of the network functions as defined in [RFC8986] 604 can be realized at the egress node as PPR-ID in this case is a SRv6 605 SID. 607 In SRv6 with SRH, one-way PPR-ID can be used, by setting it as the 608 destination IPv6 address and SL field in SRH is set to 0; here, SRH 609 can contain any other TLVs and non-topological SIDs as needed. 611 Another inter working case can be a multi area IGP deployment. In 612 this case multiple PPR-IDs corresponding to each IGP area can be 613 encoded as SIDs in SRH for an end-to-end path steering with minimal 614 SIDs in SRH. 616 3.2. PPR Control Plane aspects 618 3.2.1. PPR-ID and Data Plane Extensibility 620 The data plane identifier, PPR-ID, describes a path through the 621 network. A data plane type and corresponding PPR-ID can be specified 622 with the advertised path description in the IGP. The PPR-ID type 623 allows data plane extensibility for PPR, though it is currently 624 defined for IPv4, IPv6, SR-MPLS and SRv6 data planes. 626 For native IP data planes, this is mapped to either IPv4 or IPv6 627 address/prefix. For SR-MPLS, PPR-ID is mapped to an MPLS Label/SID 628 and for SRv6, this is mapped to an IPv6-SID. This is further 629 detailed in Section 3.1 and Section 3.1.3. 631 3.2.2. PPR Path Description Elements (PDEs) 633 The path identified by the PPR-ID is described as a set of Path 634 Description Elements (PDEs), each of which represents a segment of 635 the path. Each node determines its location in the path as 636 described, and forwards to the next segment/hop or label of the path 637 description (see the Forwarding Procedure Example later in this 638 document). 640 These PPR-PDEs like SR SIDs, can represent topological elements like 641 links/nodes, backup nodes, as well as non- topological elements such 642 as a service, function, or context on a node with additional control 643 information as needed. 645 A preferred path can be described as a Strict-PPR or a Loose-PPR. In 646 a Strict-PPR all nodes/links on the path are described with SR-SIDs 647 for SR data planes or IPv4/IPV6 addresses for native IP data planes. 648 In a Loose-PPR only some of the nodes/links from source to 649 destination are described. More specifics and restrictions around 650 Strict/Loose PPRs are described in respective data planes in 651 Section 3.1 and Section 3.1.3. Each PDE is described as either an 652 MPLS label towards the NH in MPLS enabled networks, or as an IP NH, 653 in the case of either 'plain'/'native' IP or SRv6 enabled networks. 654 A PPR path is related to a set of PDEs using the TLVs specified in 655 the respective IGPs. 657 3.2.3. ECMP Considerations 659 PPR inherently supports Equal Cost Multi Path (ECMP) for both strict 660 and loose paths. If a path is described using nodes, it would have 661 ECMP NHs established for PPR-ID along the path. In the network shown 662 in Figure 2, for PATH-2, node R1 would establish ECMP NHs computed by 663 the IGP, towards R5 for the PPR-ID r6'. However, one can avoid ECMP 664 on any segment of the path by pinning the path using link identifier 665 to the next segment as specified for PATH-1 in Figure 2. 667 3.2.4. PPR Services along the Path 669 +--------+ 670 | PPR-ID | 671 +--------+-----------+--------+--------+---------+--------+ 672 |PDE-1 | Context-1 |PDE-2 |PDE-x |Service-x|PDE-n | 673 +--------+-----------+--------+--------+---------+--------+ 675 Figure 4: Services along the Preferred Path 677 As shown in Figure 4, some of the services specific to a preferred 678 path, can be encoded as non-topological PDEs and can be part of the 679 path description. These services are applied at the respective nodes 680 along the path. In Figure 4, PDE-1,PDE-2, PDE-x, PDE-n are 681 topological PDEs of a data plane. For SR-MPLS/SRv6 data planes these 682 are simply SIDs and for native IP data planes corresponding non- 683 topological addresses. When the data packet with a PPR-ID is 684 delivered to node-1, the packet is delivered to Context-1. Similarly 685 on node-x, Service-x is applied. These services/functions need to be 686 pre-provisioned on the particular nodes and optionally can be 687 advertised in IGPs. 689 The above gives the basic and light weight service chaining 690 capability with PPR without incurring any additional overhead on the 691 data packet. However, this is limited to fixed services/functions 692 for a path and all data packets using the path will be applied with 693 these services. Flow level exclusions using the same path or 694 differentiated services that need to be applied with in a flow cannot 695 be supported with this mechanism and one has to resort to data plane 696 mechanisms as defined in NSH/SFC [RFC8300]. 698 3.2.5. PPR Graphs 700 In a network of N nodes a total O(N^2) unidirectional paths are 701 necessary to establish any-to-any connectivity, and multiple (k) such 702 path sets may be desirable if multiple path policies are to be 703 supported (lowest latency, highest throughput etc.). 705 In many solutions and topologies, N may be small enough and/or only a 706 small set of paths need to be preferred paths, for example for high 707 value traffic (DetNet, some of the defined 5G slices), and then a 708 point-to-point path structure specified in this document can support 709 these deployments. 711 (PE) (P) (PE) 712 R1---------R2----------R3 r3' 713 | \ |\ | r3'' 714 | \ | \L26 | Rg3' 715 | \ | \ | 716 | \ | \ | 717 | 10\ | 10\ | 718 | \ | \ | 719 | \ | \ | 720 | \ | \ | 721 | \ | 10 \ | 722 R4---------R5---------R6 723 (PE) (P) (PE) 724 PATH-1 : R1-R2-L26-R6-R3 : PPR-ID=r3' 725 PATH-5 : R4-R5-R2-L26-R6-R3 : PPR-ID=r3'' 726 GRAPH-1: R1-R2-L26-R6-R3 : PPR-ID=Rg3' 727 | 728 R4-R5-+ 730 Figure 5: Network with a Graph Structure: PPR TREE 732 However, to address the scale needed when a larger number of PPR 733 paths are required and for TE aware IPFRR Section 4, PPR TREE 734 structure can be used. 736 Consider the network fragment in Figure 5, where two PPR paths, 737 PATH-1 and PATH-5 are shown from different ingress PE nodes (R1, R4) 738 to the same egress PE node (R3). In a simple PPR Tree structure, 739 these 2 paths can be combined to form a PPR Tree structure. PPR Tree 740 is one type of a graph where multiple source nodes are rooted at one 741 particular destination node, with one or more branches. Figure 5, 742 shows a PPR TREE (GRAPH-1), with 2 branches constructed with 743 different PDEs, has a common PDE (node R2) and with a forwarding 744 Identifier Rg3' (PPR-ID) at the destination node R3. 746 Each PPR Tree uses one label/SID and defines paths from any set of 747 nodes to one destination, this reduces the number of entries needed. 748 For example, it reduces the number of forwarding identifiers needed 749 in SR-MPLS data plane Section 3.1.2 with PPR, which are derived from 750 the SRGB at the egress node. These paths are form a tree rooted at 751 the destination. In other word, PPR Tree identifiers are destination 752 identifiers and PPR Trees are path engineered destination routes 753 (like IP routes) and its scaling simplifies to linear in N i.e., 754 O(k*N). 756 In a completely different usage paradigm, a PPR Graph can also have 757 multiple forwarding identifiers (PPR-IDs). Based on the algorithm 758 specified for the Graph, path computation can be done in a 759 distributed fashion in the network to establish the forwarding over 760 the graph. Various types of PPR Graphs, rules for construction and 761 their usage details will be described in future revisions. 763 3.2.6. PPR Multi-Domain Scenarios 765 PPR can be extended to multi-domain, including multi-area scenarios 766 as shown in Figure 6. 768 D1 D2 769 ...... ...... 770 . .r2' . .r4' 771 R1........R2--R3........R4 772 . . . . 773 ...... ...... 775 PATH-6 = R1-R2-R3-R4 777 Figure 6: Multi-Domain Network with PPR 779 Operation of PPR within the domain is as described in the preceding 780 sections of this document. The key difference in operation in multi- 781 domain concerns the value of the PPR-ID in the packet. There are 782 three approaches that can be taken: 784 1. The PPR-ID is constant along the end-end-path. This requires 785 coordination of the PPR-ID in each domain. This has the 786 convenience of a uniform identity for the path. However, whilst 787 an IPv6 network has a large PPR identity space, this is not the 788 case for MPLS and is less the case for IPv4. The approach also 789 has the disadvantage that the entirety of the domains involved 790 need to be configured and provisioned with the common value. In 791 the network shown in Figure 6 The PPR-ID for PATH-6 is r4'. 793 2. The PPR-ID for each individual domain is the value that best 794 suits that domain, and the PPR-ID is swapped at the boundary of 795 the domains. This allows a PPR-ID that best suits arch domain. 796 This is similar to the approach taken with multi-segment 797 pseudowire [RFC5659]. This approach better suits the needs of 798 network layers with limited identity resources. It also enables 799 the better coordination of PPR-IDs. In this approach the PPR-ID 800 for PATH-6 would be r2' in domain D1 and r4' in domain D2. These 801 two PPR-IDs would be distributed in their own domains and the 802 only inter-domain co-ordination required would be between R2 and 803 R3. 805 3. A variant of (2) is that the PPR-IDs are domain specific, but a 806 segment routing approach is taken in which they encoded at 807 ingress (R1), and are popped at the inter-domain boarder. This 808 requires that the domain ingress and egress routers support 809 segment routing data-plane capability. 811 Although the example shown in Figure 6 shows the case of two domains, 812 nothing limits the design to just two IGP areas. This further 813 explained below. 815 In controller based deployments, each IGP area can have separate 816 north bound and south bound communication end points with PCE/SDN 817 controller, in their respective domain. It is expected that PPR 818 paths for each IGP level are computed and provisioned at the ingress 819 nodes of the corresponding area's area boarder router. Separate path 820 advertisement in the respective IGP area should happen with the same 821 PPR-ID. With this, only PPR-ID needs to be leaked to the other area, 822 as long as a path is available in the destination area for that PPR- 823 ID. If the destination area is not provisioned with path 824 information, area boarder shall not leak the PPR-ID to the 825 destination area. 827 3.3. PPR Management Plane Aspects 829 3.3.1. IGP Metric Independent Paths/Graphs 831 PRR allows a considerable simplification in the design and management 832 of networks. In a best effort network the setting of the IGP metrics 833 is a complex problem with competing constraints. A set of metrics 834 the is optimal for traffic distribution under normal operation may 835 not be optimal under conditions of failure of one or more of the 836 network components. Nor is that choice of metrics necessarily best 837 for operation under all IPFRR conditions. When SR is introduced to 838 the network a further constraint on metrics is the need to limit the 839 size of the SID stack/list. These problems further increase with the 840 introduction of demanding technologies such as network slicing and 841 deterministic networking. 843 Some mitigation occurs with the use of FlexAlgo 844 [I-D.ietf-lsr-flex-algo] but fundamentally this is still an approach 845 that is critically dependent on the per-flex-algo provisioning of 846 different metrics on participating nodes, that operate in both the 847 normal and the failure case. 849 PPR allows the network to simply introduce metric independent paths 850 on a strategic or tactical basis. Being metric independent each PPR 851 path operates ships-in-the-night with respect to all other paths. 852 This means that the network management system can address network 853 tuning on a case by case basis only needing to worry about the 854 traffic matrix along the path rather than needing to deconvolve the 855 impact of tuning a metric on the whole traffic matrix. In other 856 words, PPR is a direct method of tuning the traffic rather than an 857 the indirect method that metric tuning provides. 859 An example that makes this clear is the maximally redundant tree 860 (MRT) approach to IPFRR. MRT requires the tuning of metrics to tune 861 the paths, and a common algorithm for all nodes in the network. An 862 equivalent solution can be introduced to the network by the insertion 863 of a pair of PPR graphs by the network management system. 864 Furthermore the topology of these graphs are independent of all other 865 graphs, allowing the tuning and migration of the repair paths in the 866 network management system. 868 Thus PPR allows the operator to focus on the desired traffic path of 869 specific groups of packets independent of the desired path of the 870 packets in all other paths. 872 3.3.2. Granular OAM 874 For some of the deployments as described in Section 2, the ability to 875 collect certain statistics about PPR path usage, including how much 876 traffic a PPR path carries and at what times from any node in the 877 network is a critical requirement. Such statistics can be useful to 878 account for the degree of usage of a path and provide additional 879 operational insights, including usage patterns and trending 880 information. 882 Traffic for certain PPRs may have more stringent requirement w.r.t 883 accounting for critical SLAs (e.g. 5G non-eMBB slice) and should 884 account for any link/node failures along the path. Optional per path 885 attributes like Packet Traffic Accounting" and "Traffic Statistics" 886 instructs all the respective nodes along the path to provision the 887 hardware and to account for the respective traffic statistics. 888 Traffic accounting should be applied based on the PPR-ID. This 889 capability allows a more granular and dynamic measurement of traffic 890 statistics for only certain PPRs as needed. 892 As routing happens on the abstracted path identifier in the packet, 893 no additional per packet instruction is needed for achieving the 894 above functionality regardless of the data plane used in the network 895 Section 3.1. 897 4. Preferred Path Loop Free Alternatives (pLFA ) 899 PPR can be used as a method of providing IPFRR. Preferred Path Loop- 900 Free Alternate (pLFA) allows the construction of arbitrary engineered 901 backup paths pLFA and inherits the low packet overhead of PPR 902 requiring a simple encapsulation and a single path identifier for any 903 path of any complexity. 905 pLFA provides a superset of RSVP-TE repairs (complete with traffic 906 engineering capability) and Topology Independent Loop-Free Alternates 907 (TI-LFA) [I-D.ietf-rtgwg-segment-routing-ti-lfa]. However, unlike 908 the TI-LFA approaches PPR is applicable to a more complete set of 909 data planes (for example MPLS, both IPv4 and IPv6 and Ethernet) where 910 it can provide a rich set of IPFRR capabilities ranging from simple 911 best-effort repair calculated at the point of local repair (PLR) to 912 full traffic engineered paths. For any repair path pLFA requires one 913 encapsulation and one PPR-ID, regardless of the complexity and 914 constraints of the path. 916 For a basic understanding of pLFA consider the case of a link repair 917 shown in this example as shown in Figure 7, we assume that we have a 918 path A-B-C-D that the packet must traverse. This may be a normal 919 best effort path or a traffic engineered path. 921 c' 922 A---B--//--C---D 923 | | 924 E---F--G 925 f' 927 Figure 7 929 PPR is used to inject the repair path B->E->F->G->C into the network 930 with a PPR-ID of c'. B is monitoring the health of link B->C, for 931 example looking for loss-of-light, or using Bidirectional Forwarding 932 Detection (BFD) [RFC5880]. When B detects a failure it encapsulates 933 the packet to C by adding to the packet an encapsulation with a 934 destination address set as the PPR-ID for c' and then sending the 935 packet to E. At C the packet is decapsulated and sent to D. The 936 path B->E->F->G->C may be a traffic engineered path or it may be a 937 best effort path. This may of course be the post convergence path 938 from B to C, as is used by TI-LFA However B may have at its disposal 939 multiple paths to C with different properties for different traffic 940 classes. In this case each path to be used would require its own 941 PPR-ID (c', c'' etc.). Because pLFA only requires a single path 942 identifier regardless of the complexity of the path is not necessary 943 constrain the path to be a small number of loose source routed paths 944 to protect against MTU or maximum SID count considerations. 946 pLFA supports the usual IPFRR features such as early release into 947 Q-space, node repair, and shared risk link group support, LANs, ECMP 948 and multi-homed prefixes. However the ability to apply repair graphs 949 Section 3.2.5 is unique to pLFA. The use of graphs in IPFRR repair 950 simplifies the construction of traffic engineered repair paths, and 951 allows for the construction of arbitrary maximally redundant tree 952 repair paths. 954 Of importance in any IPFRR strategy in a loosely routed network, 955 including normal connectionless routing is the ability to support 956 loop-free convergence. This problem is described in [RFC5715]. 957 [I-D.ietf-rtgwg-segment-routing-ti-lfa] has proposed a mitigation 958 technique for failures (noted above) and pLFA is able to support 959 this. However a network supporting high reliability traffic may find 960 mitigation insufficient. Also disruption can take place on network 961 component inclusion (or repair/recovery) and TI-LFA is silent on 962 this. A network using pLFA is compatible with all of the know loop- 963 free convergence and loop mitigation approaches described in 964 [RFC5715]. 966 5. Traffic Engineering Attributes 968 In addition to determining the nodes to traverse, there may be other 969 aspects that need to be set up for a path. Most notably, this 970 concerns the allocation and reservation of resources along the path 971 to help ensure the service levels, i.e. the Quality of Service that 972 is delivered across the path, will be acceptable for the traffic 973 routed across the path (critical in some deployments as listed in 974 Section 2). 976 While SR allows packet steering on a specified path (for MPLS and 977 IPv6 with SRH), it does not have any notion of QoS or resources 978 reserved along the path. The determination of which resources to 979 allocate and reserve on nodes across the path, like the determination 980 of the path itself, can in many cases be made by a controller. 981 Accordingly, PPR includes extensions that allow to manage those 982 reservations, in addition to the path itself. 984 Key aspect of the solution concerns with specifying the resources to 985 be reserved along the preferred path, through path attributes TLVs. 986 Reservations are expressed in terms of required resources 987 (bandwidth), traffic characteristics (burst size), and service level 988 parameters (expected maximum latency at each hop) based on the 989 capabilities of each node and link along the path. The second part 990 of the solution is providing mechanism to indicate the status of the 991 reservations requested i.e. if these have been honored by individual 992 node/links in the path. This can be done by defining a new TLV/Sub- 993 TLV in respective IGPs. Another aspect is additional node level TLVs 994 and extensions to IS-IS-TE [RFC7810] and OSPF-TE [RFC7471] to provide 995 accounting/usage statistics that have to be maintained at each node 996 per preferred path. 998 6. IANA Considerations 1000 This document does not request any allocations from IANA. 1002 7. Security Considerations 1004 Advertisement of the additional information defined in this document 1005 introduces no new security concerns in IGP protocols. However, for 1006 extensions related to SR-MPLS and SRH data planes, those particular 1007 data plane security considerations does apply here. 1009 8. References 1011 8.1. Normative References 1013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1014 Requirement Levels", BCP 14, RFC 2119, 1015 DOI 10.17487/RFC2119, March 1997, 1016 . 1018 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1019 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1020 May 2017, . 1022 8.2. Informative References 1024 [I-D.ietf-isis-encapsulation-cap] 1025 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 1026 L. M., and L. Jalil, "Advertising Tunnelling Capability in 1027 IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in 1028 progress), April 2017. 1030 [I-D.ietf-lsr-flex-algo] 1031 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1032 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1033 algo-18 (work in progress), October 2021. 1035 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 1036 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 1037 Decraene, B., and D. Voyer, "Topology Independent Fast 1038 Reroute using Segment Routing", draft-ietf-rtgwg-segment- 1039 routing-ti-lfa-07 (work in progress), June 2021. 1041 [I-D.ietf-teas-enhanced-vpn] 1042 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 1043 Framework for Enhanced Virtual Private Network (VPN+) 1044 Services", draft-ietf-teas-enhanced-vpn-09 (work in 1045 progress), October 2021. 1047 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1048 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1049 DOI 10.17487/RFC5440, March 2009, 1050 . 1052 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 1053 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 1054 DOI 10.17487/RFC5659, October 2009, 1055 . 1057 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 1058 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 1059 2010, . 1061 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1062 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1063 . 1065 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1066 and A. Bierman, Ed., "Network Configuration Protocol 1067 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1068 . 1070 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1071 Previdi, "OSPF Traffic Engineering (TE) Metric 1072 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1073 . 1075 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 1076 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 1077 RFC 7810, DOI 10.17487/RFC7810, May 2016, 1078 . 1080 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1081 "Network Service Header (NSH)", RFC 8300, 1082 DOI 10.17487/RFC8300, January 2018, 1083 . 1085 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1086 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1087 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1088 July 2018, . 1090 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1091 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1092 Routing with the MPLS Data Plane", RFC 8660, 1093 DOI 10.17487/RFC8660, December 2019, 1094 . 1096 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1097 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1098 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1099 . 1101 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1102 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1103 (SRv6) Network Programming", RFC 8986, 1104 DOI 10.17487/RFC8986, February 2021, 1105 . 1107 Authors' Addresses 1109 Stewart Bryant (editor) 1110 University of Surrey 5GIC 1112 Email: sb@stewartbryant.com 1114 Uma Chunduri (editor) 1115 Intel Corporation 1117 Email: umac.ietf@gmail.com 1119 Alexander Clemm 1120 Futurewei 1122 Email: ludwig@clemm.org