idnits 2.17.1 draft-ietf-spring-segment-routing-14.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 (December 20, 2017) is 2319 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-6man-segment-routing-header-07 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-14 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-15 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-10 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-24 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-11 == Outdated reference: A later version (-30) exists of draft-ietf-spring-sr-yang-07 Summary: 0 errors (**), 0 flaws (~~), 10 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: June 23, 2018 L. Ginsberg 6 Cisco Systems, Inc 7 B. Decraene 8 S. Litkowski 9 Orange 10 R. Shakir 11 Google, Inc. 12 December 20, 2017 14 Segment Routing Architecture 15 draft-ietf-spring-segment-routing-14 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 June 23, 2018. 63 Copyright Notice 65 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . 8 85 3.1.2. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 26 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 2. Terminology 216 SR-MPLS: the instantiation of SR on the MPLS dataplane 218 SRv6: the instantiation of SR on the IPv6 dataplane. 220 Segment: an instruction a node executes on the incoming packet (e.g., 221 forward packet according to shortest path to destination, or, forward 222 packet through a specific interface, or, deliver the packet to a 223 given application/service instance). 225 SID: a segment identifier. Note that the term SID is commonly used 226 in place of the term Segment, though this is technically imprecise as 227 it overlooks any necessary translation. 229 SR-MPLS SID: an MPLS label or an index value into an MPLS label space 230 explicitly associated with the segment. 232 SRv6 SID: an IPv6 address explicitly associated with the segment. 234 Segment Routing Domain (SR Domain): the set of nodes participating in 235 the source based routing model. These nodes may be connected to the 236 same physical infrastructure (e.g., a Service Provider's network). 237 They may as well be remotely connected to each other (e.g., an 238 enterprise VPN or an overlay). If multiple protocol instances are 239 deployed, the SR domain most commonly includes all of the protocol 240 instances in a network. However, some deployments may wish to sub- 241 divide the network into multiple SR domains, each of which includes 242 one or more protocol instances. It is expected that all nodes in an 243 SR Domain are managed by the same administrative entity. 245 Active Segment: the segment that is used by the receiving router to 246 process the packet. In the MPLS dataplane it is the top label. In 247 the IPv6 dataplane it is the destination address. 248 [I-D.ietf-6man-segment-routing-header]. 250 PUSH: the instruction consisting of the insertion of a segment at the 251 top of the segment list. In SR-MPLS the top of the segment list is 252 the topmost (outer) label of the label stack. In SRv6, the top of 253 the segment list is represented by the first segment in the Segment 254 Routing Header as defined in [I-D.ietf-6man-segment-routing-header]. 256 NEXT: when the active segment is completed, NEXT is the instruction 257 consisting of the inspection of the next segment. The next segment 258 becomes active. In SR-MPLS, NEXT is implemented as a POP of the top 259 label. In SRv6, NEXT is implemented as the copy of the next segment 260 from the SRH to the Destination Address of the IPv6 header. 262 CONTINUE: the active segment is not completed and hence remains 263 active. In SR-MPLS, CONTINUE instruction is implemented as a SWAP of 264 the top label. [RFC3031] In SRv6, this is the plain IPv6 forwarding 265 action of a regular IPv6 packet according to its Destination Address. 267 SR Global Block (SRGB): the set of global segments in the SR Domain. 268 If a node participates in multiple SR domains, there is one SRGB for 269 each SR domain. In SR-MPLS, SRGB is a local property of a node and 270 identifies the set of local labels reserved for global segments. In 271 SR-MPLS, using identical SRGBs on all nodes within the SR Domain is 272 strongly recommended. Doing so eases operations and troubleshooting 273 as the same label represents the same global segment at each node. 274 In SRv6, the SRGB is the set of global SRv6 SIDs in the SR Domain. 276 SR Local Block (SRLB): local property of an SR node. If a node 277 participates in multiple SR domains, there is one SRLB for each SR 278 domain. In SR-MPLS, SRLB is a set of local labels reserved for local 279 segments. In SRv6, SRLB is a set of local IPv6 addresses reserved 280 for local SRv6 SID's. In a controller-driven network, some 281 controllers or applications may use the control plane to discover the 282 available set of local segments. 284 Global Segment: a segment which is part of the SRGB of the domain. 285 The instruction associated to the segment is defined at the SR Domain 286 level. A topological shortest-path segment to a given destination 287 within an SR domain is a typical example of a global segment. 289 Local Segment: In SR-MPLS, this is a local label outside the SRGB. 290 It may be part of the explicitly advertised SRLB. In SRv6, this can 291 be any IPv6 address i.e., the address may be part of the SRGB but 292 used such that it has local significance. The instruction associated 293 to the segment is defined at the node level. 295 IGP Segment: the generic name for a segment attached to a piece of 296 information advertised by a link-state IGP, e.g. an IGP prefix or an 297 IGP adjacency. 299 IGP-Prefix Segment: an IGP-Prefix Segment is an IGP Segment 300 representing an IGP prefix. When an IGP-Prefix Segment is global 301 within the SR IGP instance/topology it identifies an instruction to 302 forward the packet along the path computed using the routing 303 algorithm specified in the algorithm field, in the topology and the 304 IGP instance where it is advertised. Also referred to as Prefix 305 Segment. 307 Prefix SID: the SID of the IGP-Prefix Segment. 309 IGP-Anycast Segment: an IGP-Anycast Segment is an IGP-Prefix Segment 310 which identify an anycast prefix advertised by a set of routers. 312 Anycast-SID: the SID of the IGP-Anycast Segment. 314 IGP-Adjacency Segment: an IGP-Adjacency Segment is an IGP Segment 315 attached to a unidirectional adjacency or a set of unidirectional 316 adjacencies. By default, an IGP-Adjacency Segment is local (unless 317 explicitly advertised otherwise) to the node that advertises it. 318 Also referred to as Adjacency Segment. 320 Adj-SID: the SID of the IGP-Adjacency Segment. 322 IGP-Node Segment: an IGP-Node Segment is an IGP-Prefix Segment which 323 identifies a specific router (e.g., a loopback). Also referred to as 324 Node Segment. 326 Node-SID: the SID of the IGP-Node Segment. 328 SR Policy: an ordered list of segments. The headend of an SR Policy 329 steers packets onto the SR policy. The list of segments can be 330 specified explicitly in SR-MPLS as a stack of labels and in SRv6 as 331 an ordered list of SRv6 SID's. Alternatively, the list of segments 332 is computed based on a destination and a set of optimization 333 objective and constraints (e.g., latency, affinity, SRLG, ...). The 334 computation can be local or delegated to a PCE server. An SR policy 335 can be configured by the operator, provisioned via NETCONF [RFC6241] 336 or provisioned via PCEP [RFC5440] . An SR policy can be used for 337 traffic-engineering, OAM or FRR reasons. 339 Segment List Depth: the number of segments of an SR policy. The 340 entity instantiating an SR Policy at a node N should be able to 341 discover the depth insertion capability of the node N. For example, 342 the PCEP SR capability advertisement described in 343 [I-D.ietf-pce-segment-routing] is one means of discovering this 344 capability. 346 Forwarding Information Base (FIB): the forwarding table of a node 348 3. Link-State IGP Segments 350 Within an SR domain, an SR-capable IGP node advertises segments for 351 its attached prefixes and adjacencies. These segments are called IGP 352 segments or IGP SIDs. They play a key role in Segment Routing and 353 use-cases as they enable the expression of any path throughout the SR 354 domain. Such a path is either expressed as a single IGP segment or a 355 list of multiple IGP segments. 357 Advertisement of IGP segments requires extensions in link-state IGP 358 protocols. These extensions are defined in 359 [I-D.ietf-isis-segment-routing-extensions] 360 [I-D.ietf-ospf-segment-routing-extensions] 361 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 363 3.1. IGP-Prefix Segment, Prefix-SID 365 An IGP-Prefix segment is an IGP segment attached to an IGP prefix. 366 An IGP-Prefix segment is global (unless explicitly advertised 367 otherwise) within the SR domain. The context for an IGP-Prefix 368 segment includes the prefix, topology, and algorithm. Multiple SIDs 369 MAY be allocated to the same prefix so long as the tuple is unique. 372 Multiple instances and topologies are defined in IS-IS and OSPF in: 373 [RFC5120], [RFC8202], [RFC6549] and [RFC4915]. 375 3.1.1. Prefix-SID Algorithm 377 Segment Routing supports the use of multiple routing algorithms i.e, 378 different constraint based shortest path calculations can be 379 supported. An algorithm identifier is included as part of a Prefix- 380 SID advertisement. 382 This document defines two algorithms: 384 o "Shortest Path": this algorithm is the default behavior. The 385 packet is forwarded along the well known ECMP-aware SPF algorithm 386 employed by the IGPs. However it is explicitly allowed for a 387 midpoint to implement another forwarding based on local policy. 388 The "Shortest Path" algorithm is in fact the default and current 389 behavior of most of the networks where local policies may override 390 the SPF decision. 392 o "Strict Shortest Path": This algorithm mandates that the packet is 393 forwarded according to ECMP-aware SPF algorithm and instructs any 394 router in the path to ignore any possible local policy overriding 395 the SPF decision. The SID advertised with "Strict Shortest Path" 396 algorithm ensures that the path the packet is going to take is the 397 expected, and not altered, SPF path. Note that Fast Reroute (FRR) 398 [RFC5714] mechanisms are still compliant with the Strict Shortest 399 Path. In other words, a packet received with a Strict-SPF SID may 400 be rerouted through a FRR mechanism. 402 An IGP-Prefix Segment identifies the path, to the related prefix, 403 computed as per the associated algorithm. A packet injected anywhere 404 within the SR domain with an active Prefix-SID is expected to be 405 forwarded along a path computed using the specified algorithm. 406 Clearly, if not all SR capable nodes in an SR Domain support a given 407 algorithm it is not possible to guarantee that the packet will follow 408 a path consistent with the associated algorithm. 410 A router MUST drop any SR traffic associated with an SR algorithm, if 411 the nexthop router has not advertised support for the SR algorithm. 413 The ingress node of an SR domain SHOULD validate that the path to a 414 prefix, advertised with a given algorithm, includes nodes all 415 supporting the advertised algorithm. If this constraint cannot be 416 met the packet SHOULD be dropped by the ingress node. Note that in 417 the special case of "Shortest Path", all nodes (SR Capable or not) 418 are assumed to support this algorithm. 420 3.1.2. SR-MPLS 422 When SR is used over the MPLS dataplane SIDs are an MPLS label or an 423 index into an MPLS label space (either SRGB or SRLB). 425 Where possible, it is recommended that identical SRGBs be configured 426 on all nodes in an SR Domain. This simplifies troubleshooting as the 427 same label will be associated with the same prefix on all nodes. In 428 addition, it simplifies support for anycast as detailed in 429 Section 3.3. 431 The following behaviors are associated with SR operating over the 432 MPLS dataplane: 434 o the IGP signaling extension for IGP-Prefix segment includes a flag 435 to indicate whether directly connected neighbors of the node on 436 which the prefix is attached should perform the NEXT operation or 437 the CONTINUE operation when processing the SID. This behavior is 438 equivalent to Penultimate Hop Popping (NEXT) or Ultimate Hop 439 Popping (CONTINUE) in MPLS. 441 o A Prefix-SID is allocated in the form of an MPLS label (or an 442 index in the SRGB) according to a process similar to IP address 443 allocation. Typically, the Prefix-SID is allocated by policy by 444 the operator (or NMS) and the SID very rarely changes. 446 o While SR allows to attach a local segment to an IGP prefix, it is 447 specifically assumed that when the terms "IGP-Prefix Segment" and 448 "Prefix-SID" are used, the segment is global (the SID is allocated 449 from the SRGB or as an index into the advertised SRGB). This is 450 consistent with all the described use-cases that require global 451 segments attached to IGP prefixes. 453 o The allocation process MUST NOT allocate the same Prefix-SID to 454 different IP prefixes. 456 o If a node learns a Prefix-SID having a value that falls outside 457 the locally configured SRGB range, then the node MUST NOT use the 458 Prefix-SID and SHOULD issue an error log reporting a 459 misconfiguration. 461 o If a node N advertises Prefix-SID SID-R for a prefix R that is 462 attached to N, if N specifies CONTINUE as the operation to be 463 performed by directly connected neighbors, N MUST maintain the 464 following FIB entry: 466 Incoming Active Segment: SID-R 467 Ingress Operation: NEXT 468 Egress interface: NULL 470 o A remote node M MUST maintain the following FIB entry for any 471 learned Prefix-SID SID-R attached to IP prefix R: 473 Incoming Active Segment: SID-R 474 Ingress Operation: 475 If the next-hop of R is the originator of R 476 and instructed to remove the active segment: NEXT 477 Else: CONTINUE 478 Egress interface: the interface towards the next-hop along the 479 path computed using the algorithm advertised with 480 the SID toward prefix R. 482 3.1.3. SRv6 484 When SR is used over the IPv6 dataplane: 486 o A Prefix-SID is an IPv6 address. 488 o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node 489 addresses are not SRv6 SIDs by default. 491 A node N advertising an IPv6 address R usable as a segment identifier 492 MUST maintain the following FIB entry: 494 Incoming Active Segment: R 495 Ingress Operation: NEXT 496 Egress interface: NULL 498 Note that forwarding to R does not require an entry in the FIBs of 499 all other routers for R. Forwarding can be and most often will be 500 achieved by a shorter mask prefix which covers R. 502 Independent of Segment Routing support, any remote IPv6 node will 503 maintain a plain IPv6 FIB entry for any prefix, no matter if the 504 prefix represents a segment or not. This allows forwarding of 505 packets to the node which owns the SID even by nodes which do not 506 support Segment Routing. 508 Support of multiple algorithms applies to SRv6. Since algorithm 509 specific SIDs are simply IPv6 addresses, algorithm specific 510 forwarding entries can be achieved by assigning algorithm specific 511 subnets to the (set of) algorithm specific SIDs which a node 512 allocates. 514 Nodes which do not support a given algorithm may still have a FIB 515 entry covering an algorithm specific address even though an algorithm 516 specific path has not been calculated by that node. This is 517 mitigated by the fact that nodes which do not support a given 518 algorithm will not be included in the topology associated with that 519 algorithm specific SPF and so traffic using the algorithm specific 520 destination will normally not flow via the excluded node. If such 521 traffic were to arrive and be forwarded by such a node, it will still 522 progress towards the destination node. The nexthop will either be a 523 node which supports the algorithm - in which case the packet will be 524 forwarded along algorithm specific paths (or be dropped if none are 525 available) - or the nexthop will be a node which does NOT support the 526 algorithm - in which case the packet will continue to be forwarded 527 along Algorithm 0 paths towards the destination node. 529 3.2. IGP-Node Segment, Node-SID 531 An IGP Node-SID MUST NOT be associated with a prefix that is owned by 532 more than one router within the same routing domain. 534 3.3. IGP-Anycast Segment, Anycast SID 536 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 537 shortest-path forwarding towards the closest node of the anycast set. 538 This is useful to express macro-engineering policies or protection 539 mechanisms. 541 An IGP-Anycast segment MUST NOT reference a particular node. 543 Within an anycast group, all routers in an SR domain MUST advertise 544 the same prefix with the same SID value. 546 3.3.1. Anycast SID in SR-MPLS 547 +--------------+ 548 | Group A | 549 |192.0.2.10/32 | 550 | SID:100 | 551 | | 552 +-----------A1---A3----------+ 553 | | | \ / | | | 554 SID:10 | | | / | | | SID:30 555 203.0.113.1/32 | | | / \ | | | 203.0.113.3/32 556 PE1------R1----------A2---A4---------R3------PE3 557 \ /| | | |\ / 558 \ / | +--------------+ | \ / 559 \ / | | \ / 560 / | | / 561 / \ | | / \ 562 / \ | +--------------+ | / \ 563 / \| | | |/ \ 564 PE2------R2----------B1---B3---------R4------PE4 565 203.0.113.2/32 | | | \ / | | | 203.0.113.4/32 566 SID:20 | | | / | | | SID:40 567 | | | / \ | | | 568 +-----------B2---B4----------+ 569 | | 570 | Group B | 571 | 192.0.2.1/32 | 572 | SID:200 | 573 +--------------+ 575 Figure 1: Transit device groups 577 The figure above describes a network example with two groups of 578 transit devices. Group A consists of devices {A1, A2, A3 and A4}. 579 They are all provisioned with the anycast address 192.0.2.10/32 and 580 the anycast SID 100. 582 Similarly, group B consists of devices {B1, B2, B3 and B4} and are 583 all provisioned with the anycast address 192.0.2.1/32, anycast SID 584 200. In the above network topology, each PE device has a path to 585 each of the groups A and B. 587 PE1 can choose a particular transit device group when sending traffic 588 to PE3 or PE4. This will be done by pushing the anycast SID of the 589 group in the stack. 591 Processing the anycast, and subsequent segments, requires special 592 care. 594 +-------------------------+ 595 | Group A | 596 | 192.0.2.10/32 | 597 | SID:100 | 598 |-------------------------| 599 | | 600 | SRGB: SRGB: | 601 SID:10 |(1000-2000) (3000-4000)| SID:30 602 PE1---+ +-------A1-------------A3-------+ +---PE3 603 \ / | | \ / | | \ / 604 \ / | | +-----+ / | | \ / 605 SRGB: \ / | | \ / | | \ / SRGB: 606 (7000-8000) R1 | | \ | | R3 (6000-7000) 607 / \ | | / \ | | / \ 608 / \ | | +-----+ \ | | / \ 609 / \ | | / \ | | / \ 610 PE2---+ +-------A2-------------A4-------+ +---PE4 611 SID:20 | SRGB: SRGB: | SID:40 612 |(2000-3000) (4000-5000)| 613 | | 614 +-------------------------+ 616 Figure 2: Transit paths via anycast group A 618 Considering an MPLS deployment, in the above topology, if device PE1 619 (or PE2) requires to send a packet to the device PE3 (or PE4) it 620 needs to encapsulate the packet in an MPLS payload with the following 621 stack of labels. 623 o Label allocated by R1 for anycast SID 100 (outer label). 625 o Label allocated by the nearest router in group A for SID 30 (for 626 destination PE3). 628 While the first label is easy to compute, in this case since there 629 are more than one topologically nearest devices (A1 and A2), unless 630 A1 and A2 allocated the same label value to the same prefix, 631 determining the second label is impossible. Devices A1 and A2 may be 632 devices from different hardware vendors. If both don't allocate the 633 same label value for SID 30, it is impossible to use the anycast 634 group "A" as a transit anycast group towards PE3. Hence, PE1 (or 635 PE2) cannot compute an appropriate label stack to steer the packet 636 exclusively through the group A devices. Same holds true for devices 637 PE3 and PE4 when trying to send a packet to PE1 or PE2. 639 To ease the use of anycast segment, it is recommended to configure 640 identical SRGBs on all nodes of a particular anycast group. Using 641 this method, as mentioned above, computation of the label following 642 the anycast segment is straightforward. 644 Using anycast segment without configuring identical SRGBs on all 645 nodes belonging to the same device group may lead to misrouting (in 646 an MPLS VPN deployment, some traffic may leak between VPNs). 648 3.4. IGP-Adjacency Segment, Adj-SID 650 The adjacency is formed by the local node (i.e., the node advertising 651 the adjacency in the IGP) and the remote node (i.e., the other end of 652 the adjacency). The local node MUST be an IGP node. The remote node 653 may be an adjacent IGP neighbor or a non-adjacent neighbor (e.g., a 654 Forwarding Adjacency, [RFC4206]). 656 A packet injected anywhere within the SR domain with a segment list 657 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 658 attached by node N to its adjacency over link L, will be forwarded 659 along the shortest-path to N and then be switched by N, without any 660 IP shortest-path consideration, towards link L. If the Adj-SID 661 identifies a set of adjacencies, then the node N load-balances the 662 traffic among the various members of the set. 664 Similarly, when using a global Adj-SID, a packet injected anywhere 665 within the SR domain with a segment list {SNL}, where SNL is a global 666 Adj-SID attached by node N to its adjacency over link L, will be 667 forwarded along the shortest-path to N and then be switched by N, 668 without any IP shortest-path consideration, towards link L. If the 669 Adj-SID identifies a set of adjacencies, then the node N does load- 670 balance the traffic among the various members of the set. The use of 671 global Adj-SID allows to reduce the size of the segment list when 672 expressing a path at the cost of additional state (i.e.: the global 673 Adj-SID will be inserted by all routers within the area in their 674 forwarding table). 676 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 677 packet from a node towards a defined interface or set of interfaces. 678 This is key to theoretically prove that any path can be expressed as 679 a list of segments. 681 The encodings of the Adj-SID include a set of flags supporting the 682 following functionalities: 684 o Eligible for Protection (e.g., using IPFRR or MPLS-FRR). 685 Protection allows that in the event the interface(s) associated 686 with the Adj-SID are down, that the packet can still be forwarded 687 via an alternate path to the node at the remote end of the 688 interface(s). The use of protection is clearly a policy based 689 decision i.e., for a given policy protection may or may not be 690 desirable. 692 o Indication whether the Adj-SID has local or global scope. Default 693 scope SHOULD be Local. 695 o Indication whether the Adj-SID is persistent across control plane 696 restarts. Persistence is a key attribute in ensuring that an SR 697 Policy does not temporarily result in misforwarding due to 698 reassignment of an Adj-SID. 700 A weight (as described below) is also associated with the Adj-SID 701 advertisement. 703 A node SHOULD allocate one Adj-SID for each of its adjacencies. 705 A node MAY allocate multiple Adj-SIDs for the same adjacency. An 706 example is to support an Adj-SID which is eligible for protection and 707 an Adj-SID which is NOT eligible for protection. 709 A node MAY associate the same Adj-SID to multiple adjacencies. 711 In order to be able to advertise in the IGP all the Adj-SIDs 712 representing the IGP adjacencies between two nodes, parallel 713 adjacency suppression MUST NOT be performed by the IGP. 715 When a node binds an Adj-SID to a local data-link L, the node MUST 716 install the following FIB entry: 718 Incoming Active Segment: V 719 Ingress Operation: NEXT 720 Egress Interface: L 722 The Adj-SID implies, from the router advertising it, the forwarding 723 of the packet through the adjacency(ies) identified by the Adj-SID, 724 regardless of its IGP/SPF cost. In other words, the use of adjacency 725 segments overrides the routing decision made by the SPF algorithm. 727 3.4.1. Parallel Adjacencies 729 Adj-SIDs can be used in order to represent a set of parallel 730 interfaces between two adjacent routers. 732 A node MUST install a FIB entry for any locally originated adjacency 733 segment (Adj-SID) of value W attached to a set of links B with: 735 Incoming Active Segment: W 736 Ingress Operation: NEXT 737 Egress interface: load-balance between any data-link within set B 739 When parallel adjacencies are used and associated to the same Adj- 740 SID, and in order to optimize the load balancing function, a "weight" 741 factor can be associated to the Adj-SID advertised with each 742 adjacency. The weight tells the ingress (or an SDN/orchestration 743 system) about the load-balancing factor over the parallel 744 adjacencies. As shown in Figure 3, A and B are connected through two 745 parallel adjacencies 747 link-1 748 +--------+ 749 | | 750 S---A B---C 751 | | 752 +--------+ 753 link-2 755 Figure 3: Parallel Links and Adj-SIDs 757 Node A advertises following Adj-SIDs and weights: 759 o Link-1: Adj-SID 1000, weight: 1 761 o Link-2: Adj-SID 1000, weight: 2 763 Node S receives the advertisements of the parallel adjacencies and 764 understands that by using Adj-SID 1000 node A will load-balance the 765 traffic across the parallel links (link-1 and link-2) according to a 766 1:2 ratio i.e., twice as many packets will flow over Link-2 as 767 compared to Link-1. 769 3.4.2. LAN Adjacency Segments 771 In LAN subnetworks, link-state protocols define the concept of 772 Designated Router (DR, in OSPF) or Designated Intermediate System 773 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 774 that describe the LAN topology in a special routing update (OSPF 775 Type2 LSA or IS-IS Pseudonode LSP). 777 The difficulty with LANs is that each router only advertises its 778 connectivity to the DR/DIS and not to each of the individual nodes in 779 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 780 are necessary in order for each router in the LAN to advertise an 781 Adj-SID associated to each neighbor in the LAN. 783 3.5. Inter-Area Considerations 785 In the following example diagram it is assumed that the all areas are 786 part of a single SR Domain. 788 The example here below assumes the IPv6 control plane with the MPLS 789 dataplane. 791 ! ! 792 ! ! 793 B------C-----F----G-----K 794 / | | | 795 S---A/ | | | 796 \ | | | 797 \D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150) 798 ! ! 799 Area-1 ! Backbone ! Area 2 800 ! area ! 802 Figure 4: Inter-Area Topology Example 804 In area 2, node Z allocates Node-SID 150 to his local IPv6 prefix 805 2001:DB8::2:1/128. 807 Area Border Routers (ABR) G and J will propagate the prefix and its 808 SIDs into the backbone area by creating a new instance of the prefix 809 according to normal inter-area/level IGP propagation rules. 811 Nodes C and I will apply the same behavior when leaking prefixes from 812 the backbone area down to area 1. Therefore, node S will see prefix 813 2001:DB8::2:1/128 with Prefix-SID 150 and advertised by nodes C and 814 I. 816 It therefore results that a Prefix-SID remains attached to its 817 related IGP Prefix through the inter-area process, which is the 818 expected behavior in a single SR Domain. 820 When node S sends traffic to 2001:DB8::2:1/128, it pushes Node- 821 SID(150) as active segment and forward it to A. 823 When packet arrives at ABR I (or C), the ABR forwards the packet 824 according to the active segment (Node-SID(150)). Forwarding 825 continues across area borders, using the same Node-SID(150), until 826 the packet reaches its destination. 828 4. BGP Peering Segments 830 BGP segments may be allocated and distributed by BGP. 832 4.1. BGP Prefix Segment 834 A BGP-Prefix segment is a BGP segment attached to a BGP prefix. 836 A BGP-Prefix segment is global (unless explicitly advertised 837 otherwise) within the SR domain. 839 The BGP Prefix SID is the BGP equivalent to the IGP Prefix Segment. 841 A likely use-case for the BGP Prefix Segment is an IGP-free hyper- 842 scale spine-leaf topology where connectivity is learned solely via 843 BGP [RFC7938] 845 4.2. BGP Peering Segments 847 In the context of BGP Egress Peer Engineering (EPE), as described in 848 [I-D.ietf-spring-segment-routing-central-epe], an EPE enabled Egress 849 PE node MAY advertise segments corresponding to its attached peers. 850 These segments are called BGP peering segments or BGP peering SIDs. 851 They enable the expression of source-routed inter-domain paths. 853 An ingress border router of an AS may compose a list of segments to 854 steer a flow along a selected path within the AS, towards a selected 855 egress border router C of the AS and through a specific peer. At 856 minimum, a BGP peering Engineering policy applied at an ingress PE 857 involves two segments: the Node SID of the chosen egress PE and then 858 the BGP peering segment for the chosen egress PE peer or peering 859 interface. 861 Three types of BGP peering segments/SIDs are defined: PeerNode SID, 862 PeerAdj SID and PeerSet SID. 864 o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At 865 the BGP node advertising it, its semantics is: 867 * SR header operation: NEXT. 869 * Next-Hop: the connected peering node to which the segment is 870 related. 872 o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the 873 BGP node advertising it, the semantic is: 875 * SR header operation: NEXT. 877 * Next-Hop: the peer connected through the interface to which the 878 segment is related. 880 o PeerSet SID. a BGP PeerSet segment/SID is a local segment. At the 881 BGP node advertising it, the semantic is: 883 * SR header operation: NEXT. 885 * Next-Hop: load-balance across any connected interface to any 886 peer in the related group. 888 A peer set could be all the connected peers from the same AS or a 889 subset of these. A group could also span across AS. The group 890 definition is a policy set by the operator. 892 The BGP extensions necessary in order to signal these BGP peering 893 segments are defined in [I-D.ietf-idr-bgpls-segment-routing-epe] 895 5. Binding Segment 897 In order to provide greater scalability, network opacity, and service 898 independence, SR utilizes a Binding SID (BSID). The BSID is bound to 899 an SR policy, instantiation of which may involve a list of SIDs. Any 900 packets received with active segment = BSID are steered onto the 901 bound SR Policy. 903 A BSID may either be a local or a global SID. If local, a BSID 904 SHOULD be allocated from the SRLB. If global, a BSID MUST be 905 allocated from the SRGB. 907 Use of a BSID allows the instantiation of the policy (the SID list) 908 to be stored only on the node(s) which need to impose the policy. 909 Direction of traffic to a node supporting the policy then only 910 requires imposition of the BSID. If the policy changes, this also 911 means that only the nodes imposing the policy need to be updated. 912 Users of the policy are not impacted. 914 5.1. IGP Mirroring Context Segment 916 One use case for a Binding Segment is to provide support for an IGP 917 node to advertise its ability to process traffic originally destined 918 to another IGP node, called the Mirrored node and identified by an IP 919 address or a Node-SID, provided that a "Mirroring Context" segment be 920 inserted in the segment list prior to any service segment local to 921 the mirrored node. 923 When a given node B wants to provide egress node A protection, it 924 advertises a segment identifying node's A context. Such segment is 925 called "Mirror Context Segment" and identified by the Mirror SID. 927 The Mirror SID is advertised using the binding segment defined in SR 928 IGP protocol extensions [I-D.ietf-isis-segment-routing-extensions] . 930 In the event of a failure, a point of local repair (PLR) diverting 931 traffic from A to B does a PUSH of the Mirror SID on the protected 932 traffic. B, when receiving the traffic with the Mirror SID as the 933 active segment, uses that segment and processes underlying segments 934 in the context of A. 936 6. Multicast 938 Segment Routing is defined for unicast. The application of the 939 source-route concept to Multicast is not in the scope of this 940 document. 942 7. IANA Considerations 944 This document does not require any action from IANA. 946 8. Security Considerations 948 Segment Routing is applicable to both MPLS and IPv6 data planes. 950 Segment Routing adds some meta-data (instructions) to the packet, 951 with the list of forwarding path elements (e.g., nodes, links, 952 services, etc.) that the packet must traverse. It has to be noted 953 that the complete source routed path may be represented by a single 954 segment. This is the case of the Binding SID. 956 SR by default operates within a trusted domain. Traffic MUST be 957 filtered at the domain boundaries. 959 8.1. SR-MPLS 961 When applied to the MPLS data plane, Segment Routing does not 962 introduce any new behavior or any change in the way MPLS data plane 963 works. Therefore, from a security standpoint, this document does not 964 define any additional mechanism in the MPLS data plane. 966 SR allows the expression of a source routed path using a single 967 segment (the Binding SID). Compared to RSVP-TE which also provides 968 explicit routing capability, there are no fundamental differences in 969 term of information provided. Both RSVP-TE and Segment Routing may 970 express a source routed path using a single segment. 972 When a path is expressed using a single label, the syntax of the 973 meta-data is equivalent between RSVP-TE [RFC3209] and SR. 975 When a source routed path is expressed with a list of segments 976 additional meta-data is added to the packet consisting of the source 977 routed path the packet must follow expressed as a segment list. 979 When a path is expressed using a label stack, if one has access to 980 the meaning (i.e.: the Forwarding Equivalence Class) of the labels, 981 one has the knowledge of the explicit path. For the MPLS data plane, 982 as no data plane modification is required, there is no fundamental 983 change of capability. Yet, the occurrence of label stacking will 984 increase. 986 SR domain boundary routers MUST filter any external traffic destined 987 to a label associated with a segment within the trusted domain. This 988 includes labels within the SRGB of the trusted domain, labels within 989 the SRLB of the specific boundary router, and labels outside either 990 of these blocks. External traffic is any traffic received from an 991 interface connected to a node outside the domain of trust. 993 From a network protection standpoint, there is an assumed trust model 994 such that any node imposing a label stack on a packet is assumed to 995 be allowed to do so. This is a significant change compared to plain 996 IP offering shortest path routing but not fundamentally different 997 compared to existing techniques providing explicit routing capability 998 such as RSVP-TE. By default, the explicit routing information MUST 999 NOT be leaked through the boundaries of the administered domain. 1000 Segment Routing extensions that have been defined in various 1001 protocols, leverage the security mechanisms of these protocols such 1002 as encryption, authentication, filtering, etc. 1004 In the general case, a segment routing capable router accepts and 1005 install labels only if these labels have been previously advertised 1006 by a trusted source. The received information is validated using 1007 existing control plane protocols providing authentication and 1008 security mechanisms. Segment Routing does not define any additional 1009 security mechanism in existing control plane protocols. 1011 Segment Routing does not introduce signaling between the source and 1012 the mid points of a source routed path. With SR, the source routed 1013 path is computed using SIDs previously advertised in the IP control 1014 plane. Therefore, in addition to filtering and controlled 1015 advertisement of SIDs at the boundaries of the SR domain, filtering 1016 in the data plane is also required. Filtering MUST be performed on 1017 the forwarding plane at the boundaries of the SR domain and may 1018 require looking at multiple labels/instruction. 1020 For the MPLS data plane, there are no new requirements as the 1021 existing MPLS architecture already allows such source routing by 1022 stacking multiple labels. And for security protection, [RFC4381] and 1023 [RFC5920] already call for the filtering of MPLS packets on trust 1024 boundaries. 1026 8.2. SRv6 1028 When applied to the IPv6 data plane, Segment Routing does introduce 1029 the Segment Routing Header (SRH, 1030 [I-D.ietf-6man-segment-routing-header]) which is a type of Routing 1031 Extension header as defined in [RFC8200]. 1033 The SRH adds some meta-data to the IPv6 packet, with the list of 1034 forwarding path elements (e.g., nodes, links, services, etc.) that 1035 the packet must traverse and that are represented by IPv6 addresses. 1036 A complete source routed path may be encoded in the packet using a 1037 single segment (single IPv6 address). 1039 SR domain boundary routers MUST filter any external traffic destined 1040 to an address within the SRGB of the trusted domain or the SRLB of 1041 the specific boundary router. External traffic is any traffic 1042 received from an interface connected to a node outside the domain of 1043 trust. 1045 From a network protection standpoint, there is an assumed trust model 1046 such that any node adding an SRH to the packet is assumed to be 1047 allowed to do so. Therefore, by default, the explicit routing 1048 information MUST NOT be leaked through the boundaries of the 1049 administered domain. Segment Routing extensions that have been 1050 defined in various protocols, leverage the security mechanisms of 1051 these protocols such as encryption, authentication, filtering, etc. 1053 In the general case, an SR IPv6 router accepts and install segments 1054 identifiers (in the form of IPv6 addresses), only if these SIDs are 1055 advertised by a trusted source. The received information is 1056 validated using existing control plane protocols providing 1057 authentication and security mechanisms. Segment Routing does not 1058 define any additional security mechanism in existing control plane 1059 protocols. 1061 Problems which may arise when the above behaviors are not done 1062 include: 1064 o Malicious looping 1066 o Evasion of access controls 1067 o Hiding the source of DOS attacks 1069 Security concerns with source routing at the IPv6 data plane are more 1070 completely discussed in [RFC5095]. The new IPv6-based segment 1071 routing header is defined in [I-D.ietf-6man-segment-routing-header]. 1072 This document also discusses the above security concerns. 1074 8.3. Congestion Control 1076 SR does not introduce new requirements for congestion control. By 1077 default, traffic delivery is assumed to be best effort. Congestion 1078 control may be implemented at endpoints. Where SR policies are in 1079 use bandwidth allocation may be managed by monitoring incoming 1080 traffic associated with the binding SID identifying the SR policy. 1081 Other solutions such as [RFC8084] may be applicable. 1083 9. Manageability Considerations 1085 In SR enabled networks, the path the packet takes is encoded in the 1086 header. As the path is not signaled through a protocol, OAM 1087 mechanisms are necessary in order for the network operator to 1088 validate the effectiveness of a path as well as to check and monitor 1089 its liveness and performance. However, it has to be noted that SR 1090 allows to reduce substantially the number of states in transit nodes 1091 and hence the number of elements that a transit node has to manage is 1092 smaller. 1094 SR OAM use cases for the MPLS data plane are defined in 1095 [I-D.ietf-spring-oam-usecase]. SR OAM procedures for the MPLS data 1096 plane are defined in [I-D.ietf-mpls-spring-lsp-ping]. 1098 SR routers receive advertisements of SIDs (index, label or IPv6 1099 address) from the different routing protocols being extended for SR. 1100 Each of these protocols have monitoring and troubleshooting 1101 mechanisms to provide operation and management functions for IP 1102 addresses that must be extended in order to include troubleshooting 1103 and monitoring functions of the SID. 1105 SR architecture introduces the usage of global segments. Each global 1106 segment MUST be bound to a unique index or address within an SR 1107 domain. The management of the allocation of such index or address by 1108 the operator is critical for the network behavior to avoid situations 1109 like mis-routing. In addition to the allocation policy/tooling that 1110 the operator will have in place, an implementation SHOULD protect the 1111 network in case of conflict detection by providing a deterministic 1112 resolution approach. 1114 When a path is expressed using a label stack, the occurrence of label 1115 stacking will increase. A node may want to signal in the control 1116 plane its ability in terms of size of the label stack it can support. 1118 A YANG data model [RFC6020] for segment routing configuration and 1119 operations has been defined in [I-D.ietf-spring-sr-yang]. 1121 When Segment Routing is applied to the IPv6 data plane, segments are 1122 identified through IPv6 addresses. The allocation, management and 1123 troubleshooting of segment identifiers is no different than the 1124 existing mechanisms applied to the allocation and management of IPv6 1125 addresses. 1127 The DA of the packet gives the active segment address. The segment 1128 list in the SRH gives the entire path of the packet. The validation 1129 of the source routed path is done through inspection of DA and SRH 1130 present in the packet header matched to the equivalent routing table 1131 entries. 1133 In the context of SR over the IPv6 data plane, the source routed path 1134 is encoded in the SRH as described in 1135 [I-D.ietf-6man-segment-routing-header]. The SR IPv6 source routed 1136 path is instantiated into the SRH as a list of IPv6 address where the 1137 active segment is in the Destination Address (DA) field of the IPv6 1138 packet header. Typically, by inspecting in any node the packet 1139 header, it is possible to derive the source routed path it belongs 1140 to. Similar to the context of SR over MPLS data plane, an 1141 implementation may originate path control and monitoring packets 1142 where the source routed path is inserted in the SRH and where each 1143 segment of the path inserts in the packet the relevant data in order 1144 to measure the end to end path and performance. 1146 10. Contributors 1148 The following people have substantially contributed to the definition 1149 of the Segment Routing architecture and to the editing of this 1150 document: 1152 Ahmed Bashandy 1153 Cisco Systems, Inc. 1154 Email: bashandy@cisco.com 1156 Martin Horneffer 1157 Deutsche Telekom 1158 Email: Martin.Horneffer@telekom.de 1159 Wim Henderickx 1160 Nokia 1161 Email: wim.henderickx@nokia.com 1163 Jeff Tantsura 1164 Email: jefftant@gmail.com 1166 Edward Crabbe 1167 Email: edward.crabbe@gmail.com 1169 Igor Milojevic 1170 Email: milojevicigor@gmail.com 1172 Saku Ytti 1173 TDC 1174 Email: saku@ytti.fi 1176 11. Acknowledgements 1178 We would like to thank Dave Ward, Peter Psenak, Dan Frost, Stewart 1179 Bryant, Pierre Francois, Thomas Telkamp, Ruediger Geib, Hannes 1180 Gredler, Pushpasis Sarkar, Eric Rosen, Chris Bowers and Alvaro Retana 1181 for their comments and review of this document. 1183 12. References 1185 12.1. Normative References 1187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1188 Requirement Levels", BCP 14, RFC 2119, 1189 DOI 10.17487/RFC2119, March 1997, 1190 . 1192 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1193 Label Switching Architecture", RFC 3031, 1194 DOI 10.17487/RFC3031, January 2001, 1195 . 1197 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1198 (IPv6) Specification", STD 86, RFC 8200, 1199 DOI 10.17487/RFC8200, July 2017, 1200 . 1202 12.2. Informative References 1204 [I-D.ietf-6man-segment-routing-header] 1205 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 1206 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1207 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 1208 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 1209 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1210 segment-routing-header-07 (work in progress), July 2017. 1212 [I-D.ietf-idr-bgpls-segment-routing-epe] 1213 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 1214 Dong, "BGP-LS extensions for Segment Routing BGP Egress 1215 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 1216 epe-14 (work in progress), December 2017. 1218 [I-D.ietf-isis-segment-routing-extensions] 1219 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1220 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 1221 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1222 segment-routing-extensions-15 (work in progress), December 1223 2017. 1225 [I-D.ietf-mpls-spring-lsp-ping] 1226 Kumar, N., Pignataro, C., Swallow, G., Akiya, N., Kini, 1227 S., and M. Chen, "Label Switched Path (LSP) Ping/ 1228 Traceroute for Segment Routing IGP Prefix and Adjacency 1229 SIDs with MPLS Data-plane", draft-ietf-mpls-spring-lsp- 1230 ping-13 (work in progress), October 2017. 1232 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1233 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1234 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1235 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1236 segment-routing-extensions-10 (work in progress), 1237 September 2017. 1239 [I-D.ietf-ospf-segment-routing-extensions] 1240 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1241 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1242 Extensions for Segment Routing", draft-ietf-ospf-segment- 1243 routing-extensions-24 (work in progress), December 2017. 1245 [I-D.ietf-pce-segment-routing] 1246 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1247 and J. Hardwick, "PCEP Extensions for Segment Routing", 1248 draft-ietf-pce-segment-routing-11 (work in progress), 1249 November 2017. 1251 [I-D.ietf-spring-oam-usecase] 1252 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A 1253 Scalable and Topology-Aware MPLS Dataplane Monitoring 1254 System", draft-ietf-spring-oam-usecase-10 (work in 1255 progress), December 2017. 1257 [I-D.ietf-spring-resiliency-use-cases] 1258 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 1259 "Resiliency use cases in SPRING networks", draft-ietf- 1260 spring-resiliency-use-cases-12 (work in progress), 1261 December 2017. 1263 [I-D.ietf-spring-segment-routing-central-epe] 1264 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1265 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1266 Engineering", draft-ietf-spring-segment-routing-central- 1267 epe-08 (work in progress), December 2017. 1269 [I-D.ietf-spring-segment-routing-mpls] 1270 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1271 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1272 data plane", draft-ietf-spring-segment-routing-mpls-11 1273 (work in progress), October 2017. 1275 [I-D.ietf-spring-sr-yang] 1276 Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG 1277 Data Model for Segment Routing", draft-ietf-spring-sr- 1278 yang-07 (work in progress), July 2017. 1280 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1281 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1282 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1283 . 1285 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1286 Hierarchy with Generalized Multi-Protocol Label Switching 1287 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1288 DOI 10.17487/RFC4206, October 2005, 1289 . 1291 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1292 Virtual Private Networks (VPNs)", RFC 4381, 1293 DOI 10.17487/RFC4381, February 2006, 1294 . 1296 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1297 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1298 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1299 . 1301 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1302 of Type 0 Routing Headers in IPv6", RFC 5095, 1303 DOI 10.17487/RFC5095, December 2007, 1304 . 1306 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1307 Topology (MT) Routing in Intermediate System to 1308 Intermediate Systems (IS-ISs)", RFC 5120, 1309 DOI 10.17487/RFC5120, February 2008, 1310 . 1312 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1313 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1314 DOI 10.17487/RFC5440, March 2009, 1315 . 1317 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1318 RFC 5714, DOI 10.17487/RFC5714, January 2010, 1319 . 1321 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1322 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1323 . 1325 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1326 the Network Configuration Protocol (NETCONF)", RFC 6020, 1327 DOI 10.17487/RFC6020, October 2010, 1328 . 1330 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1331 and A. Bierman, Ed., "Network Configuration Protocol 1332 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1333 . 1335 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1336 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1337 March 2012, . 1339 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 1340 BGP for Routing in Large-Scale Data Centers", RFC 7938, 1341 DOI 10.17487/RFC7938, August 2016, 1342 . 1344 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 1345 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 1346 . 1348 [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS 1349 Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 1350 2017, . 1352 Authors' Addresses 1354 Clarence Filsfils (editor) 1355 Cisco Systems, Inc. 1356 Brussels 1357 BE 1359 Email: cfilsfil@cisco.com 1361 Stefano Previdi (editor) 1362 Cisco Systems, Inc. 1363 Italy 1365 Email: stefano@previdi.net 1367 Les Ginsberg 1368 Cisco Systems, Inc 1370 Email: ginsberg@cisco.com 1372 Bruno Decraene 1373 Orange 1374 FR 1376 Email: bruno.decraene@orange.com 1378 Stephane Litkowski 1379 Orange 1380 FR 1382 Email: stephane.litkowski@orange.com 1383 Rob Shakir 1384 Google, Inc. 1385 1600 Amphitheatre Parkway 1386 Mountain View, CA 94043 1387 US 1389 Email: robjs@google.com