idnits 2.17.00 (12 Aug 2021) /tmp/idnits65290/draft-ietf-spring-segment-routing-15.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 date (January 25, 2018) is 1570 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: draft-ietf-6man-segment-routing-header has been published as RFC 8754 == Outdated reference: draft-ietf-idr-bgpls-segment-routing-epe has been published as RFC 9086 == Outdated reference: draft-ietf-isis-segment-routing-extensions has been published as RFC 8667 == Outdated reference: draft-ietf-ospf-ospfv3-segment-routing-extensions has been published as RFC 8666 == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665 == Outdated reference: draft-ietf-pce-segment-routing has been published as RFC 8664 == Outdated reference: draft-ietf-spring-oam-usecase has been published as RFC 8403 == Outdated reference: draft-ietf-spring-resiliency-use-cases has been published as RFC 8355 == Outdated reference: draft-ietf-spring-segment-routing-central-epe has been published as RFC 9087 == Outdated reference: draft-ietf-spring-segment-routing-mpls has been published as RFC 8660 == Outdated reference: draft-ietf-spring-sr-yang has been published as RFC 9020 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: July 29, 2018 L. Ginsberg 6 Cisco Systems, Inc 7 B. Decraene 8 S. Litkowski 9 Orange 10 R. Shakir 11 Google, Inc. 12 January 25, 2018 14 Segment Routing Architecture 15 draft-ietf-spring-segment-routing-15 17 Abstract 19 Segment Routing (SR) leverages the source routing paradigm. A node 20 steers a packet through an ordered list of instructions, called 21 segments. A segment can represent any instruction, topological or 22 service-based. A segment can have a semantic local to an SR node or 23 global within an SR domain. SR allows to enforce a flow through any 24 topological path while maintaining per-flow state only at the ingress 25 nodes to the SR domain. 27 Segment Routing can be directly applied to the MPLS architecture with 28 no change on the forwarding plane. A segment is encoded as an MPLS 29 label. An ordered list of segments is encoded as a stack of labels. 30 The segment to process is on the top of the stack. Upon completion 31 of a segment, the related label is popped from the stack. 33 Segment Routing can be applied to the IPv6 architecture, with a new 34 type of routing header. A segment is encoded as an IPv6 address. An 35 ordered list of segments is encoded as an ordered list of IPv6 36 addresses in the routing header. The active segment is indicated by 37 the Destination Address of the packet. The next active segment is 38 indicated by a pointer in the new routing header. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on July 29, 2018. 63 Copyright Notice 65 Copyright (c) 2018 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 8 83 3.1. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 8 84 3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 9 85 3.1.2. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 10 86 3.1.3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 11 87 3.2. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 12 88 3.3. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 12 89 3.3.1. Anycast SID in SR-MPLS . . . . . . . . . . . . . . . 12 90 3.4. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 15 91 3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 16 92 3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 17 93 3.5. Inter-Area Considerations . . . . . . . . . . . . . . . . 18 95 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 19 96 4.1. BGP Prefix Segment . . . . . . . . . . . . . . . . . . . 19 97 4.2. BGP Peering Segments . . . . . . . . . . . . . . . . . . 19 98 5. Binding Segment . . . . . . . . . . . . . . . . . . . . . . . 20 99 5.1. IGP Mirroring Context Segment . . . . . . . . . . . . . . 20 100 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 103 8.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 8.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 105 8.3. Congestion Control . . . . . . . . . . . . . . . . . . . 24 106 9. Manageability Considerations . . . . . . . . . . . . . . . . 24 107 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 108 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 109 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 110 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 111 12.2. Informative References . . . . . . . . . . . . . . . . . 27 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 114 1. Introduction 116 Segment Routing (SR) leverages the source routing paradigm. A node 117 steers a packet through an SR Policy instantiated as an ordered list 118 of instructions called segments. A segment can represent any 119 instruction, topological or service-based. A segment can have a 120 semantic local to an SR node or global within an SR domain. SR 121 supports per-flow explicit routing while maintaining per-flow state 122 only at the ingress nodes to the SR domain. 124 A segment is often referred to by its Segment Identifier (SID). 126 A segment may be associated with a topological instruction. A 127 topological local segment may instruct a node to forward the packet 128 via a specific outgoing interface. A topological global segment may 129 instruct an SR domain to forward the packet via a specific path to a 130 destination. Different segments may exist for the same destination, 131 each with different path objectives (e.g., which metric is minimized, 132 what constraints are specified). 134 A segment may be associated with a service instruction (e.g. the 135 packet should be processed by a container or VM associated with the 136 segment). A segment may be associated with a QoS treatment (e.g., 137 shape the packets received with this segment at x Mbps). 139 The SR architecture supports any type of instruction associated with 140 a segment. 142 The SR architecture supports any type of control-plane: distributed, 143 centralized or hybrid. 145 In a distributed scenario, the segments are allocated and signaled by 146 IS-IS or OSPF or BGP. A node individually decides to steer packets 147 on a source-routed policy (e.g., pre-computed local protection 148 [I-D.ietf-spring-resiliency-use-cases] ) . A node individually 149 computes the source-routed policy. 151 In a centralized scenario, the segments are allocated and 152 instantiated by an SR controller. The SR controller decides which 153 nodes need to steer which packets on which source-routed policies. 154 The SR controller computes the source-routed policies. The SR 155 architecture does not restrict how the controller programs the 156 network. Likely options are NETCONF, PCEP and BGP. The SR 157 architecture does not restrict the number of SR controllers. 158 Specifically multiple SR controllers may program the same SR domain. 159 The SR architecture allows these SR controllers to discover which 160 SID's are instantiated at which nodes and which sets of local (SRLB) 161 and global labels (SRGB) are available at which node. 163 A hybrid scenario complements a base distributed control-plane with a 164 centralized controller. For example, when the destination is outside 165 the IGP domain, the SR controller may compute a source-routed policy 166 on behalf of an IGP node. The SR architecture does not restrict how 167 the nodes which are part of the distributed control-plane interact 168 with the SR controller. Likely options are PCEP and BGP. 170 Hosts MAY be part of an SR Domain. A centralized controller can 171 inform hosts about policies either by pushing these policies to hosts 172 or responding to requests from hosts. 174 The SR architecture can be instantiated on various dataplanes. This 175 document introduces two dataplane instantiations of SR: SR over MPLS 176 (SR-MPLS) and SR over IPv6 (SRv6). 178 Segment Routing can be directly applied to the MPLS architecture with 179 no change on the forwarding plane 180 [I-D.ietf-spring-segment-routing-mpls] A segment is encoded as an 181 MPLS label. An SR Policy is instantiated as a stack of labels. The 182 segment to process (the active segment) is on the top of the stack. 183 Upon completion of a segment, the related label is popped from the 184 stack. 186 Segment Routing can be applied to the IPv6 architecture with a new 187 type of routing header called the SR header (SRH) 188 [I-D.ietf-6man-segment-routing-header] . An instruction is associated 189 with a segment and encoded as an IPv6 address. An SRv6 segment is 190 also called an SRv6 SID. An SR Policy is instantiated as an ordered 191 list of SRv6 SID's in the routing header. The active segment is 192 indicated by the Destination Address(DA) of the packet. The next 193 active segment is indicated by the SegmentsLeft (SL) pointer in the 194 SRH. When an SRv6 SID is completed, the SL is decremented and the 195 next segment is copied to the DA. When a packet is steered on an SR 196 policy, the related SRH is added to the packet. 198 In the context of an IGP-based distributed control-plane, two 199 topological segments are defined: the IGP adjacency segment and the 200 IGP prefix segment. 202 In the context of a BGP-based distributed control-plane, two 203 topological segments are defined: the BGP peering segment and the BGP 204 prefix segment. 206 The headend of an SR Policy binds a SID (called Binding segment or 207 BSID) to its policy. When the headend receives a packet with active 208 segment matching the BSID of a local SR Policy, the headend steers 209 the packet into the associated SR Policy. 211 This document defines the IGP, BGP and Binding segments for the SR- 212 MPLS and SRv6 dataplanes. 214 Note: This document defines the architecture for Segment Routing, 215 including definitions of basic objects and functions and a 216 description of the overall design. It does NOT define the means of 217 implementing the architecture - that is contained in numerous 218 referencing documents, some of which are mentioned in this document 219 as a convenience to the reader. 221 2. Terminology 223 SR-MPLS: the instantiation of SR on the MPLS dataplane 225 SRv6: the instantiation of SR on the IPv6 dataplane. 227 Segment: an instruction a node executes on the incoming packet (e.g., 228 forward packet according to shortest path to destination, or, forward 229 packet through a specific interface, or, deliver the packet to a 230 given application/service instance). 232 SID: a segment identifier. Note that the term SID is commonly used 233 in place of the term Segment, though this is technically imprecise as 234 it overlooks any necessary translation. 236 SR-MPLS SID: an MPLS label or an index value into an MPLS label space 237 explicitly associated with the segment. 239 SRv6 SID: an IPv6 address explicitly associated with the segment. 241 Segment Routing Domain (SR Domain): the set of nodes participating in 242 the source based routing model. These nodes may be connected to the 243 same physical infrastructure (e.g., a Service Provider's network). 244 They may as well be remotely connected to each other (e.g., an 245 enterprise VPN or an overlay). If multiple protocol instances are 246 deployed, the SR domain most commonly includes all of the protocol 247 instances in a network. However, some deployments may wish to sub- 248 divide the network into multiple SR domains, each of which includes 249 one or more protocol instances. It is expected that all nodes in an 250 SR Domain are managed by the same administrative entity. 252 Active Segment: the segment that is used by the receiving router to 253 process the packet. In the MPLS dataplane it is the top label. In 254 the IPv6 dataplane it is the destination address. 255 [I-D.ietf-6man-segment-routing-header]. 257 PUSH: the instruction consisting of the insertion of a segment at the 258 top of the segment list. In SR-MPLS the top of the segment list is 259 the topmost (outer) label of the label stack. In SRv6, the top of 260 the segment list is represented by the first segment in the Segment 261 Routing Header as defined in [I-D.ietf-6man-segment-routing-header]. 263 NEXT: when the active segment is completed, NEXT is the instruction 264 consisting of the inspection of the next segment. The next segment 265 becomes active. In SR-MPLS, NEXT is implemented as a POP of the top 266 label. In SRv6, NEXT is implemented as the copy of the next segment 267 from the SRH to the Destination Address of the IPv6 header. 269 CONTINUE: the active segment is not completed and hence remains 270 active. In SR-MPLS, CONTINUE instruction is implemented as a SWAP of 271 the top label. [RFC3031] In SRv6, this is the plain IPv6 forwarding 272 action of a regular IPv6 packet according to its Destination Address. 274 SR Global Block (SRGB): the set of global segments in the SR Domain. 275 If a node participates in multiple SR domains, there is one SRGB for 276 each SR domain. In SR-MPLS, SRGB is a local property of a node and 277 identifies the set of local labels reserved for global segments. In 278 SR-MPLS, using identical SRGBs on all nodes within the SR Domain is 279 strongly recommended. Doing so eases operations and troubleshooting 280 as the same label represents the same global segment at each node. 281 In SRv6, the SRGB is the set of global SRv6 SIDs in the SR Domain. 283 SR Local Block (SRLB): local property of an SR node. If a node 284 participates in multiple SR domains, there is one SRLB for each SR 285 domain. In SR-MPLS, SRLB is a set of local labels reserved for local 286 segments. In SRv6, SRLB is a set of local IPv6 addresses reserved 287 for local SRv6 SID's. In a controller-driven network, some 288 controllers or applications may use the control plane to discover the 289 available set of local segments. 291 Global Segment: a segment which is part of the SRGB of the domain. 292 The instruction associated to the segment is defined at the SR Domain 293 level. A topological shortest-path segment to a given destination 294 within an SR domain is a typical example of a global segment. 296 Local Segment: In SR-MPLS, this is a local label outside the SRGB. 297 It may be part of the explicitly advertised SRLB. In SRv6, this can 298 be any IPv6 address i.e., the address may be part of the SRGB but 299 used such that it has local significance. The instruction associated 300 to the segment is defined at the node level. 302 IGP Segment: the generic name for a segment attached to a piece of 303 information advertised by a link-state IGP, e.g. an IGP prefix or an 304 IGP adjacency. 306 IGP-Prefix Segment: an IGP-Prefix Segment is an IGP Segment 307 representing an IGP prefix. When an IGP-Prefix Segment is global 308 within the SR IGP instance/topology it identifies an instruction to 309 forward the packet along the path computed using the routing 310 algorithm specified in the algorithm field, in the topology and the 311 IGP instance where it is advertised. Also referred to as Prefix 312 Segment. 314 Prefix SID: the SID of the IGP-Prefix Segment. 316 IGP-Anycast Segment: an IGP-Anycast Segment is an IGP-Prefix Segment 317 which identify an anycast prefix advertised by a set of routers. 319 Anycast-SID: the SID of the IGP-Anycast Segment. 321 IGP-Adjacency Segment: an IGP-Adjacency Segment is an IGP Segment 322 attached to a unidirectional adjacency or a set of unidirectional 323 adjacencies. By default, an IGP-Adjacency Segment is local (unless 324 explicitly advertised otherwise) to the node that advertises it. 325 Also referred to as Adjacency Segment. 327 Adj-SID: the SID of the IGP-Adjacency Segment. 329 IGP-Node Segment: an IGP-Node Segment is an IGP-Prefix Segment which 330 identifies a specific router (e.g., a loopback). Also referred to as 331 Node Segment. 333 Node-SID: the SID of the IGP-Node Segment. 335 SR Policy: an ordered list of segments. The headend of an SR Policy 336 steers packets onto the SR policy. The list of segments can be 337 specified explicitly in SR-MPLS as a stack of labels and in SRv6 as 338 an ordered list of SRv6 SID's. Alternatively, the list of segments 339 is computed based on a destination and a set of optimization 340 objective and constraints (e.g., latency, affinity, SRLG, ...). The 341 computation can be local or delegated to a PCE server. An SR policy 342 can be configured by the operator, provisioned via NETCONF [RFC6241] 343 or provisioned via PCEP [RFC5440] . An SR policy can be used for 344 traffic-engineering, OAM or FRR reasons. 346 Segment List Depth: the number of segments of an SR policy. The 347 entity instantiating an SR Policy at a node N should be able to 348 discover the depth insertion capability of the node N. For example, 349 the PCEP SR capability advertisement described in 350 [I-D.ietf-pce-segment-routing] is one means of discovering this 351 capability. 353 Forwarding Information Base (FIB): the forwarding table of a node 355 3. Link-State IGP Segments 357 Within an SR domain, an SR-capable IGP node advertises segments for 358 its attached prefixes and adjacencies. These segments are called IGP 359 segments or IGP SIDs. They play a key role in Segment Routing and 360 use-cases as they enable the expression of any path throughout the SR 361 domain. Such a path is either expressed as a single IGP segment or a 362 list of multiple IGP segments. 364 Advertisement of IGP segments requires extensions in link-state IGP 365 protocols. These extensions are defined in 366 [I-D.ietf-isis-segment-routing-extensions] 367 [I-D.ietf-ospf-segment-routing-extensions] 368 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 370 3.1. IGP-Prefix Segment, Prefix-SID 372 An IGP-Prefix segment is an IGP segment attached to an IGP prefix. 373 An IGP-Prefix segment is global (unless explicitly advertised 374 otherwise) within the SR domain. The context for an IGP-Prefix 375 segment includes the prefix, topology, and algorithm. Multiple SIDs 376 MAY be allocated to the same prefix so long as the tuple is unique. 379 Multiple instances and topologies are defined in IS-IS and OSPF in: 380 [RFC5120], [RFC8202], [RFC6549] and [RFC4915]. 382 3.1.1. Prefix-SID Algorithm 384 Segment Routing supports the use of multiple routing algorithms i.e, 385 different constraint based shortest path calculations can be 386 supported. An algorithm identifier is included as part of a Prefix- 387 SID advertisement. Specification of how an algorithm specific path 388 calculation is done is required in the document defining the 389 algorithm. 391 This document defines two algorithms: 393 o "Shortest Path": this algorithm is the default behavior. The 394 packet is forwarded along the well known ECMP-aware SPF algorithm 395 employed by the IGPs. However it is explicitly allowed for a 396 midpoint to implement another forwarding based on local policy. 397 The "Shortest Path" algorithm is in fact the default and current 398 behavior of most of the networks where local policies may override 399 the SPF decision. 401 o "Strict Shortest Path (Strict-SPF)": This algorithm mandates that 402 the packet is forwarded according to ECMP-aware SPF algorithm and 403 instructs any router in the path to ignore any possible local 404 policy overriding the SPF decision. The SID advertised with 405 Strict-SPF algorithm ensures that the path the packet is going to 406 take is the expected, and not altered, SPF path. Note that Fast 407 Reroute (FRR) [RFC5714] mechanisms are still compliant with the 408 Strict Shortest Path. In other words, a packet received with a 409 Strict-SPF SID may be rerouted through a FRR mechanism. Strict- 410 SPF uses the same topology used by "Shortest Path". Obviously, 411 nodes which do not support Strict-SPF will not install forwarding 412 entries for this algorithm. Restricting the topology only to 413 those nodes which support this algorithm will not produce the 414 desired forwarding paths since the desired behavior is to follow 415 the path calculated by "Shortest Path". Therefore, a source SR 416 node MUST NOT use a source-routing policy containing a strict SPF 417 segment if the path crosses a node not supporting the strict-SPF 418 algorithm. 420 An IGP-Prefix Segment identifies the path, to the related prefix, 421 computed as per the associated algorithm. A packet injected anywhere 422 within the SR domain with an active Prefix-SID is expected to be 423 forwarded along a path computed using the specified algorithm. For 424 this to be possible, a fully connected topology of routers supporting 425 the specified algorithm is required. 427 3.1.2. SR-MPLS 429 When SR is used over the MPLS dataplane SIDs are an MPLS label or an 430 index into an MPLS label space (either SRGB or SRLB). 432 Where possible, it is recommended that identical SRGBs be configured 433 on all nodes in an SR Domain. This simplifies troubleshooting as the 434 same label will be associated with the same prefix on all nodes. In 435 addition, it simplifies support for anycast as detailed in 436 Section 3.3. 438 The following behaviors are associated with SR operating over the 439 MPLS dataplane: 441 o the IGP signaling extension for IGP-Prefix segment includes a flag 442 to indicate whether directly connected neighbors of the node on 443 which the prefix is attached should perform the NEXT operation or 444 the CONTINUE operation when processing the SID. This behavior is 445 equivalent to Penultimate Hop Popping (NEXT) or Ultimate Hop 446 Popping (CONTINUE) in MPLS. 448 o A Prefix-SID is allocated in the form of an MPLS label (or an 449 index in the SRGB) according to a process similar to IP address 450 allocation. Typically, the Prefix-SID is allocated by policy by 451 the operator (or NMS) and the SID very rarely changes. 453 o While SR allows to attach a local segment to an IGP prefix, it is 454 specifically assumed that when the terms "IGP-Prefix Segment" and 455 "Prefix-SID" are used, the segment is global (the SID is allocated 456 from the SRGB or as an index into the advertised SRGB). This is 457 consistent with all the described use-cases that require global 458 segments attached to IGP prefixes. 460 o The allocation process MUST NOT allocate the same Prefix-SID to 461 different IP prefixes. 463 o If a node learns a Prefix-SID having a value that falls outside 464 the locally configured SRGB range, then the node MUST NOT use the 465 Prefix-SID and SHOULD issue an error log reporting a 466 misconfiguration. 468 o If a node N advertises Prefix-SID SID-R for a prefix R that is 469 attached to N, if N specifies CONTINUE as the operation to be 470 performed by directly connected neighbors, N MUST maintain the 471 following FIB entry: 473 Incoming Active Segment: SID-R 474 Ingress Operation: NEXT 475 Egress interface: NULL 477 o A remote node M MUST maintain the following FIB entry for any 478 learned Prefix-SID SID-R attached to IP prefix R: 480 Incoming Active Segment: SID-R 481 Ingress Operation: 482 If the next-hop of R is the originator of R 483 and instructed to remove the active segment: NEXT 484 Else: CONTINUE 485 Egress interface: the interface towards the next-hop along the 486 path computed using the algorithm advertised with 487 the SID toward prefix R. 489 As Prefix-SIDs are specific to a given algorithm, if traffic 490 associated with an algorithm arrives at a node which does not support 491 that algorithm the traffic will be dropped as there will be no 492 forwarding entry matching the incoming label. 494 3.1.3. SRv6 496 When SR is used over the IPv6 dataplane: 498 o A Prefix-SID is an IPv6 address. 500 o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node 501 addresses are not SRv6 SIDs by default. 503 A node N advertising an IPv6 address R usable as a segment identifier 504 MUST maintain the following FIB entry: 506 Incoming Active Segment: R 507 Ingress Operation: NEXT 508 Egress interface: NULL 510 Note that forwarding to R does not require an entry in the FIBs of 511 all other routers for R. Forwarding can be and most often will be 512 achieved by a shorter mask prefix which covers R. 514 Independent of Segment Routing support, any remote IPv6 node will 515 maintain a plain IPv6 FIB entry for any prefix, no matter if the 516 prefix represents a segment or not. This allows forwarding of 517 packets to the node which owns the SID even by nodes which do not 518 support Segment Routing. 520 Support of multiple algorithms applies to SRv6. Since algorithm 521 specific SIDs are simply IPv6 addresses, algorithm specific 522 forwarding entries can be achieved by assigning algorithm specific 523 subnets to the (set of) algorithm specific SIDs which a node 524 allocates. 526 Nodes which do not support a given algorithm may still have a FIB 527 entry covering an algorithm specific address even though an algorithm 528 specific path has not been calculated by that node. This is 529 mitigated by the fact that nodes which do not support a given 530 algorithm will not be included in the topology associated with that 531 algorithm specific SPF and so traffic using the algorithm specific 532 destination will normally not flow via the excluded node. If such 533 traffic were to arrive and be forwarded by such a node, it will still 534 progress towards the destination node. The nexthop will either be a 535 node which supports the algorithm - in which case the packet will be 536 forwarded along algorithm specific paths (or be dropped if none are 537 available) - or the nexthop will be a node which does NOT support the 538 algorithm - in which case the packet will continue to be forwarded 539 along Algorithm 0 paths towards the destination node. 541 3.2. IGP-Node Segment, Node-SID 543 An IGP Node-SID MUST NOT be associated with a prefix that is owned by 544 more than one router within the same routing domain. 546 3.3. IGP-Anycast Segment, Anycast SID 548 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 549 shortest-path forwarding towards the closest node of the anycast set. 550 This is useful to express macro-engineering policies or protection 551 mechanisms. 553 An IGP-Anycast segment MUST NOT reference a particular node. 555 Within an anycast group, all routers in an SR domain MUST advertise 556 the same prefix with the same SID value. 558 3.3.1. Anycast SID in SR-MPLS 559 +--------------+ 560 | Group A | 561 |192.0.2.10/32 | 562 | SID:100 | 563 | | 564 +-----------A1---A3----------+ 565 | | | \ / | | | 566 SID:10 | | | / | | | SID:30 567 203.0.113.1/32 | | | / \ | | | 203.0.113.3/32 568 PE1------R1----------A2---A4---------R3------PE3 569 \ /| | | |\ / 570 \ / | +--------------+ | \ / 571 \ / | | \ / 572 / | | / 573 / \ | | / \ 574 / \ | +--------------+ | / \ 575 / \| | | |/ \ 576 PE2------R2----------B1---B3---------R4------PE4 577 203.0.113.2/32 | | | \ / | | | 203.0.113.4/32 578 SID:20 | | | / | | | SID:40 579 | | | / \ | | | 580 +-----------B2---B4----------+ 581 | | 582 | Group B | 583 | 192.0.2.1/32 | 584 | SID:200 | 585 +--------------+ 587 Figure 1: Transit device groups 589 The figure above describes a network example with two groups of 590 transit devices. Group A consists of devices {A1, A2, A3 and A4}. 591 They are all provisioned with the anycast address 192.0.2.10/32 and 592 the anycast SID 100. 594 Similarly, group B consists of devices {B1, B2, B3 and B4} and are 595 all provisioned with the anycast address 192.0.2.1/32, anycast SID 596 200. In the above network topology, each PE device has a path to 597 each of the groups A and B. 599 PE1 can choose a particular transit device group when sending traffic 600 to PE3 or PE4. This will be done by pushing the anycast SID of the 601 group in the stack. 603 Processing the anycast, and subsequent segments, requires special 604 care. 606 +-------------------------+ 607 | Group A | 608 | 192.0.2.10/32 | 609 | SID:100 | 610 |-------------------------| 611 | | 612 | SRGB: SRGB: | 613 SID:10 |(1000-2000) (3000-4000)| SID:30 614 PE1---+ +-------A1-------------A3-------+ +---PE3 615 \ / | | \ / | | \ / 616 \ / | | +-----+ / | | \ / 617 SRGB: \ / | | \ / | | \ / SRGB: 618 (7000-8000) R1 | | \ | | R3 (6000-7000) 619 / \ | | / \ | | / \ 620 / \ | | +-----+ \ | | / \ 621 / \ | | / \ | | / \ 622 PE2---+ +-------A2-------------A4-------+ +---PE4 623 SID:20 | SRGB: SRGB: | SID:40 624 |(2000-3000) (4000-5000)| 625 | | 626 +-------------------------+ 628 Figure 2: Transit paths via anycast group A 630 Considering an MPLS deployment, in the above topology, if device PE1 631 (or PE2) requires to send a packet to the device PE3 (or PE4) it 632 needs to encapsulate the packet in an MPLS payload with the following 633 stack of labels. 635 o Label allocated by R1 for anycast SID 100 (outer label). 637 o Label allocated by the nearest router in group A for SID 30 (for 638 destination PE3). 640 While the first label is easy to compute, in this case since there 641 are more than one topologically nearest devices (A1 and A2), unless 642 A1 and A2 allocated the same label value to the same prefix, 643 determining the second label is impossible. Devices A1 and A2 may be 644 devices from different hardware vendors. If both don't allocate the 645 same label value for SID 30, it is impossible to use the anycast 646 group "A" as a transit anycast group towards PE3. Hence, PE1 (or 647 PE2) cannot compute an appropriate label stack to steer the packet 648 exclusively through the group A devices. Same holds true for devices 649 PE3 and PE4 when trying to send a packet to PE1 or PE2. 651 To ease the use of anycast segment, it is recommended to configure 652 identical SRGBs on all nodes of a particular anycast group. Using 653 this method, as mentioned above, computation of the label following 654 the anycast segment is straightforward. 656 Using anycast segment without configuring identical SRGBs on all 657 nodes belonging to the same device group may lead to misrouting (in 658 an MPLS VPN deployment, some traffic may leak between VPNs). 660 3.4. IGP-Adjacency Segment, Adj-SID 662 The adjacency is formed by the local node (i.e., the node advertising 663 the adjacency in the IGP) and the remote node (i.e., the other end of 664 the adjacency). The local node MUST be an IGP node. The remote node 665 may be an adjacent IGP neighbor or a non-adjacent neighbor (e.g., a 666 Forwarding Adjacency, [RFC4206]). 668 A packet injected anywhere within the SR domain with a segment list 669 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 670 attached by node N to its adjacency over link L, will be forwarded 671 along the shortest-path to N and then be switched by N, without any 672 IP shortest-path consideration, towards link L. If the Adj-SID 673 identifies a set of adjacencies, then the node N load-balances the 674 traffic among the various members of the set. 676 Similarly, when using a global Adj-SID, a packet injected anywhere 677 within the SR domain with a segment list {SNL}, where SNL is a global 678 Adj-SID attached by node N to its adjacency over link L, will be 679 forwarded along the shortest-path to N and then be switched by N, 680 without any IP shortest-path consideration, towards link L. If the 681 Adj-SID identifies a set of adjacencies, then the node N does load- 682 balance the traffic among the various members of the set. The use of 683 global Adj-SID allows to reduce the size of the segment list when 684 expressing a path at the cost of additional state (i.e.: the global 685 Adj-SID will be inserted by all routers within the area in their 686 forwarding table). 688 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 689 packet from a node towards a defined interface or set of interfaces. 690 This is key to theoretically prove that any path can be expressed as 691 a list of segments. 693 The encodings of the Adj-SID include a set of flags supporting the 694 following functionalities: 696 o Eligible for Protection (e.g., using IPFRR or MPLS-FRR). 697 Protection allows that in the event the interface(s) associated 698 with the Adj-SID are down, that the packet can still be forwarded 699 via an alternate path. The use of protection is clearly a policy 700 based decision i.e., for a given policy protection may or may not 701 be desirable. 703 o Indication whether the Adj-SID has local or global scope. Default 704 scope SHOULD be Local. 706 o Indication whether the Adj-SID is persistent across control plane 707 restarts. Persistence is a key attribute in ensuring that an SR 708 Policy does not temporarily result in misforwarding due to 709 reassignment of an Adj-SID. 711 A weight (as described below) is also associated with the Adj-SID 712 advertisement. 714 A node SHOULD allocate one Adj-SID for each of its adjacencies. 716 A node MAY allocate multiple Adj-SIDs for the same adjacency. An 717 example is to support an Adj-SID which is eligible for protection and 718 an Adj-SID which is NOT eligible for protection. 720 A node MAY associate the same Adj-SID to multiple adjacencies. 722 In order to be able to advertise in the IGP all the Adj-SIDs 723 representing the IGP adjacencies between two nodes, parallel 724 adjacency suppression MUST NOT be performed by the IGP. 726 When a node binds an Adj-SID to a local data-link L, the node MUST 727 install the following FIB entry: 729 Incoming Active Segment: V 730 Ingress Operation: NEXT 731 Egress Interface: L 733 The Adj-SID implies, from the router advertising it, the forwarding 734 of the packet through the adjacency(ies) identified by the Adj-SID, 735 regardless of its IGP/SPF cost. In other words, the use of adjacency 736 segments overrides the routing decision made by the SPF algorithm. 738 3.4.1. Parallel Adjacencies 740 Adj-SIDs can be used in order to represent a set of parallel 741 interfaces between two adjacent routers. 743 A node MUST install a FIB entry for any locally originated adjacency 744 segment (Adj-SID) of value W attached to a set of links B with: 746 Incoming Active Segment: W 747 Ingress Operation: NEXT 748 Egress interface: load-balance between any data-link within set B 750 When parallel adjacencies are used and associated to the same Adj- 751 SID, and in order to optimize the load balancing function, a "weight" 752 factor can be associated to the Adj-SID advertised with each 753 adjacency. The weight tells the ingress (or an SDN/orchestration 754 system) about the load-balancing factor over the parallel 755 adjacencies. As shown in Figure 3, A and B are connected through two 756 parallel adjacencies 758 link-1 759 +--------+ 760 | | 761 S---A B---C 762 | | 763 +--------+ 764 link-2 766 Figure 3: Parallel Links and Adj-SIDs 768 Node A advertises following Adj-SIDs and weights: 770 o Link-1: Adj-SID 1000, weight: 1 772 o Link-2: Adj-SID 1000, weight: 2 774 Node S receives the advertisements of the parallel adjacencies and 775 understands that by using Adj-SID 1000 node A will load-balance the 776 traffic across the parallel links (link-1 and link-2) according to a 777 1:2 ratio i.e., twice as many packets will flow over Link-2 as 778 compared to Link-1. 780 3.4.2. LAN Adjacency Segments 782 In LAN subnetworks, link-state protocols define the concept of 783 Designated Router (DR, in OSPF) or Designated Intermediate System 784 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 785 that describe the LAN topology in a special routing update (OSPF 786 Type2 LSA or IS-IS Pseudonode LSP). 788 The difficulty with LANs is that each router only advertises its 789 connectivity to the DR/DIS and not to each of the individual nodes in 790 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 791 are necessary in order for each router in the LAN to advertise an 792 Adj-SID associated to each neighbor in the LAN. 794 3.5. Inter-Area Considerations 796 In the following example diagram it is assumed that the all areas are 797 part of a single SR Domain. 799 The example here below assumes the IPv6 control plane with the MPLS 800 dataplane. 802 ! ! 803 ! ! 804 B------C-----F----G-----K 805 / | | | 806 S---A/ | | | 807 \ | | | 808 \D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150) 809 ! ! 810 Area-1 ! Backbone ! Area 2 811 ! area ! 813 Figure 4: Inter-Area Topology Example 815 In area 2, node Z allocates Node-SID 150 to his local IPv6 prefix 816 2001:DB8::2:1/128. 818 Area Border Routers (ABR) G and J will propagate the prefix and its 819 SIDs into the backbone area by creating a new instance of the prefix 820 according to normal inter-area/level IGP propagation rules. 822 Nodes C and I will apply the same behavior when leaking prefixes from 823 the backbone area down to area 1. Therefore, node S will see prefix 824 2001:DB8::2:1/128 with Prefix-SID 150 and advertised by nodes C and 825 I. 827 It therefore results that a Prefix-SID remains attached to its 828 related IGP Prefix through the inter-area process, which is the 829 expected behavior in a single SR Domain. 831 When node S sends traffic to 2001:DB8::2:1/128, it pushes Node- 832 SID(150) as active segment and forward it to A. 834 When packet arrives at ABR I (or C), the ABR forwards the packet 835 according to the active segment (Node-SID(150)). Forwarding 836 continues across area borders, using the same Node-SID(150), until 837 the packet reaches its destination. 839 4. BGP Peering Segments 841 BGP segments may be allocated and distributed by BGP. 843 4.1. BGP Prefix Segment 845 A BGP-Prefix segment is a BGP segment attached to a BGP prefix. 847 A BGP-Prefix segment is global (unless explicitly advertised 848 otherwise) within the SR domain. 850 The BGP Prefix SID is the BGP equivalent to the IGP Prefix Segment. 852 A likely use-case for the BGP Prefix Segment is an IGP-free hyper- 853 scale spine-leaf topology where connectivity is learned solely via 854 BGP [RFC7938] 856 4.2. BGP Peering Segments 858 In the context of BGP Egress Peer Engineering (EPE), as described in 859 [I-D.ietf-spring-segment-routing-central-epe], an EPE enabled Egress 860 PE node MAY advertise segments corresponding to its attached peers. 861 These segments are called BGP peering segments or BGP peering SIDs. 862 They enable the expression of source-routed inter-domain paths. 864 An ingress border router of an AS may compose a list of segments to 865 steer a flow along a selected path within the AS, towards a selected 866 egress border router C of the AS and through a specific peer. At 867 minimum, a BGP peering Engineering policy applied at an ingress PE 868 involves two segments: the Node SID of the chosen egress PE and then 869 the BGP peering segment for the chosen egress PE peer or peering 870 interface. 872 Three types of BGP peering segments/SIDs are defined: PeerNode SID, 873 PeerAdj SID and PeerSet SID. 875 o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At 876 the BGP node advertising it, its semantics is: 878 * SR header operation: NEXT. 880 * Next-Hop: the connected peering node to which the segment is 881 related. 883 o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the 884 BGP node advertising it, the semantic is: 886 * SR header operation: NEXT. 888 * Next-Hop: the peer connected through the interface to which the 889 segment is related. 891 o PeerSet SID. a BGP PeerSet segment/SID is a local segment. At the 892 BGP node advertising it, the semantic is: 894 * SR header operation: NEXT. 896 * Next-Hop: load-balance across any connected interface to any 897 peer in the related group. 899 A peer set could be all the connected peers from the same AS or a 900 subset of these. A group could also span across AS. The group 901 definition is a policy set by the operator. 903 The BGP extensions necessary in order to signal these BGP peering 904 segments are defined in [I-D.ietf-idr-bgpls-segment-routing-epe] 906 5. Binding Segment 908 In order to provide greater scalability, network opacity, and service 909 independence, SR utilizes a Binding SID (BSID). The BSID is bound to 910 an SR policy, instantiation of which may involve a list of SIDs. Any 911 packets received with active segment = BSID are steered onto the 912 bound SR Policy. 914 A BSID may either be a local or a global SID. If local, a BSID 915 SHOULD be allocated from the SRLB. If global, a BSID MUST be 916 allocated from the SRGB. 918 Use of a BSID allows the instantiation of the policy (the SID list) 919 to be stored only on the node(s) which need to impose the policy. 920 Direction of traffic to a node supporting the policy then only 921 requires imposition of the BSID. If the policy changes, this also 922 means that only the nodes imposing the policy need to be updated. 923 Users of the policy are not impacted. 925 5.1. IGP Mirroring Context Segment 927 One use case for a Binding Segment is to provide support for an IGP 928 node to advertise its ability to process traffic originally destined 929 to another IGP node, called the Mirrored node and identified by an IP 930 address or a Node-SID, provided that a "Mirroring Context" segment be 931 inserted in the segment list prior to any service segment local to 932 the mirrored node. 934 When a given node B wants to provide egress node A protection, it 935 advertises a segment identifying node's A context. Such segment is 936 called "Mirror Context Segment" and identified by the Mirror SID. 938 The Mirror SID is advertised using the binding segment defined in SR 939 IGP protocol extensions [I-D.ietf-isis-segment-routing-extensions] . 941 In the event of a failure, a point of local repair (PLR) diverting 942 traffic from A to B does a PUSH of the Mirror SID on the protected 943 traffic. B, when receiving the traffic with the Mirror SID as the 944 active segment, uses that segment and processes underlying segments 945 in the context of A. 947 6. Multicast 949 Segment Routing is defined for unicast. The application of the 950 source-route concept to Multicast is not in the scope of this 951 document. 953 7. IANA Considerations 955 This document does not require any action from IANA. 957 8. Security Considerations 959 Segment Routing is applicable to both MPLS and IPv6 data planes. 961 Segment Routing adds some meta-data (instructions) to the packet, 962 with the list of forwarding path elements (e.g., nodes, links, 963 services, etc.) that the packet must traverse. It has to be noted 964 that the complete source routed path may be represented by a single 965 segment. This is the case of the Binding SID. 967 SR by default operates within a trusted domain. Traffic MUST be 968 filtered at the domain boundaries. 970 The use of best practices to reduce the risk of tampering within the 971 trusted domain is important. Such practices are discussed in 972 [RFC4381] and are applicable to both SR-MPLS and SRv6. 974 8.1. SR-MPLS 976 When applied to the MPLS data plane, Segment Routing does not 977 introduce any new behavior or any change in the way MPLS data plane 978 works. Therefore, from a security standpoint, this document does not 979 define any additional mechanism in the MPLS data plane. 981 SR allows the expression of a source routed path using a single 982 segment (the Binding SID). Compared to RSVP-TE which also provides 983 explicit routing capability, there are no fundamental differences in 984 term of information provided. Both RSVP-TE and Segment Routing may 985 express a source routed path using a single segment. 987 When a path is expressed using a single label, the syntax of the 988 meta-data is equivalent between RSVP-TE [RFC3209] and SR. 990 When a source routed path is expressed with a list of segments 991 additional meta-data is added to the packet consisting of the source 992 routed path the packet must follow expressed as a segment list. 994 When a path is expressed using a label stack, if one has access to 995 the meaning (i.e.: the Forwarding Equivalence Class) of the labels, 996 one has the knowledge of the explicit path. For the MPLS data plane, 997 as no data plane modification is required, there is no fundamental 998 change of capability. Yet, the occurrence of label stacking will 999 increase. 1001 SR domain boundary routers MUST filter any external traffic destined 1002 to a label associated with a segment within the trusted domain. This 1003 includes labels within the SRGB of the trusted domain, labels within 1004 the SRLB of the specific boundary router, and labels outside either 1005 of these blocks. External traffic is any traffic received from an 1006 interface connected to a node outside the domain of trust. 1008 From a network protection standpoint, there is an assumed trust model 1009 such that any node imposing a label stack on a packet is assumed to 1010 be allowed to do so. This is a significant change compared to plain 1011 IP offering shortest path routing but not fundamentally different 1012 compared to existing techniques providing explicit routing capability 1013 such as RSVP-TE. By default, the explicit routing information MUST 1014 NOT be leaked through the boundaries of the administered domain. 1015 Segment Routing extensions that have been defined in various 1016 protocols, leverage the security mechanisms of these protocols such 1017 as encryption, authentication, filtering, etc. 1019 In the general case, a segment routing capable router accepts and 1020 install labels only if these labels have been previously advertised 1021 by a trusted source. The received information is validated using 1022 existing control plane protocols providing authentication and 1023 security mechanisms. Segment Routing does not define any additional 1024 security mechanism in existing control plane protocols. 1026 Segment Routing does not introduce signaling between the source and 1027 the mid points of a source routed path. With SR, the source routed 1028 path is computed using SIDs previously advertised in the IP control 1029 plane. Therefore, in addition to filtering and controlled 1030 advertisement of SIDs at the boundaries of the SR domain, filtering 1031 in the data plane is also required. Filtering MUST be performed on 1032 the forwarding plane at the boundaries of the SR domain and may 1033 require looking at multiple labels/instruction. 1035 For the MPLS data plane, there are no new requirements as the 1036 existing MPLS architecture already allows such source routing by 1037 stacking multiple labels. And for security protection, [RFC4381] and 1038 [RFC5920] already call for the filtering of MPLS packets on trust 1039 boundaries. 1041 8.2. SRv6 1043 When applied to the IPv6 data plane, Segment Routing does introduce 1044 the Segment Routing Header (SRH, 1045 [I-D.ietf-6man-segment-routing-header]) which is a type of Routing 1046 Extension header as defined in [RFC8200]. 1048 The SRH adds some meta-data to the IPv6 packet, with the list of 1049 forwarding path elements (e.g., nodes, links, services, etc.) that 1050 the packet must traverse and that are represented by IPv6 addresses. 1051 A complete source routed path may be encoded in the packet using a 1052 single segment (single IPv6 address). 1054 SR domain boundary routers MUST filter any external traffic destined 1055 to an address within the SRGB of the trusted domain or the SRLB of 1056 the specific boundary router. External traffic is any traffic 1057 received from an interface connected to a node outside the domain of 1058 trust. 1060 From a network protection standpoint, there is an assumed trust model 1061 such that any node adding an SRH to the packet is assumed to be 1062 allowed to do so. Therefore, by default, the explicit routing 1063 information MUST NOT be leaked through the boundaries of the 1064 administered domain. Segment Routing extensions that have been 1065 defined in various protocols, leverage the security mechanisms of 1066 these protocols such as encryption, authentication, filtering, etc. 1068 In the general case, an SR IPv6 router accepts and install segments 1069 identifiers (in the form of IPv6 addresses), only if these SIDs are 1070 advertised by a trusted source. The received information is 1071 validated using existing control plane protocols providing 1072 authentication and security mechanisms. Segment Routing does not 1073 define any additional security mechanism in existing control plane 1074 protocols. 1076 Problems which may arise when the above behaviors are not implemented 1077 or when the assumed trust model is violated (e.g., through a security 1078 breach) include: 1080 o Malicious looping 1082 o Evasion of access controls 1084 o Hiding the source of DOS attacks 1086 Security concerns with source routing at the IPv6 data plane are more 1087 completely discussed in [RFC5095]. The new IPv6-based segment 1088 routing header is defined in [I-D.ietf-6man-segment-routing-header]. 1089 This document also discusses the above security concerns. 1091 8.3. Congestion Control 1093 SR does not introduce new requirements for congestion control. By 1094 default, traffic delivery is assumed to be best effort. Congestion 1095 control may be implemented at endpoints. Where SR policies are in 1096 use bandwidth allocation may be managed by monitoring incoming 1097 traffic associated with the binding SID identifying the SR policy. 1098 Other solutions such as [RFC8084] may be applicable. 1100 9. Manageability Considerations 1102 In SR enabled networks, the path the packet takes is encoded in the 1103 header. As the path is not signaled through a protocol, OAM 1104 mechanisms are necessary in order for the network operator to 1105 validate the effectiveness of a path as well as to check and monitor 1106 its liveness and performance. However, it has to be noted that SR 1107 allows to reduce substantially the number of states in transit nodes 1108 and hence the number of elements that a transit node has to manage is 1109 smaller. 1111 SR OAM use cases for the MPLS data plane are defined in 1112 [I-D.ietf-spring-oam-usecase]. SR OAM procedures for the MPLS data 1113 plane are defined in [RFC8287]. 1115 SR routers receive advertisements of SIDs (index, label or IPv6 1116 address) from the different routing protocols being extended for SR. 1117 Each of these protocols have monitoring and troubleshooting 1118 mechanisms to provide operation and management functions for IP 1119 addresses that must be extended in order to include troubleshooting 1120 and monitoring functions of the SID. 1122 SR architecture introduces the usage of global segments. Each global 1123 segment MUST be bound to a unique index or address within an SR 1124 domain. The management of the allocation of such index or address by 1125 the operator is critical for the network behavior to avoid situations 1126 like mis-routing. In addition to the allocation policy/tooling that 1127 the operator will have in place, an implementation SHOULD protect the 1128 network in case of conflict detection by providing a deterministic 1129 resolution approach. 1131 When a path is expressed using a label stack, the occurrence of label 1132 stacking will increase. A node may want to signal in the control 1133 plane its ability in terms of size of the label stack it can support. 1135 A YANG data model [RFC6020] for segment routing configuration and 1136 operations has been defined in [I-D.ietf-spring-sr-yang]. 1138 When Segment Routing is applied to the IPv6 data plane, segments are 1139 identified through IPv6 addresses. The allocation, management and 1140 troubleshooting of segment identifiers is no different than the 1141 existing mechanisms applied to the allocation and management of IPv6 1142 addresses. 1144 The DA of the packet gives the active segment address. The segment 1145 list in the SRH gives the entire path of the packet. The validation 1146 of the source routed path is done through inspection of DA and SRH 1147 present in the packet header matched to the equivalent routing table 1148 entries. 1150 In the context of SR over the IPv6 data plane, the source routed path 1151 is encoded in the SRH as described in 1152 [I-D.ietf-6man-segment-routing-header]. The SR IPv6 source routed 1153 path is instantiated into the SRH as a list of IPv6 address where the 1154 active segment is in the Destination Address (DA) field of the IPv6 1155 packet header. Typically, by inspecting in any node the packet 1156 header, it is possible to derive the source routed path it belongs 1157 to. Similar to the context of SR over MPLS data plane, an 1158 implementation may originate path control and monitoring packets 1159 where the source routed path is inserted in the SRH and where each 1160 segment of the path inserts in the packet the relevant data in order 1161 to measure the end to end path and performance. 1163 10. Contributors 1165 The following people have substantially contributed to the definition 1166 of the Segment Routing architecture and to the editing of this 1167 document: 1169 Ahmed Bashandy 1170 Cisco Systems, Inc. 1171 Email: bashandy@cisco.com 1172 Martin Horneffer 1173 Deutsche Telekom 1174 Email: Martin.Horneffer@telekom.de 1176 Wim Henderickx 1177 Nokia 1178 Email: wim.henderickx@nokia.com 1180 Jeff Tantsura 1181 Email: jefftant@gmail.com 1183 Edward Crabbe 1184 Email: edward.crabbe@gmail.com 1186 Igor Milojevic 1187 Email: milojevicigor@gmail.com 1189 Saku Ytti 1190 TDC 1191 Email: saku@ytti.fi 1193 11. Acknowledgements 1195 We would like to thank Dave Ward, Peter Psenak, Dan Frost, Stewart 1196 Bryant, Pierre Francois, Thomas Telkamp, Ruediger Geib, Hannes 1197 Gredler, Pushpasis Sarkar, Eric Rosen, Chris Bowers and Alvaro Retana 1198 for their comments and review of this document. 1200 12. References 1202 12.1. Normative References 1204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1205 Requirement Levels", BCP 14, RFC 2119, 1206 DOI 10.17487/RFC2119, March 1997, 1207 . 1209 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1210 Label Switching Architecture", RFC 3031, 1211 DOI 10.17487/RFC3031, January 2001, 1212 . 1214 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1215 (IPv6) Specification", STD 86, RFC 8200, 1216 DOI 10.17487/RFC8200, July 2017, 1217 . 1219 12.2. Informative References 1221 [I-D.ietf-6man-segment-routing-header] 1222 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 1223 Field, B., daniel.voyer@bell.ca, d., 1224 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 1225 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 1226 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 1227 Header (SRH)", draft-ietf-6man-segment-routing-header-08 1228 (work in progress), January 2018. 1230 [I-D.ietf-idr-bgpls-segment-routing-epe] 1231 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 1232 Dong, "BGP-LS extensions for Segment Routing BGP Egress 1233 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 1234 epe-14 (work in progress), December 2017. 1236 [I-D.ietf-isis-segment-routing-extensions] 1237 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1238 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 1239 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1240 segment-routing-extensions-15 (work in progress), December 1241 2017. 1243 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1244 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1245 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1246 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1247 segment-routing-extensions-10 (work in progress), 1248 September 2017. 1250 [I-D.ietf-ospf-segment-routing-extensions] 1251 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1252 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1253 Extensions for Segment Routing", draft-ietf-ospf-segment- 1254 routing-extensions-24 (work in progress), December 2017. 1256 [I-D.ietf-pce-segment-routing] 1257 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1258 and J. Hardwick, "PCEP Extensions for Segment Routing", 1259 draft-ietf-pce-segment-routing-11 (work in progress), 1260 November 2017. 1262 [I-D.ietf-spring-oam-usecase] 1263 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A 1264 Scalable and Topology-Aware MPLS Dataplane Monitoring 1265 System", draft-ietf-spring-oam-usecase-10 (work in 1266 progress), December 2017. 1268 [I-D.ietf-spring-resiliency-use-cases] 1269 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 1270 "Resiliency use cases in SPRING networks", draft-ietf- 1271 spring-resiliency-use-cases-12 (work in progress), 1272 December 2017. 1274 [I-D.ietf-spring-segment-routing-central-epe] 1275 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1276 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1277 Engineering", draft-ietf-spring-segment-routing-central- 1278 epe-10 (work in progress), December 2017. 1280 [I-D.ietf-spring-segment-routing-mpls] 1281 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1282 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1283 data plane", draft-ietf-spring-segment-routing-mpls-11 1284 (work in progress), October 2017. 1286 [I-D.ietf-spring-sr-yang] 1287 Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG 1288 Data Model for Segment Routing", draft-ietf-spring-sr- 1289 yang-08 (work in progress), December 2017. 1291 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1292 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1293 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1294 . 1296 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1297 Hierarchy with Generalized Multi-Protocol Label Switching 1298 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1299 DOI 10.17487/RFC4206, October 2005, 1300 . 1302 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1303 Virtual Private Networks (VPNs)", RFC 4381, 1304 DOI 10.17487/RFC4381, February 2006, 1305 . 1307 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1308 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1309 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1310 . 1312 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1313 of Type 0 Routing Headers in IPv6", RFC 5095, 1314 DOI 10.17487/RFC5095, December 2007, 1315 . 1317 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1318 Topology (MT) Routing in Intermediate System to 1319 Intermediate Systems (IS-ISs)", RFC 5120, 1320 DOI 10.17487/RFC5120, February 2008, 1321 . 1323 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1324 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1325 DOI 10.17487/RFC5440, March 2009, 1326 . 1328 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1329 RFC 5714, DOI 10.17487/RFC5714, January 2010, 1330 . 1332 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1333 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1334 . 1336 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1337 the Network Configuration Protocol (NETCONF)", RFC 6020, 1338 DOI 10.17487/RFC6020, October 2010, 1339 . 1341 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1342 and A. Bierman, Ed., "Network Configuration Protocol 1343 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1344 . 1346 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1347 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1348 March 2012, . 1350 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 1351 BGP for Routing in Large-Scale Data Centers", RFC 7938, 1352 DOI 10.17487/RFC7938, August 2016, 1353 . 1355 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 1356 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 1357 . 1359 [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS 1360 Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 1361 2017, . 1363 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 1364 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 1365 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 1366 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 1367 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 1368 . 1370 Authors' Addresses 1372 Clarence Filsfils (editor) 1373 Cisco Systems, Inc. 1374 Brussels 1375 BE 1377 Email: cfilsfil@cisco.com 1379 Stefano Previdi (editor) 1380 Cisco Systems, Inc. 1381 Italy 1383 Email: stefano@previdi.net 1385 Les Ginsberg 1386 Cisco Systems, Inc 1388 Email: ginsberg@cisco.com 1390 Bruno Decraene 1391 Orange 1392 FR 1394 Email: bruno.decraene@orange.com 1396 Stephane Litkowski 1397 Orange 1398 FR 1400 Email: stephane.litkowski@orange.com 1401 Rob Shakir 1402 Google, Inc. 1403 1600 Amphitheatre Parkway 1404 Mountain View, CA 94043 1405 US 1407 Email: robjs@google.com