idnits 2.17.00 (12 Aug 2021) /tmp/idnits32648/draft-ietf-spring-segment-routing-13.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 (October 28, 2017) is 1665 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-mpls-spring-lsp-ping has been published as RFC 8287 == 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 (~~), 13 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: May 1, 2018 L. Ginsberg 6 Cisco Systems, Inc 7 B. Decraene 8 S. Litkowski 9 Orange 10 R. Shakir 11 Google, Inc. 12 October 28, 2017 14 Segment Routing Architecture 15 draft-ietf-spring-segment-routing-13 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 May 1, 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 . . . . . . . . . . . . . 14 91 3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 15 92 3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 16 93 3.5. Inter-Area Considerations . . . . . . . . . . . . . . . . 17 95 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 18 96 4.1. BGP Prefix Segment . . . . . . . . . . . . . . . . . . . 18 97 4.2. BGP Peering Segments . . . . . . . . . . . . . . . . . . 18 98 5. Binding Segment . . . . . . . . . . . . . . . . . . . . . . . 19 99 5.1. IGP Mirroring Context Segment . . . . . . . . . . . . . . 19 100 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 103 8.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 8.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 9. Manageability Considerations . . . . . . . . . . . . . . . . 22 106 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 107 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 109 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 110 12.2. Informative References . . . . . . . . . . . . . . . . . 25 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 113 1. Introduction 115 Segment Routing (SR) leverages the source routing paradigm. A node 116 steers a packet through an SR Policy instantiated as an ordered list 117 of instructions called segments. A segment can represent any 118 instruction, topological or service-based. A segment can have a 119 semantic local to an SR node or global within an SR domain. SR 120 supports per-flow explicit routing while maintaining per-flow state 121 only at the ingress nodes to the SR domain. 123 A segment is often referred by its Segment Identifier (SID). 125 A segment may be associated with a topological instruction. A 126 topological local segment may instruct a node to forward the packet 127 via a specific outgoing interface. A topological global segment may 128 instruct an SR domain to forward the packet via a specific path to a 129 destination. Different segments may exist for the same destination, 130 each with different path objectives (e.g., which metric is minimized, 131 what constraints are specified). 133 A segment may be associated with a service instruction (e.g. the 134 packet should be processed by a container or VM associated with the 135 segment). A segment may be associated with a QoS treatment (e.g., 136 shape the packets received with this segment at x Mbps). 138 The SR architecture supports any type of instruction associated with 139 a segment. 141 The SR architecture supports any type of control-plane: distributed, 142 centralized or hybrid. 144 In a distributed scenario, the segments are allocated and signaled by 145 IS-IS or OSPF or BGP. A node individually decides to steer packets 146 on a source-routed policy (e.g., pre-computed local protection 147 [I-D.ietf-spring-resiliency-use-cases] ) . A node individually 148 computes the source-routed policy. 150 In a centralized scenario, the segments are allocated and 151 instantiated by an SR controller. The SR controller decides which 152 nodes need to steer which packets on which source-routed policies. 153 The SR controller computes the source-routed policies. The SR 154 architecture does not restrict how the controller programs the 155 network. Likely options are NETCONF, PCEP and BGP. The SR 156 architecture does not restrict the number of SR controllers. 157 Specifically multiple SR controllers may program the same SR domain. 158 The SR architecture allows these SR controllers to discover which 159 SID's are instantiated at which nodes and which sets of local (SRLB) 160 and global labels (SRGB) are available at which node. 162 A hybrid scenario complements a base distributed control-plane with a 163 centralized controller. For example, when the destination is outside 164 the IGP domain, the SR controller may compute a source-routed policy 165 on behalf of an IGP node. The SR architecture does not restrict how 166 the nodes which are part of the distributed control-plane interact 167 with the SR controller. Likely options are PCEP and BGP. 169 Hosts MAY be part of an SR Domain. A centralized controller can 170 inform hosts about policies either by pushing these policies to hosts 171 or responding to requests from hosts. 173 The SR architecture can be instantiated on various dataplanes. This 174 document introduces two dataplanes instantiations of SR: SR over MPLS 175 (SR-MPLS) and SR over IPv6 (SRv6). 177 Segment Routing can be directly applied to the MPLS architecture with 178 no change on the forwarding plane 179 [I-D.ietf-spring-segment-routing-mpls] A segment is encoded as an 180 MPLS label. An SR Policy is instantiated as a stack of labels. The 181 segment to process (the active segment) is on the top of the stack. 182 Upon completion of a segment, the related label is popped from the 183 stack. 185 Segment Routing can be applied to the IPv6 architecture with a new 186 type of routing header called the SR header (SRH) 187 [I-D.ietf-6man-segment-routing-header] . An instruction is associated 188 with a segment and encoded as an IPv6 address. An SRv6 segment is 189 also called an SRv6 SID. An SR Policy is instantiated as an ordered 190 list of SRv6 SID's in the routing header. The active segment is 191 indicated by the Destination Address(DA) of the packet. The next 192 active segment is indicated by the SegmentsLeft (SL) pointer in the 193 SRH. When an SRv6 SID is completed, the SL is decremented and the 194 next segment is copied to the DA. When a packet is steered on an SR 195 policy, the related SRH is added to the packet. 197 In the context of an IGP-based distributed control-plane, two 198 topological segments are defined: the IGP adjacency segment and the 199 IGP prefix segment. 201 In the context of a BGP-based distributed control-plane, two 202 topological segments are defined: the BGP peering segment and the BGP 203 prefix segment. 205 The headend of an SR Policy binds a SID (called Binding segment or 206 BSID) to its policy. When the headend receives a packet with active 207 segment matching the BSID of a local SR Policy, the headend steers 208 the packet into the associated SR Policy. 210 This document defines the IGP, BGP and Binding segments for the SR- 211 MPLS and SRv6 dataplanes. 213 2. Terminology 215 SR-MPLS: the instantiation of SR on the MPLS dataplane 217 SRv6: the instantiation of SR on the IPv6 dataplane. 219 Segment: an instruction a node executes on the incoming packet (e.g.: 220 forward packet according to shortest path to destination, or, forward 221 packet through a specific interface, or, deliver the packet to a 222 given application/service instance). 224 SID: a segment identifier. Note that the term SID is commonly used 225 in place of the term Segment, though this is technically imprecise as 226 it overlooks any necessary translation. 228 SR-MPLS SID: an MPLS label or an index value into an MPLS label space 229 explicitly associated with the segment. 231 SRv6 SID: an IPv6 address explicitly associated with the segment. 233 Segment Routing Domain (SR Domain): the set of nodes participating in 234 the source based routing model. These nodes may be connected to the 235 same physical infrastructure (e.g.: a Service Provider's network). 236 They may as well be remotely connected to each other (e.g.: an 237 enterprise VPN or an overlay). If multiple protocol instances are 238 deployed, the SR domain most commonly includes all of the protocol 239 instances in a single SR domain. However, some deployments may wish 240 to sub-divide the network into multiple SR domains, each of which 241 includes one or more protocol instances. It is expected that all 242 nodes in an SR Domain are managed by the same administrative entity. 244 Active Segment: the segment that MUST be used by the receiving router 245 to process the packet. In the MPLS dataplane it is the top label. 246 In the IPv6 dataplane it is the destination address. 247 [I-D.ietf-6man-segment-routing-header]. 249 PUSH: the instruction consisting of the insertion of a segment at the 250 top of the segment list. In SR-MPLS the top of the segment list is 251 the topmost (outer) label of the label stack. In SRv6, the top of 252 the segment list is represented by the first segment in the Segment 253 Routing Header as defined in [I-D.ietf-6man-segment-routing-header]. 255 NEXT: when the active segment is completed, NEXT is the instruction 256 consisting of the inspection of the next segment. The next segment 257 becomes active. In SR-MPLS, NEXT is implemented as a POP of the top 258 label. In SRv6, NEXT is implemented as the copy of the next segment 259 from the SRH to the Destination Address of the IPv6 header. 261 CONTINUE: the active segment is not completed and hence remains 262 active. In SR-MPLS, CONTINUE instruction is implemented as a SWAP of 263 the top label. [RFC3031] In SRv6, this is the plain IPv6 forwarding 264 action of a regular IPv6 packet according to its Destination Address. 266 SR Global Block (SRGB): the set of global segments in the SR Domain. 267 If a node participates in multiple SR domains, there is one SRGB for 268 each SR domain. In SR-MPLS, SRGB is a local property of a node and 269 identifies the set of local labels reserved for global segments. In 270 SR-MPLS, using the same SRGB on all nodes within the SR Domain is 271 strongly recommended. Doing so eases operations and troubleshooting 272 as the same label represents the same global segment at each node. 273 In SRv6, the SRGB is the set of global SRv6 SIDs in the SR Domain. 275 SR Local Block (SRLB): local property of an SR node. If a node 276 participates in multiple SR domains, there is one SRLB for each SR 277 domain. In SR-MPLS, SRLB is a set of local labels reserved for local 278 segments. In SRv6, SRLB is a set of local IPv6 addresses reserved 279 for local SRv6 SID's. In a controller-driven network, some 280 controllers or applications MAY use the control plane to discover the 281 available set of local segments. 283 Global Segment: a segment which is part of the SRGB of the domain. 284 The instruction associated to the segment is defined at the SR Domain 285 level. A topological shortest-path segment to a given destination 286 within an SR domain is a typical example of a global segment. 288 Local Segment: In SR-MPLS, this is a local label outside the SRGB. 289 It MAY be part of the explicitly advertised SRLB. In SRv6, this can 290 be any IPv6 address i.e., the address MAY be part of the SRGB but 291 used such that it has local significance. The instruction associated 292 to the segment is defined at the node level. 294 IGP Segment: the generic name for a segment attached to a piece of 295 information advertised by a link-state IGP, e.g. an IGP prefix or an 296 IGP adjacency. 298 IGP-Prefix Segment: an IGP-Prefix Segment is an IGP Segment 299 representing an IGP prefix. When an IGP-Prefix Segment is global 300 within the SR IGP instance/topology it identifies an instruction to 301 forward the packet along the path computed using the routing 302 algorithm specified in the algorithm field, in the topology and the 303 IGP instance where it is advertised. Also referred to as Prefix 304 Segment. 306 Prefix SID: the SID of the IGP-Prefix Segment. 308 IGP-Anycast Segment: an IGP-Anycast Segment is an IGP-Prefix Segment 309 which identify an anycast prefix advertised by a set of routers. 311 Anycast-SID: the SID of the IGP-Anycast Segment. 313 IGP-Adjacency Segment: an IGP-Adjacency Segment is an IGP Segment 314 attached to a unidirectional adjacency or a set of unidirectional 315 adjacencies. By default, an IGP-Adjacency Segment is local (unless 316 explicitly advertised otherwise) to the node that advertises it. 317 Also referred to as Adjacency Segment. 319 Adj-SID: the SID of the IGP-Adjacency Segment. 321 IGP-Node Segment: an IGP-Node Segment is an IGP-Prefix Segment which 322 identifies a specific router (e.g., a loopback). Also referred to as 323 Node Segment. 325 Node-SID: the SID of the IGP-Node Segment. 327 SR Policy: an ordered list of segments. The headend of an SR Policy 328 steers packets onto the SR policy. The list of segments can be 329 specified explicitly in SR-MPLS as a stack of labels and in SRv6 as 330 an ordered list of SRv6 SID's. Alternatively, the list of segments 331 is computed based on a destination and a set of optimization 332 objective and constraints (e.g., latency, affinity, SRLG, ...). The 333 computation can be local or delegated to a PCE server. An SR policy 334 can be configured by the operator, provisioned via NETCONF or 335 provisioned via PCEP [RFC5440] . An SR policy can be used for 336 traffic-engineering, OAM or FRR reasons. 338 Segment List Depth: the number of segments of an SR policy. The 339 entity instantiating an SR Policy at a node N should be able to 340 discover the depth insertion capability of the node N. For example, 341 the PCEP SR capability advertisement described in 342 [I-D.ietf-pce-segment-routing] is one means of discovering this 343 capability. 345 Forwarding Information Base (FIB): the forwarding table of a node 347 3. Link-State IGP Segments 349 Within an SR domain, an SR-capable IGP node advertises segments for 350 its attached prefixes and adjacencies. These segments are called IGP 351 segments or IGP SIDs. They play a key role in Segment Routing and 352 use-cases as they enable the expression of any path throughout the SR 353 domain. Such a path is either expressed as a single IGP segment or a 354 list of multiple IGP segments. 356 Advertisement of IGP segments requires extensions in link-state IGP 357 protocols. These extensions are defined in 358 [I-D.ietf-isis-segment-routing-extensions] 359 [I-D.ietf-ospf-segment-routing-extensions] 360 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 362 3.1. IGP-Prefix Segment, Prefix-SID 364 An IGP-Prefix segment is an IGP segment attached to an IGP prefix. 365 An IGP-Prefix segment is global (unless explicitly advertised 366 otherwise) within the SR domain. The context for an IGP-Prefix 367 segment includes the prefix, topology, and algorithm. Multiple SIDs 368 MAY be allocated to the same prefix so long as the tuple is unique. 371 Multiple instances and topologies are defined in IS-IS and OSPF in: 372 [RFC5120], [RFC8202], [RFC6549] and [RFC4915]. 374 3.1.1. Prefix-SID Algorithm 376 Segment Routing supports the use of multiple routing algorithms i.e, 377 different constraint based shortest path calculations can be 378 supported. An algorithm identifier is included as part of a Prefix- 379 SID advertisement. 381 This document defines two algorithms: 383 o "Shortest Path": this algorithm is the default behavior. The 384 packet is forwarded along the well known ECMP-aware SPF algorithm 385 employed by the IGPs. However it is explicitly allowed for a 386 midpoint to implement another forwarding based on local policy. 387 The "Shortest Path" algorithm is in fact the default and current 388 behavior of most of the networks where local policies may override 389 the SPF decision. 391 o "Strict Shortest Path": This algorithm mandates that the packet is 392 forwarded according to ECMP-aware SPF algorithm and instructs any 393 router in the path to ignore any possible local policy overriding 394 the SPF decision. The SID advertised with "Strict Shortest Path" 395 algorithm ensures that the path the packet is going to take is the 396 expected, and not altered, SPF path. Note that Fast Reroute (FRR) 397 [RFC5714] mechanisms are still compliant with the Strict Shortest 398 Path. In other words, a packet received with a Strict-SPF SID may 399 be rerouted through a FRR mechanism. 401 An IGP-Prefix Segment identifies the path, to the related prefix, 402 computed as per the associated algorithm. A packet injected anywhere 403 within the SR domain with an active Prefix-SID is expected to be 404 forwarded along a path computed using the specified algorithm. 405 Clearly, if not all SR capable nodes in an SR Domain support a given 406 algorithm it is not possible to guarantee that the packet will follow 407 a path consistent with the associated algorithm. 409 A router MUST drop any SR traffic associated with an SR algorithm, if 410 the nexthop router has not advertised support for the SR algorithm. 412 The ingress node of an SR domain SHOULD validate that the path to a 413 prefix, advertised with a given algorithm, includes nodes all 414 supporting the advertised algorithm. If this constraint cannot be 415 met the packet SHOULD be dropped by the ingress node. Note that in 416 the special case of "Shortest Path", all nodes (SR Capable or not) 417 are assumed to support this algorithm. 419 3.1.2. SR-MPLS 421 When SR is used over the MPLS dataplane SIDs are an MPLS label or an 422 index into an MPLS label space (either SRGB or SRLB). An SRGB/SRLB 423 is advertised as an ordered set of ranges which has the following 424 properties: 426 o Each range specifies a starting label and the number of labels in 427 that range 429 o The set of ranges advertised by a given node MUST be disjoint 430 When the SID is an index, the mapping of the index to a label is 431 computed using the following algorithm: 433 r = # of advertised ranges 434 L(Ri) is the starting label of Range #i 435 N(Ri) is the number of labels in Range #i 436 X is the 0 based index 438 i = 1 439 while ((i <= r) && (X >= N(Ri)) { 440 X = X - N(Ri) 441 i = i + 1 442 } 443 if (i <= r) 444 LABEL = L(Ri) + X 445 else 446 no valid label exists for this index 448 Where possible, it is recommended that a consistent SRGB be 449 configured on all nodes in an SR Domain. This simplifies 450 troubleshooting as the same label will be associated with the same 451 prefix on all nodes. In addition, it simplifies support for anycast 452 as detailed in Section 3.3. 454 The following behaviors are associated with SR operating over the 455 MPLS dataplane: 457 o the IGP signaling extension for IGP-Prefix segment includes a flag 458 to indicate whether directly connected neighbors of the node on 459 which the prefix is attached should perform the NEXT operation or 460 the CONTINUE operation when processing the SID. This behavior is 461 equivalent to Penultimate Hop Popping (NEXT) or Ultimate Hop 462 Popping (CONTINUE) in MPLS. 464 o A Prefix-SID is allocated in the form of an MPLS label (or an 465 index in the SRGB) according to a process similar to IP address 466 allocation. Typically, the Prefix-SID is allocated by policy by 467 the operator (or NMS) and the SID very rarely changes. 469 o While SR allows to attach a local segment to an IGP prefix, it is 470 specifically assumed that when the terms "IGP-Prefix Segment" and 471 "Prefix-SID" are used, the segment is global (the SID is allocated 472 from the SRGB or as an index into the advertised SRGB). This is 473 consistent with all the described use-cases that require global 474 segments attached to IGP prefixes. 476 o The allocation process MUST NOT allocate the same Prefix-SID to 477 different IP prefixes. 479 o If a node learns a Prefix-SID having a value that falls outside 480 the locally configured SRGB range, then the node MUST NOT use the 481 Prefix-SID and SHOULD issue an error log reporting a 482 misconfiguration. 484 o If a node N advertises Prefix-SID SID-R for a prefix R that is 485 attached to N, if N specifies CONTINUE as the operation to be 486 performed by directly connected neighbors, N MUST maintain the 487 following FIB entry: 489 Incoming Active Segment: SID-R 490 Ingress Operation: NEXT 491 Egress interface: NULL 493 o A remote node M MUST maintain the following FIB entry for any 494 learned Prefix-SID SID-R attached to IP prefix R: 496 Incoming Active Segment: SID-R 497 Ingress Operation: 498 If the next-hop of R is the originator of R 499 and instructed to remove the active segment: NEXT 500 Else: CONTINUE 501 Egress interface: the interface towards the next-hop along the 502 path computed using the algorithm advertised with 503 the SID toward prefix R. 505 3.1.3. SRv6 507 When SR is used over the IPv6 dataplane: 509 o A Prefix-SID is an IPv6 address.. 511 o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node 512 addresses are not SRv6 SIDs by default. 514 A node N advertising an IPv6 address R usable as a segment identifier 515 MUST maintain the following FIB entry: 517 Incoming Active Segment: R 518 Ingress Operation: NEXT 519 Egress interface: NULL 521 Independent of Segment Routing support, any remote IPv6 node will 522 maintain a plain IPv6 FIB entry for any prefix, no matter if the 523 represent a segment or not. This allows forwarding of packets to the 524 node which owns the SID even by nodes which do not support Segment 525 Routing. 527 3.2. IGP-Node Segment, Node-SID 529 An IGP Node-SID MUST NOT be associated with a prefix that is owned by 530 more than one router within the same routing domain. 532 3.3. IGP-Anycast Segment, Anycast SID 534 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 535 shortest-path forwarding towards the closest node of the anycast set. 536 This is useful to express macro-engineering policies or protection 537 mechanisms. 539 An IGP-Anycast segment MUST NOT reference a particular node. 541 Within an anycast group, all routers in an SR domain MUST advertise 542 the same prefix with the same SID value. 544 3.3.1. Anycast SID in SR-MPLS 546 +--------------+ 547 | Group A | 548 |192.0.2.10/32 | 549 | SID:100 | 550 | | 551 +-----------A1---A3----------+ 552 | | | \ / | | | 553 SID:10 | | | / | | | SID:30 554 203.0.113.1/32 | | | / \ | | | 203.0.113.3/32 555 PE1------R1----------A2---A4---------R3------PE3 556 \ /| | | |\ / 557 \ / | +--------------+ | \ / 558 \ / | | \ / 559 / | | / 560 / \ | | / \ 561 / \ | +--------------+ | / \ 562 / \| | | |/ \ 563 PE2------R2----------B1---B3---------R4------PE4 564 203.0.113.2/32 | | | \ / | | | 203.0.113.4/32 565 SID:20 | | | / | | | SID:40 566 | | | / \ | | | 567 +-----------B2---B4----------+ 568 | | 569 | Group B | 570 | 192.0.2.1/32 | 571 | SID:200 | 572 +--------------+ 574 Figure 1: Transit device groups 576 The figure above describes a network example with two groups of 577 transit devices. Group A consists of devices {A1, A2, A3 and A4}. 578 They are all provisioned with the anycast address 192.0.2.10/32 and 579 the anycast SID 100. 581 Similarly, group B consists of devices {B1, B2, B3 and B4} and are 582 all provisioned with the anycast address 192.0.2.1/32, anycast SID 583 200. In the above network topology, each PE device has a path to 584 each of the groups A and B. 586 PE1 can choose a particular transit device group when sending traffic 587 to PE3 or PE4. This will be done by pushing the anycast SID of the 588 group in the stack. 590 Processing the anycast, and subsequent segments, requires special 591 care. 593 +-------------------------+ 594 | Group A | 595 | 192.0.2.10/32 | 596 | SID:100 | 597 |-------------------------| 598 | | 599 | SRGB: SRGB: | 600 SID:10 |(1000-2000) (3000-4000)| SID:30 601 PE1---+ +-------A1-------------A3-------+ +---PE3 602 \ / | | \ / | | \ / 603 \ / | | +-----+ / | | \ / 604 SRGB: \ / | | \ / | | \ / SRGB: 605 (7000-8000) R1 | | \ | | R3 (6000-7000) 606 / \ | | / \ | | / \ 607 / \ | | +-----+ \ | | / \ 608 / \ | | / \ | | / \ 609 PE2---+ +-------A2-------------A4-------+ +---PE4 610 SID:20 | SRGB: SRGB: | SID:40 611 |(2000-3000) (4000-5000)| 612 | | 613 +-------------------------+ 615 Figure 2: Transit paths via anycast group A 617 Considering an MPLS deployment, in the above topology, if device PE1 618 (or PE2) requires to send a packet to the device PE3 (or PE4) it 619 needs to encapsulate the packet in an MPLS payload with the following 620 stack of labels. 622 o Label allocated by R1 for anycast SID 100 (outer label). 624 o Label allocated by the nearest router in group A for SID 30 (for 625 destination PE3). 627 While the first label is easy to compute, in this case since there 628 are more than one topologically nearest devices (A1 and A2), unless 629 A1 and A2 allocated the same label value to the same prefix, 630 determining the second label is impossible. Devices A1 and A2 may be 631 devices from different hardware vendors. If both don't allocate the 632 same label value for SID 30, it is impossible to use the anycast 633 group "A" as a transit anycast group towards PE3. Hence, PE1 (or 634 PE2) cannot compute an appropriate label stack to steer the packet 635 exclusively through the group A devices. Same holds true for devices 636 PE3 and PE4 when trying to send a packet to PE1 or PE2. 638 To ease the use of anycast segment in a short term, it is recommended 639 to configure the same SRGB on all nodes of a particular anycast 640 group. Using this method, as mentioned above, computation of the 641 label following the anycast segment is straightforward. 643 Using anycast segment without configuring the same SRGB on nodes 644 belonging to the same device group may lead to misrouting (in an MPLS 645 VPN deployment, some traffic may leak between VPNs). 647 3.4. IGP-Adjacency Segment, Adj-SID 649 The adjacency is formed by the local node (i.e., the node advertising 650 the adjacency in the IGP) and the remote node (i.e., the other end of 651 the adjacency). The local node MUST be an IGP node. The remote node 652 may be an adjacent IGP neighbor or a non-adjacent neighbor (e.g.: a 653 Forwarding Adjacency, [RFC4206]). 655 A packet injected anywhere within the SR domain with a segment list 656 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 657 attached by node N to its adjacency over link L, will be forwarded 658 along the shortest-path to N and then be switched by N, without any 659 IP shortest-path consideration, towards link L. If the Adj-SID 660 identifies a set of adjacencies, then the node N load-balances the 661 traffic among the various members of the set. 663 Similarly, when using a global Adj-SID, a packet injected anywhere 664 within the SR domain with a segment list {SNL}, where SNL is a global 665 Adj-SID attached by node N to its adjacency over link L, will be 666 forwarded along the shortest-path to N and then be switched by N, 667 without any IP shortest-path consideration, towards link L. If the 668 Adj-SID identifies a set of adjacencies, then the node N does load- 669 balance the traffic among the various members of the set. The use of 670 global Adj-SID allows to reduce the size of the segment list when 671 expressing a path at the cost of additional state (i.e.: the global 672 Adj-SID will be inserted by all routers within the area in their 673 forwarding table). 675 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 676 packet from a node towards a defined interface or set of interfaces. 677 This is key to theoretically prove that any path can be expressed as 678 a list of segments. 680 The encodings of the Adj-SID include a set of flags supporting the 681 following functionalities: 683 o Eligible for Protection (e.g.: using IPFRR or MPLS-FRR) 685 o Indication whether the Adj-SID has local or global scope. Default 686 scope SHOULD be Local. 688 A weight (as described below) is also associated with the Adj-SID 689 advertisement. 691 A node SHOULD allocate one Adj-SID for each of its adjacencies. 693 A node MAY allocate multiple Adj-SIDs for the same adjacency. An 694 example is to support an Adj-SID which is eligible for protection and 695 an Adj-SID which is NOT eligible for protection. 697 A node MAY associate the same Adj-SID to multiple adjacencies. 699 In order to be able to advertise in the IGP all the Adj-SIDs 700 representing the IGP adjacencies between two nodes, parallel 701 adjacency suppression MUST NOT be performed by the IGP. 703 When a node binds an Adj-SID to a local data-link L, the node MUST 704 install the following FIB entry: 706 Incoming Active Segment: V 707 Ingress Operation: NEXT 708 Egress Interface: L 710 The Adj-SID implies, from the router advertising it, the forwarding 711 of the packet through the adjacency(ies) identified by the Adj-SID, 712 regardless of its IGP/SPF cost. In other words, the use of adjacency 713 segments overrides the routing decision made by the SPF algorithm. 715 3.4.1. Parallel Adjacencies 717 Adj-SIDs can be used in order to represent a set of parallel 718 interfaces between two adjacent routers. 720 A node MUST install a FIB entry for any locally originated adjacency 721 segment (Adj-SID) of value W attached to a set of links B with: 723 Incoming Active Segment: W 724 Ingress Operation: NEXT 725 Egress interface: load-balance between any data-link within set B 727 When parallel adjacencies are used and associated to the same Adj- 728 SID, and in order to optimize the load balancing function, a "weight" 729 factor can be associated to the Adj-SID advertised with each 730 adjacency. The weight tells the ingress (or an SDN/orchestration 731 system) about the load-balancing factor over the parallel 732 adjacencies. As shown in Figure 3, A and B are connected through two 733 parallel adjacencies 735 link-1 736 +--------+ 737 | | 738 S---A B---C 739 | | 740 +--------+ 741 link-2 743 Figure 3: Parallel Links and Adj-SIDs 745 Node A advertises following Adj-SIDs and weights: 747 o Link-1: Adj-SID 1000, weight: 1 749 o Link-2: Adj-SID 1000, weight: 2 751 Node S receives the advertisements of the parallel adjacencies and 752 understands that by using Adj-SID 1000 node A will load-balance the 753 traffic across the parallel links (link-1 and link-2) according to a 754 1:2 ratio i.e., twice as many packets will flow over Link-2 as 755 compared to Link-1. 757 3.4.2. LAN Adjacency Segments 759 In LAN subnetworks, link-state protocols define the concept of 760 Designated Router (DR, in OSPF) or Designated Intermediate System 761 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 762 that describe the LAN topology in a special routing update (OSPF 763 Type2 LSA or IS-IS Pseudonode LSP). 765 The difficulty with LANs is that each router only advertises its 766 connectivity to the DR/DIS and not to each of the individual nodes in 767 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 768 are necessary in order for each router in the LAN to advertise an 769 Adj-SID associated to each neighbor in the LAN. These extensions are 770 defined in IGP SR extensions documents. 772 3.5. Inter-Area Considerations 774 In the following example diagram it is assumed that the all areas are 775 part of a single SR Domain. 777 The example here below assumes the IPv6 control plane with the MPLS 778 dataplane. 780 ! ! 781 ! ! 782 B------C-----F----G-----K 783 / | | | 784 S---A/ | | | 785 \ | | | 786 \D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150) 787 ! ! 788 Area-1 ! Backbone ! Area 2 789 ! area ! 791 Figure 4: Inter-Area Topology Example 793 In area 2, node Z allocates Node-SID 150 to his local IPv6 prefix 794 2001:DB8::2:1/128. 796 ABRs G and J will propagate the prefix and its SIDs into the backbone 797 area by creating a new instance of the prefix according to normal 798 inter-area/level IGP propagation rules. 800 Nodes C and I will apply the same behavior when leaking prefixes from 801 the backbone area down to area 1. Therefore, node S will see prefix 802 2001:DB8::2:1/128 with Prefix-SID 150 and advertised by nodes C and 803 I. 805 It therefore results that a Prefix-SID remains attached to its 806 related IGP Prefix through the inter-area process. 808 When node S sends traffic to 2001:DB8::2:1/128, it pushes Node- 809 SID(150) as active segment and forward it to A. 811 When packet arrives at ABR I (or C), the ABR forwards the packet 812 according to the active segment (Node-SID(150)). Forwarding 813 continues across area borders, using the same Node-SID(150), until 814 the packet reaches its destination. 816 4. BGP Peering Segments 818 BGP segments may be allocated and distributed by BGP. 820 4.1. BGP Prefix Segment 822 A BGP-Prefix segment is a BGP segment attached to a BGP prefix. 824 A BGP-Prefix segment is global (unless explicitly advertised 825 otherwise) within the SR domain. 827 The BGP Prefix SID is the BGP equivalent to the IGP Prefix Segment. 829 A likely use-case for the BGP Prefix Segment is an IGP-free hyper- 830 scale spine-leaf topology where connectivity is learned solely via 831 BGP [RFC7938] 833 4.2. BGP Peering Segments 835 In the context of BGP Egress Peer Engineering (EPE), as described in 836 [I-D.ietf-spring-segment-routing-central-epe], an EPE enabled Egress 837 PE node MAY advertise segments corresponding to its attached peers. 838 These segments are called BGP peering segments or BGP peering SIDs. 839 They enable the expression of source-routed inter-domain paths. 841 An ingress border router of an AS may compose a list of segments to 842 steer a flow along a selected path within the AS, towards a selected 843 egress border router C of the AS and through a specific peer. At 844 minimum, a BGP peering Engineering policy applied at an ingress PE 845 involves two segments: the Node SID of the chosen egress PE and then 846 the BGP peering segment for the chosen egress PE peer or peering 847 interface. 849 Three types of BGP peering segments/SIDs are defined: PeerNode SID, 850 PeerAdj SID and PeerSet SID. 852 o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At 853 the BGP node advertising it, its semantics is: 855 * SR header operation: NEXT. 857 * Next-Hop: the connected peering node to which the segment is 858 related. 860 o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the 861 BGP node advertising it, the semantic is: 863 * SR header operation: NEXT. 865 * Next-Hop: the peer connected through the interface to which the 866 segment is related. 868 o PeerSet SID. a BGP PeerSet segment/SID is a local segment. At the 869 BGP node advertising it, the semantic is: 871 * SR header operation: NEXT. 873 * Next-Hop: load-balance across any connected interface to any 874 peer in the related group. 876 A peer set could be all the connected peers from the same AS or a 877 subset of these. A group could also span across AS. The group 878 definition is a policy set by the operator. 880 The BGP extensions necessary in order to signal these BGP peering 881 segments are defined in [I-D.ietf-idr-bgpls-segment-routing-epe] 883 5. Binding Segment 885 An SR Policy is bound to a so-called Binding SID (BSID). Any packets 886 received with active segment = BSID are steered onto the bound SR 887 Policy. 889 A BSID may either be a local or a global SID. If local, a BSID 890 SHOULD be allocated from the SRLB. If global, a BSID MUST be 891 allocated from the SRGB. 893 One of the possible use cases for a BSID is to overcome a Segment 894 List Depth limitation on a given node by requiring that node only to 895 impose a BSID which could be SWAPPED on downstream nodes with a set 896 of SIDs associated with an SR policy. 898 5.1. IGP Mirroring Context Segment 900 Another use case for a Binding Segment is to provide support for an 901 IGP node to advertise its ability to process traffic originally 902 destined to another IGP node, called the Mirrored node and identified 903 by an IP address or a Node-SID, provided that a "Mirroring Context" 904 segment be inserted in the segment list prior to any service segment 905 local to the mirrored node. 907 When a given node B wants to provide egress node A protection, it 908 advertises a segment identifying node's A context. Such segment is 909 called "Mirror Context Segment" and identified by the Mirror SID. 911 The Mirror SID is advertised using the binding segment defined in SR 912 IGP protocol extensions [I-D.ietf-isis-segment-routing-extensions] . 914 In the event of a failure, a point of local repair (PLR) diverting 915 traffic from A to B does a PUSH of the Mirror SID on the protected 916 traffic. B, when receiving the traffic with the Mirror SID as the 917 active segment, uses that segment and processes underlying segments 918 in the context of A. 920 6. Multicast 922 Segment Routing is defined for unicast. The application of the 923 source-route concept to Multicast is not in the scope of this 924 document. 926 7. IANA Considerations 928 This document does not require any action from IANA. 930 8. Security Considerations 932 Segment Routing is applicable to both MPLS and IPv6 data planes. 934 Segment Routing adds some meta-data (instructions) on the packet, 935 with the list of forwarding path elements (e.g.: nodes, links, 936 services, etc.) that the packet must traverse. It has to be noted 937 that the complete source routed path may be represented by a single 938 segment. This is the case of the Binding SID. 940 8.1. SR-MPLS 942 When applied to the MPLS data plane, Segment Routing does not 943 introduce any new behavior or any change in the way MPLS data plane 944 works. Therefore, from a security standpoint, this document does not 945 define any additional mechanism in the MPLS data plane. 947 SR allows the expression of a source routed path using a single 948 segment (the Binding SID). Compared to RSVP-TE which also provides 949 explicit routing capability, there are no fundamental differences in 950 term of information provided. Both RSVP-TE and Segment Routing may 951 express a source routed path using a single segment. 953 When a path is expressed using a single label, the syntax of the 954 meta-data is equivalent between RSVP-TE [RFC3209] and SR. 956 When a source routed path is expressed with a list of segments 957 additional meta-data is added to the packet consisting of the source 958 routed path the packet must follow expressed as a segment list. 960 When a path is expressed using a label stack, if one has access to 961 the meaning (i.e.: the Forwarding Equivalence Class) of the labels, 962 one has the knowledge of the explicit path. For the MPLS data plane, 963 as no data plane modification is required, there is no fundamental 964 change of capability. Yet, the occurrence of label stacking will 965 increase. 967 From a network protection standpoint, there is an assumed trust model 968 such that any node imposing a label stack on a packet is assumed to 969 be allowed to do so. This is a significant change compared to plain 970 IP offering shortest path routing but not fundamentally different 971 compared to existing techniques providing explicit routing capability 972 such as RSVP-TE. By default, the explicit routing information MUST 973 NOT be leaked through the boundaries of the administered domain. 974 Segment Routing extensions that have been defined in various 975 protocols, leverage the security mechanisms of these protocols such 976 as encryption, authentication, filtering, etc. 978 In the general case, a segment routing capable router accepts and 979 install labels, only if these labels have been previously advertised 980 by a trusted source. The received information is validated using 981 existing control plane protocols providing authentication and 982 security mechanisms. Segment Routing does not define any additional 983 security mechanism in existing control plane protocols. 985 Segment Routing does not introduce signaling between the source and 986 the mid points of a source routed path. With SR, the source routed 987 path is computed using SIDs previously advertised in the IP control 988 plane. Therefore, in addition to filtering and controlled 989 advertisement of SIDs at the boundaries of the SR domain, filtering 990 in the data plane is also required. Filtering MUST be performed on 991 the forwarding plane at the boundaries of the SR domain and may 992 require looking at multiple labels/instruction. 994 For the MPLS data plane, there are no new requirement as the existing 995 MPLS architecture already allows such source routing by stacking 996 multiple labels. And for security protection, [RFC4381] and 997 [RFC5920] already call for the filtering of MPLS packets on trust 998 boundaries. 1000 8.2. SRv6 1002 When applied to the IPv6 data plane, Segment Routing does introduce 1003 the Segment Routing Header (SRH, 1004 [I-D.ietf-6man-segment-routing-header]) which is a type of Routing 1005 Extension header as defined in [RFC8200]. 1007 The SRH adds some meta-data on the IPv6 packet, with the list of 1008 forwarding path elements (e.g.: nodes, links, services, etc.) that 1009 the packet must traverse and that are represented by IPv6 addresses. 1011 A complete source routed path may be encoded in the packet using a 1012 single segment (single IPv6 address). 1014 From a network protection standpoint, there is an assumed trust model 1015 such that any node adding an SRH to the packet is assumed to be 1016 allowed to do so. Therefore, by default, the explicit routing 1017 information MUST NOT be leaked through the boundaries of the 1018 administered domain. Segment Routing extensions that have been 1019 defined in various protocols, leverage the security mechanisms of 1020 these protocols such as encryption, authentication, filtering, etc. 1022 In the general case, an SR IPv6 router accepts and install segments 1023 identifiers (in the form of IPv6 addresses), only if these SIDs are 1024 advertised by a trusted source. The received information is 1025 validated using existing control plane protocols providing 1026 authentication and security mechanisms. Segment Routing does not 1027 define any additional security mechanism in existing control plane 1028 protocols. 1030 In addition, SR domain boundary routers, by default, MUST apply data 1031 plane filters so to only accept packets whose DA and SRH (if any) 1032 contain addresses previously advertised as SIDs. 1034 There are a number of security concerns with source routing at the 1035 IPv6 data plane [RFC5095]. The new IPv6-based segment routing header 1036 is defined in [I-D.ietf-6man-segment-routing-header]. This document 1037 also discusses the above security concerns. 1039 9. Manageability Considerations 1041 In SR enabled networks, the path the packet takes is encoded in the 1042 header. As the path is not signaled through a protocol, OAM 1043 mechanisms are necessary in order for the network operator to 1044 validate the effectiveness of a path as well as to check and monitor 1045 its liveness and performance. However, it has to be noted that SR 1046 allows to reduce substantially the number of states in transit nodes 1047 and hence the number of elements that a transit node has to manage is 1048 smaller. 1050 SR OAM use cases and requirements for the MPLS data plane are defined 1051 in [I-D.ietf-spring-oam-usecase] and 1052 [I-D.ietf-spring-sr-oam-requirement]. SR OAM procedures for the MPLS 1053 data plane are defined in [I-D.ietf-mpls-spring-lsp-ping]. 1055 SR routers receive advertisements of SIDs (index, label or IPv6 1056 address) from the different routing protocols being extended for SR. 1057 Each of these protocols have monitoring and troubleshooting 1058 mechanisms to provide operation and management functions for IP 1059 addresses that MUST be extended in order to include troubleshooting 1060 and monitoring functions of the SID. 1062 SR architecture introduces the usage of global segments. Each global 1063 segment must be bound to a unique index or address within an SR 1064 domain. The management of the allocation of such index or address by 1065 the operator is critical for the network behavior to avoid situations 1066 like mis-routing. In addition to the allocation policy/tooling that 1067 the operator will have in place, an implementation SHOULD protect the 1068 network in case of conflict detection by providing a deterministic 1069 resolution approach. 1071 When a path is expressed using a label stack, the occurrence of label 1072 stacking will increase. A node may want to signal in the control 1073 plane its ability in terms of size of the label stack it can support. 1075 A YANG data model [RFC6020] for segment routing configuration and 1076 operations has been defined in [I-D.ietf-spring-sr-yang]. 1078 When Segment Routing is applied to the IPv6 data plane, segments are 1079 identified through IPv6 addresses. The allocation, management and 1080 troubleshooting of segment identifiers is no different than the 1081 existing mechanisms applied to the allocation and management of IPv6 1082 addresses. 1084 The DA of the packet gives the active segment address. The segment 1085 list in the SRH gives the entire path of the packet. The validation 1086 of the source routed path is done through inspection of DA and SRH 1087 present in the packet header matched to the equivalent routing table 1088 entries. 1090 In the context of SR over the IPv6 data plane, the source routed path 1091 is encoded in the SRH as described in 1092 [I-D.ietf-6man-segment-routing-header]. The SR IPv6 source routed 1093 path is instantiated into the SRH as a list of IPv6 address where the 1094 active segment is in the Destination Address (DA) field of the IPv6 1095 packet header. Typically, by inspecting in any node the packet 1096 header, it is possible to derive the source routed path it belongs 1097 to. Similar to the context of SR over MPLS data plane, an 1098 implementation may originate path control and monitoring packets 1099 where the source routed path is inserted in the SRH and where each 1100 segment of the path inserts in the packet the relevant data in order 1101 to measure the end to end path and performance. 1103 10. Contributors 1105 The following people have substantially contributed to the definition 1106 of the Segment Routing architecture and to the editing of this 1107 document: 1109 Ahmed Bashandy 1110 Cisco Systems, Inc. 1111 Email: bashandy@cisco.com 1113 Martin Horneffer 1114 Deutsche Telekom 1115 Email: Martin.Horneffer@telekom.de 1117 Wim Henderickx 1118 Nokia 1119 Email: wim.henderickx@nokia.com 1121 Jeff Tantsura 1122 Email: jefftant@gmail.com 1124 Edward Crabbe 1125 Email: edward.crabbe@gmail.com 1127 Igor Milojevic 1128 Email: milojevicigor@gmail.com 1130 Saku Ytti 1131 TDC 1132 Email: saku@ytti.fi 1134 11. Acknowledgements 1136 We would like to thank Dave Ward, Peter Psenak, Dan Frost, Stewart 1137 Bryant, Pierre Francois, Thomas Telkamp, Ruediger Geib, Hannes 1138 Gredler, Pushpasis Sarkar, Eric Rosen, Chris Bowers and Alvaro Retana 1139 for their comments and review of this document. 1141 12. References 1143 12.1. Normative References 1145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1146 Requirement Levels", BCP 14, RFC 2119, 1147 DOI 10.17487/RFC2119, March 1997, 1148 . 1150 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1151 Label Switching Architecture", RFC 3031, 1152 DOI 10.17487/RFC3031, January 2001, 1153 . 1155 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1156 (IPv6) Specification", STD 86, RFC 8200, 1157 DOI 10.17487/RFC8200, July 2017, 1158 . 1160 12.2. Informative References 1162 [I-D.ietf-6man-segment-routing-header] 1163 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 1164 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1165 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 1166 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 1167 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1168 segment-routing-header-07 (work in progress), July 2017. 1170 [I-D.ietf-idr-bgpls-segment-routing-epe] 1171 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 1172 Dong, "BGP-LS extensions for Segment Routing BGP Egress 1173 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 1174 epe-13 (work in progress), June 2017. 1176 [I-D.ietf-isis-segment-routing-extensions] 1177 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1178 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 1179 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1180 segment-routing-extensions-13 (work in progress), June 1181 2017. 1183 [I-D.ietf-mpls-spring-lsp-ping] 1184 Kumar, N., Pignataro, C., Swallow, G., Akiya, N., Kini, 1185 S., and M. Chen, "Label Switched Path (LSP) Ping/ 1186 Traceroute for Segment Routing IGP Prefix and Adjacency 1187 SIDs with MPLS Data-plane", draft-ietf-mpls-spring-lsp- 1188 ping-13 (work in progress), October 2017. 1190 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1191 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1192 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1193 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1194 segment-routing-extensions-10 (work in progress), 1195 September 2017. 1197 [I-D.ietf-ospf-segment-routing-extensions] 1198 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1199 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1200 Extensions for Segment Routing", draft-ietf-ospf-segment- 1201 routing-extensions-21 (work in progress), October 2017. 1203 [I-D.ietf-pce-segment-routing] 1204 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1205 and J. Hardwick, "PCEP Extensions for Segment Routing", 1206 draft-ietf-pce-segment-routing-10 (work in progress), 1207 October 2017. 1209 [I-D.ietf-spring-oam-usecase] 1210 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A 1211 Scalable and Topology-Aware MPLS Dataplane Monitoring 1212 System", draft-ietf-spring-oam-usecase-09 (work in 1213 progress), July 2017. 1215 [I-D.ietf-spring-resiliency-use-cases] 1216 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 1217 "Resiliency use cases in SPRING networks", draft-ietf- 1218 spring-resiliency-use-cases-11 (work in progress), May 1219 2017. 1221 [I-D.ietf-spring-segment-routing-central-epe] 1222 Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev, 1223 "Segment Routing Centralized BGP Egress Peer Engineering", 1224 draft-ietf-spring-segment-routing-central-epe-06 (work in 1225 progress), June 2017. 1227 [I-D.ietf-spring-segment-routing-mpls] 1228 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1229 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1230 data plane", draft-ietf-spring-segment-routing-mpls-10 1231 (work in progress), June 2017. 1233 [I-D.ietf-spring-sr-oam-requirement] 1234 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 1235 and S. Litkowski, "OAM Requirements for Segment Routing 1236 Network", draft-ietf-spring-sr-oam-requirement-03 (work in 1237 progress), January 2017. 1239 [I-D.ietf-spring-sr-yang] 1240 Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG 1241 Data Model for Segment Routing", draft-ietf-spring-sr- 1242 yang-07 (work in progress), July 2017. 1244 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1245 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1246 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1247 . 1249 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1250 Hierarchy with Generalized Multi-Protocol Label Switching 1251 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1252 DOI 10.17487/RFC4206, October 2005, 1253 . 1255 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1256 Virtual Private Networks (VPNs)", RFC 4381, 1257 DOI 10.17487/RFC4381, February 2006, 1258 . 1260 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1261 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1262 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1263 . 1265 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1266 of Type 0 Routing Headers in IPv6", RFC 5095, 1267 DOI 10.17487/RFC5095, December 2007, 1268 . 1270 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1271 Topology (MT) Routing in Intermediate System to 1272 Intermediate Systems (IS-ISs)", RFC 5120, 1273 DOI 10.17487/RFC5120, February 2008, 1274 . 1276 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1277 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1278 DOI 10.17487/RFC5440, March 2009, 1279 . 1281 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 1282 RFC 5714, DOI 10.17487/RFC5714, January 2010, 1283 . 1285 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1286 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1287 . 1289 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1290 the Network Configuration Protocol (NETCONF)", RFC 6020, 1291 DOI 10.17487/RFC6020, October 2010, 1292 . 1294 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1295 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1296 March 2012, . 1298 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 1299 BGP for Routing in Large-Scale Data Centers", RFC 7938, 1300 DOI 10.17487/RFC7938, August 2016, 1301 . 1303 [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS 1304 Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 1305 2017, . 1307 Authors' Addresses 1309 Clarence Filsfils (editor) 1310 Cisco Systems, Inc. 1311 Brussels 1312 BE 1314 Email: cfilsfil@cisco.com 1316 Stefano Previdi (editor) 1317 Cisco Systems, Inc. 1318 Italy 1320 Email: stefano@previdi.net 1322 Les Ginsberg 1323 Cisco Systems, Inc 1325 Email: ginsberg@cisco.com 1327 Bruno Decraene 1328 Orange 1329 FR 1331 Email: bruno.decraene@orange.com 1332 Stephane Litkowski 1333 Orange 1334 FR 1336 Email: stephane.litkowski@orange.com 1338 Rob Shakir 1339 Google, Inc. 1340 1600 Amphitheatre Parkway 1341 Mountain View, CA 94043 1342 US 1344 Email: robjs@google.com