idnits 2.17.1 draft-ietf-spring-segment-routing-12.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 (June 20, 2017) is 2495 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-06 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-13) exists of draft-ietf-mpls-spring-lsp-ping-03 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-09 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-16 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-09 == Outdated reference: A later version (-05) exists of draft-ietf-spring-conflict-resolution-04 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-11 == Outdated reference: A later version (-10) exists of draft-ietf-spring-oam-usecase-06 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-11 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-09 == Outdated reference: A later version (-30) exists of draft-ietf-spring-sr-yang-06 -- Obsolete informational reference (is this intentional?): RFC 6822 (Obsoleted by RFC 8202) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). 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: December 22, 2017 B. Decraene 6 S. Litkowski 7 Orange 8 R. Shakir 9 Google, Inc. 10 June 20, 2017 12 Segment Routing Architecture 13 draft-ietf-spring-segment-routing-12 15 Abstract 17 Segment Routing (SR) leverages the source routing paradigm. A node 18 steers a packet through an ordered list of instructions, called 19 segments. A segment can represent any instruction, topological or 20 service-based. A segment can have a semantic local to an SR node or 21 global within an SR domain. SR allows to enforce a flow through any 22 topological path and service chain while maintaining per-flow state 23 only at the ingress nodes to the SR domain. 25 Segment Routing can be directly applied to the MPLS architecture with 26 no change on the forwarding plane. A segment is encoded as an MPLS 27 label. An ordered list of segments is encoded as a stack of labels. 28 The segment to process is on the top of the stack. Upon completion 29 of a segment, the related label is popped from the stack. 31 Segment Routing can be applied to the IPv6 architecture, with a new 32 type of routing header. A segment is encoded as an IPv6 address. An 33 ordered list of segments is encoded as an ordered list of IPv6 34 addresses in the routing header. The active segment is indicated by 35 the Destination Address of the packet. The next active segment is 36 indicated by a pointer in the new routing header. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on December 22, 2017. 61 Copyright Notice 63 Copyright (c) 2017 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 7 82 3.1. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 83 3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 7 84 3.1.2. MPLS Dataplane . . . . . . . . . . . . . . . . . . . 8 85 3.1.3. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . 9 86 3.2. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 10 87 3.3. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 10 88 3.4. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 13 89 3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 14 90 3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 15 91 3.5. Binding Segment . . . . . . . . . . . . . . . . . . . . . 15 92 3.5.1. Mapping Server . . . . . . . . . . . . . . . . . . . 15 93 3.5.2. Tunnel Head-end . . . . . . . . . . . . . . . . . . . 16 94 3.6. Inter-Area Considerations . . . . . . . . . . . . . . . . 16 95 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 17 96 5. IGP Mirroring Context Segment . . . . . . . . . . . . . . . 18 97 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 100 8.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 19 101 8.2. IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 20 102 9. Manageability Considerations . . . . . . . . . . . . . . . . 21 103 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 104 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 105 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 106 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 107 12.2. Informative References . . . . . . . . . . . . . . . . . 24 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 110 1. Introduction 112 With Segment Routing (SR), a node steers a packet through an ordered 113 list of instructions, called segments. A segment can represent any 114 instruction, topological or service-based. A segment can have a 115 semantic local to an SR node or global within an SR domain. SR 116 allows to enforce a flow through any path and service chain while 117 maintaining per-flow state only at the ingress node of the SR domain. 119 Segment Routing can be directly applied to the MPLS architecture 120 ([RFC3031]) with no change on the forwarding plane. A segment is 121 encoded as an MPLS label. An ordered list of segments is encoded as 122 a stack of labels. The active segment is on the top of the stack. A 123 completed segment is popped off the stack. The addition of a segment 124 is performed with a push. 126 In the Segment Routing MPLS instantiation, a segment could be of 127 several types: 129 o an IGP segment, 131 o a BGP Peering segment, 133 o an LDP LSP segment, 135 o an RSVP-TE LSP segment, 137 o a BGP LSP segment. 139 The first two (IGP and BGP peering segments) types of segments are 140 defined in this document. The use of the last three types of 141 segments is illustrated in [I-D.ietf-spring-segment-routing-mpls]. 143 Segment Routing can be applied to the IPv6 architecture ([RFC2460]), 144 with a new type of routing header. A segment is encoded as an IPv6 145 address. An ordered list of segments is encoded as an ordered list 146 of IPv6 addresses in the routing header. The active segment is 147 indicated by the Destination Address of the packet. Upon completion 148 of a segment, a pointer in the new routing header is incremented and 149 indicates the next segment. 151 Numerous use-cases illustrate the benefits of source routing either 152 for FRR, OAM or Traffic Engineering reasons 153 ([I-D.ietf-spring-oam-usecase]). 155 This document defines a set of instructions (called segments) that 156 are required to fulfill the described use-cases. These segments can 157 either be used in isolation (one single segment defines the source 158 route of the packet) or in combination (these segments are part of an 159 ordered list of segments that define the source route of the packet). 161 1.1. Companion Documents 163 This document defines the SR architecture, its routing model, the 164 IGP-based segments, the BGP-based segments and the service segments. 166 The problem statement and requirements are described in [RFC7855]. 168 Use cases are described in .[I-D.ietf-spring-ipv6-use-cases], 169 [I-D.ietf-spring-resiliency-use-cases] and 170 [I-D.ietf-spring-oam-usecase]. 172 2. Terminology 174 Segment: an instruction a node executes on the incoming packet (e.g.: 175 forward packet according to shortest path to destination, or, forward 176 packet through a specific interface, or, deliver the packet to a 177 given application/service instance). 179 SID: a segment identifier. Examples of SIDs are: an MPLS label, an 180 index value in an MPLS label space, an IPv6 address. Other types of 181 SIDs can be defined in the future. 183 Segment List: ordered list of SIDs encoding the ordered set of 184 instructions to be applied to the packet as it traverses the SR 185 domain. For example, the topological and service source route of the 186 packet. The Segment List is instantiated as a stack of labels in the 187 MPLS architecture and as an ordered list of IPv6 addresses in the 188 IPv6 architecture. 190 Segment Routing Domain (SR Domain): the set of nodes participating 191 into the source based routing model. These nodes may be connected to 192 the same physical infrastructure (e.g.: a Service Provider's 193 network). They may as well be remotely connected to each other 194 (e.g.: an enterprise VPN or an overlay). Note that an SR domain may 195 also be confined within an IGP instance, in which case it is named 196 SR-IGP Domain. 198 Active Segment: the segment that MUST be used by the receiving router 199 to process the packet. In the MPLS dataplane it is the top label. 200 In the IPv6 dataplane it is the destination address of a packet 201 having the Segment Routing Header (SRH) as defined in 202 [I-D.ietf-6man-segment-routing-header]. 204 PUSH: the instruction consisting of the insertion of a segment at the 205 top of the segment list. In the MPLS dataplane the top of the 206 segment list is the topmost (outer) label of the label stack. In the 207 IPv6 dataplane, the top of the segment list is represented by the 208 first segment in the Segment Routing Header as defined in 209 [I-D.ietf-6man-segment-routing-header]. 211 NEXT: when the active segment is completed, NEXT is the instruction 212 consisting of the inspection of the next segment. The next segment 213 becomes active. 215 CONTINUE: the active segment is not completed and hence remains 216 active. The CONTINUE instruction is implemented as the SWAP 217 instruction in the MPLS dataplane. In IPv6, this is the plain IPv6 218 forwarding action of a regular IPv6 packet according to its 219 Destination Address. 221 SR Global Block (SRGB): local property of an SR node. In the MPLS 222 architecture, SRGB is the set of local labels reserved for global 223 segments. Using the same SRGB on all nodes within the SR domain ease 224 operations and troubleshooting and is expected to be a deployment 225 guideline. In the IPv6 architecture, the equivalent of the SRGB is 226 in fact the set of addresses used as global segments. Since there 227 are no restrictions on which IPv6 address can be used, the concept of 228 the SRGB includes all IPv6 global address space used within the SR 229 domain. 231 Global Segment: the related instruction is supported by all the SR- 232 capable nodes in the domain. In the MPLS architecture, a global 233 segment is represented by a globally-unique index. The related local 234 label at a given node N is found by adding the globally-unique index 235 to the SRGB of node N. In the IPv6 architecture, a global segment is 236 a globally-unique IPv6 address. 238 Local Segment: the related instruction is supported only by the node 239 originating it. In the MPLS architecture, this is a local label 240 outside the SRGB. In the IPv6 architecture, this can be any IPv6 241 address whose reachability is not advertised in any routing protocol 242 (hence, the segment is known only by the local node). 244 IGP Segment: the generic name for a segment attached to a piece of 245 information advertised by a link-state IGP, e.g. an IGP prefix or an 246 IGP adjacency. 248 IGP-Prefix Segment: an IGP-Prefix Segment is an IGP Segment 249 representing an IGP prefix. An IGP-Prefix Segment is global (unless 250 explicitly advertised otherwise) within the SR IGP instance/topology 251 and identifies an instruction to forward the packet along the path 252 computed using the routing algorithm specified in the algorithm 253 field, in the topology and the IGP instance where it is advertised. 254 Also referred to as Prefix Segment. 256 Prefix SID: the SID of the IGP-Prefix Segment. 258 IGP-Anycast Segment: an IGP-Anycast Segment is an IGP-Prefix Segment 259 which identify an anycast prefix advertised by a set of routers. 261 Anycast-SID: the SID of the IGP-Anycast Segment. 263 IGP-Adjacency Segment: an IGP-Adjacency Segment is an IGP Segment 264 attached to a unidirectional adjacency or a set of unidirectional 265 adjacencies. By default, an IGP-Adjacency Segment is local (unless 266 explicitly advertised otherwise) to the node that advertises it. 267 Also referred to as Adjacency Segment. 269 Adj-SID: the SID of the IGP-Adjacency Segment. 271 IGP-Node Segment: an IGP-Node Segment is an IGP-Prefix Segment which 272 identifies a specific router (e.g., a loopback). Also referred to as 273 Node Segment. 275 Node-SID: the SID of the IGP-Node Segment. 277 Note that for all of the above, the SID is often used to refer to the 278 Segment itself. For example, Prefix-SID is sometimes used to refer 279 to Prefix Segment. 281 SR Tunnel: a list of segments to be pushed on the packets directed on 282 the tunnel. The list of segments can be specified explicitly or 283 implicitly via a set of abstract constraints (latency, affinity, 284 SRLG, ...). In the latter case, a constraint-based path computation 285 is used to determine the list of segments associated with the tunnel. 286 The computation can be local or delegated to a PCE server. An SR 287 tunnel can be configured by the operator, provisioned via netconf or 288 provisioned via PCEP. An SR tunnel can be used for traffic- 289 engineering, OAM or FRR reasons. 291 Segment List Depth: the number of segments of an SR tunnel. The 292 entity instantiating an SR Tunnel at a node N should be able to 293 discover the depth insertion capability of the node N. The PCEP 294 discovery capability is described in [I-D.ietf-pce-segment-routing]. 296 3. Link-State IGP Segments 298 Within a link-state IGP domain, an SR-capable IGP node advertises 299 segments for its attached prefixes and adjacencies. These segments 300 are called IGP segments or IGP SIDs. They play a key role in Segment 301 Routing and use-cases as they enable the expression of any path 302 throughout the IGP domain. Such a path is either expressed as a 303 single IGP segment or a list of multiple IGP segments. 305 IGP segments require extensions in link-state IGP protocols. IGP 306 extensions are required in order to advertise the IGP segments. 308 3.1. IGP-Prefix Segment, Prefix-SID 310 An IGP-Prefix segment is an IGP segment attached to an IGP prefix. 311 An IGP-Prefix segment is global (unless explicitly advertised 312 otherwise) within the SR/IGP domain. 314 3.1.1. Prefix-SID Algorithm 316 The IGP protocol extensions for Segment Routing define the Prefix-SID 317 advertisement which includes a set of flags and the algorithm field. 318 The algorithm field has the purpose of associating a given Prefix-SID 319 to a routing algorithm. 321 In the context of an instance and a topology, multiple Prefix-SID's 322 MAY be allocated to the same IGP Prefix as long as the algorithm 323 value is different in each one. 325 Multiple instances and topologies are defined in IS-IS and OSPF in: 326 [RFC5120], [RFC6822], [RFC6549] and [RFC4915]. 328 Initially, two "algorithms" have been defined: 330 o "Shortest Path": this algorithm is the default behavior. The 331 packet is forwarded along the well known ECMP-aware SPF algorithm 332 however it is explicitly allowed for a midpoint to implement 333 another forwarding based on local policy. The "Shortest Path" 334 algorithm is in fact the default and current behavior of most of 335 the networks where local policies may override the SPF decision. 337 o "Strict Shortest Path": This algorithm mandates that the packet is 338 forwarded according to ECMP-aware SPF algorithm and instruct any 339 router in the path to ignore any possible local policy overriding 340 SPF decision. The SID advertised with "Strict Shortest Path" 341 algorithm ensures that the path the packet is going to take is the 342 expected, and not altered, SPF path. 344 An IGP-Prefix Segment identifies the path, to the related prefix, 345 computed as per the algorithm field. 347 A packet injected anywhere within the SR/IGP domain with an active 348 Prefix-SID will be forwarded along path computed by the algorithm 349 expressed in the algorithm field. 351 A router MUST drop any SR traffic associated with the SR algorithm to 352 the adjacent router, if the adjacent router has not advertised 353 support for such SR algorithm. 355 The ingress node of an SR domain validates that the path to a prefix, 356 advertised with a given algorithm, includes nodes all supporting the 357 advertised algorithm. As a consequence, if a node on the path does 358 not support algorithm X, the IGP-Prefix segment will be interrupted 359 and will drop packet on that node. It's the responsibility of the 360 ingress node using a segment to check that all downstream nodes 361 support the algorithm of the segment. 363 It has to be noted that Fast Reroute (FRR) mechanisms are still 364 compliant with the Strict-SPF. In other words, a packet received 365 with a Strict-SPF SID may be rerouted through a FRR mechanism. 367 Details of the two defined algorithms are defined in 368 [I-D.ietf-isis-segment-routing-extensions], 369 [I-D.ietf-ospf-segment-routing-extensions] and 370 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 372 3.1.2. MPLS Dataplane 374 When SR is used over the MPLS dataplane: 376 o the IGP signaling extension for IGP-Prefix segment includes the 377 P-Flag ([I-D.ietf-isis-segment-routing-extensions]) or the NP-Flag 378 ([I-D.ietf-ospf-segment-routing-extensions]). A Node N 379 advertising a Prefix-SID SID-R for its attached prefix R unsets 380 the P-Flag (or NP-Flag) in order to instruct its connected 381 neighbors to perform the NEXT operation while processing SID-R. 382 This behavior is equivalent to Penultimate Hop Popping in MPLS. 383 When the flag is unset, the neighbors of N MUST perform the NEXT 384 operation while processing SID-R. When the flag is set, the 385 neighbors of N MUST perform the CONTINUE operation while 386 processing SID-R. 388 o A Prefix-SID is allocated in the form of an index in the SRGB (or 389 as a local MPLS label) according to a process similar to IP 390 address allocation. Typically, the Prefix-SID is allocated by 391 policy by the operator (or NMS) and the SID very rarely changes. 393 o While SR allows to attach a local segment to an IGP prefix, we 394 specifically assume that when the terms "IGP-Prefix Segment" and 395 "Prefix-SID" are used, the segment is global (the SID is allocated 396 from the SRGB or as an index). This is consistent with all the 397 described use-cases that require global segments attached to IGP 398 prefixes. 400 o The allocation process MUST NOT allocate the same Prefix-SID to 401 different IP prefixes. 403 o If a node learns a Prefix-SID having a value that falls outside 404 the locally configured SRGB range, then the node MUST NOT use the 405 Prefix-SID and SHOULD issue an error log warning for 406 misconfiguration. 408 o If a node N advertises Prefix-SID SID-R for a prefix R that is 409 attached to N, N MUST either clear the P-Flag in the advertisement 410 of SID-R, or else maintain the following FIB entry: 412 Incoming Active Segment: SID-R 413 Ingress Operation: NEXT 414 Egress interface: NULL 416 o A remote node M MUST maintain the following FIB entry for any 417 learned Prefix-SID SID-R attached to IP prefix R: 419 Incoming Active Segment: SID-R 420 Ingress Operation: 421 If the next-hop of R is the originator of R 422 and instructed to remove the active segment: NEXT 423 Else: CONTINUE 424 Egress interface: the interface towards the next-hop along the 425 path computed using the algorithm advertised with 426 the SID toward prefix R. 428 3.1.3. IPv6 Dataplane 430 When SR is used over the IPv6 dataplane: 432 o The Prefix-SID is the prefix itself. No additional identifier is 433 needed for Segment Routing over IPv6. 435 o Any address belonging to any of the node's prefixes can be used as 436 Prefix-SIDs. 438 o An operator may want to explicitly indicate which of the node's 439 prefixes can be used as Prefix-SIDs through the setting of a flag 440 (e.g.: using the IGP prefix attribute defined in [RFC7794]) in the 441 routing protocol used for advertising the prefix. 443 o A global SID is instantiated through any globally advertised IPv6 444 address. 446 o A local SID is instantiated through a local IPv6 prefix not being 447 advertised and therefore known only by the local node. 449 A node N advertising an IPv6 address R usable as a segment identifier 450 MUST maintain the following FIB entry: 452 Incoming Active Segment: R 453 Ingress Operation: NEXT 454 Egress interface: NULL 456 Regardless Segment Routing, any remote IPv6 node will maintain a 457 plain IPv6 FIB entry for any prefix, no matter if they represent a 458 segment or not. 460 3.2. IGP-Node Segment, Node-SID 462 An IGP Node-SID MUST NOT be associated with a prefix that is owned by 463 more than one router within the same routing domain. 465 3.3. IGP-Anycast Segment, Anycast SID 467 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 468 shortest-path forwarding towards the closest node of the anycast set. 469 This is useful to express macro-engineering policies or protection 470 mechanisms. 472 An IGP-Anycast segment MUST NOT reference a particular node. 474 Within an anycast group, all routers MUST advertise the same prefix 475 with the same SID value. 477 +--------------+ 478 | Group A | 479 |192.0.2.10/32 | 480 | SID:100 | 481 | | 482 +-----------A1---A3----------+ 483 | | | \ / | | | 484 SID:10 | | | / | | | SID:30 485 203.0.113.1/32 | | | / \ | | | 203.0.113.3/32 486 PE1------R1----------A2---A4---------R3------PE3 487 \ /| | | |\ / 488 \ / | +--------------+ | \ / 489 \ / | | \ / 490 / | | / 491 / \ | | / \ 492 / \ | +--------------+ | / \ 493 / \| | | |/ \ 494 PE2------R2----------B1---B3---------R4------PE4 495 203.0.113.2/32 | | | \ / | | | 203.0.113.4/32 496 SID:20 | | | / | | | SID:40 497 | | | / \ | | | 498 +-----------B2---B4----------+ 499 | | 500 | Group B | 501 | 192.0.2.1/32 | 502 | SID:200 | 503 +--------------+ 505 Figure 1: Transit device groups 507 The figure above describes a network example with two groups of 508 transit devices. Group A consists of devices {A1, A2, A3 and A4}. 509 They are all provisioned with the anycast address 192.0.2.10/32 and 510 the anycast SID 100. 512 Similarly, group B consists of devices {B1, B2, B3 and B4} and are 513 all provisioned with the anycast address 192.0.2.1/32, anycast SID 514 200. In the above network topology, each PE device is connected to 515 two routers in each of the groups A and B. 517 PE1 can choose a particular transit device group when sending traffic 518 to PE3 or PE4. This will be done by pushing the anycast SID of the 519 group in the stack. 521 Processing the anycast, and subsequent segments, requires special 522 care. 524 Obviously, the value of the SID following the anycast SID MUST be 525 understood by all nodes advertising the same anycast segment. 527 +-------------------------+ 528 | Group A | 529 | 192.0.2.10/32 | 530 | SID:100 | 531 |-------------------------| 532 | | 533 | SRGB: SRGB: | 534 SID:10 |(1000-2000) (3000-4000)| SID:30 535 PE1---+ +-------A1-------------A3-------+ +---PE3 536 \ / | | \ / | | \ / 537 \ / | | +-----+ / | | \ / 538 SRGB: \ / | | \ / | | \ / SRGB: 539 (7000-8000) R1 | | \ | | R3 (6000-7000) 540 / \ | | / \ | | / \ 541 / \ | | +-----+ \ | | / \ 542 / \ | | / \ | | / \ 543 PE2---+ +-------A2-------------A4-------+ +---PE4 544 SID:20 | SRGB: SRGB: | SID:40 545 |(2000-3000) (4000-5000)| 546 | | 547 +-------------------------+ 549 Figure 2: Transit paths via anycast group A 551 Considering an MPLS deployment, in the above topology, if device PE1 552 (or PE2) requires to send a packet to the device PE3 (or PE4) it 553 needs to encapsulate the packet in an MPLS payload with the following 554 stack of labels. 556 o Label allocated by R1 for anycast SID 100 (outer label). 558 o Label allocated by the nearest router in group A for SID 30 (for 559 destination PE3). 561 While the first label is easy to compute, in this case since there 562 are more than one topologically nearest devices (A1 and A2), unless 563 A1 and A2 allocated the same label value to the same prefix, 564 determining the second label is impossible. Devices A1 and A2 may be 565 devices from different hardware vendors. If both don't allocate the 566 same label value for SID 30, it is impossible to use the anycast 567 group "A" as a transit anycast group towards PE3. Hence, PE1 (or 568 PE2) cannot compute an appropriate label stack to steer the packet 569 exclusively through the group A devices. Same holds true for devices 570 PE3 and PE4 when trying to send a packet to PE1 or PE2. 572 To ease the use of anycast segment in a short term, it is recommended 573 to configure the same SRGB on all nodes of a particular anycast 574 group. Using this method, as mentioned above, computation of the 575 label following the anycast segment is straightforward. 577 Using anycast segment without configuring the same SRGB on nodes 578 belonging to the same device group may lead to misrouting (in an MPLS 579 VPN deployment, some traffic may leak between VPNs). 581 3.4. IGP-Adjacency Segment, Adj-SID 583 The adjacency is formed by the local node (i.e., the node advertising 584 the adjacency in the IGP) and the remote node (i.e., the other end of 585 the adjacency). The local node MUST be an IGP node. The remote node 586 MAY be an adjacent IGP neighbor or a non-adjacent neighbor (e.g.: a 587 Forwarding Adjacency, [RFC4206]). 589 A packet injected anywhere within the SR domain with a segment list 590 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 591 attached by node N to its adjacency over link L, will be forwarded 592 along the shortest-path to N and then be switched by N, without any 593 IP shortest-path consideration, towards link L. If the Adj-SID 594 identifies a set of adjacencies, then the node N load-balances the 595 traffic among the various members of the set. 597 Similarly, when using a global Adj-SID, a packet injected anywhere 598 within the SR domain with a segment list {SNL}, where SNL is a global 599 Adj-SID attached by node N to its adjacency over link L, will be 600 forwarded along the shortest-path to N and then be switched by N, 601 without any IP shortest-path consideration, towards link L. If the 602 Adj-SID identifies a set of adjacencies, then the node N does load- 603 balance the traffic among the various members of the set. The use of 604 global Adj-SID allows to reduce the size of the segment list when 605 expressing a path at the cost of additional state (i.e.: the global 606 Adj-SID will be inserted by all routers within the area in their 607 forwarding table). 609 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 610 packet from a node towards a defined interface or set of interfaces. 611 This is key to theoretically prove that any path can be expressed as 612 a list of segments. 614 The encodings of the Adj-SID include the a set of flags among which 615 there is the B-flag. When set, the Adj-SID refers to an adjacency 616 that is eligible for protection (e.g.: using IPFRR or MPLS-FRR). 618 The encodings of the Adj-SID also include the L-flag. When set, the 619 Adj-SID has local significance. By default, the L-flag is set. 621 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 623 A node MAY allocate multiple Adj-SIDs to the same adjacency. An 624 example is where the adjacency is established over a bundle 625 interface. Each bundle member MAY have its own Adj-SID. 627 A node MAY allocate the same Adj-SID to multiple adjacencies. 629 Obviously, in order to be able to advertise in the IGP all the Adj- 630 SIDs representing the IGP adjacencies between two nodes, parallel 631 adjacency suppression MUST NOT be performed by the IGP. 633 A node MUST install a FIB entry for any Adj-SID of value V attached 634 to data-link L: 636 Incoming Active Segment: V 637 Ingress Operation: NEXT 638 Egress Interface: L 640 The Adj-SID implies, from the router advertising it, the forwarding 641 of the packet through the adjacency identified by the Adj-SID, 642 regardless its IGP/SPF cost. In other words, the use of adjacency 643 segments overrides the routing decision made by the SPF algorithm. 645 3.4.1. Parallel Adjacencies 647 Adj-SIDs can be used in order to represent a set of parallel 648 interfaces between two adjacent routers. 650 A node MUST install a FIB entry for any locally originated adjacency 651 segment (Adj-SID) of value W attached to a set of link B with: 653 Incoming Active Segment: W 654 Ingress Operation: NEXT 655 Egress interface: load-balance between any data-link within set B 657 When parallel adjacencies are used and associated to the same Adj- 658 SID, and in order to optimize the load balancing function, a "weight" 659 factor can be associated to the Adj-SID advertised with each 660 adjacency. The weight tells the ingress (or a SDN/orchestration 661 system) about the load-balancing factor over the parallel 662 adjacencies. As shown in Figure 3, A and B are connected through two 663 parallel adjacencies 664 link-1 665 +--------+ 666 | | 667 S---A B---C 668 | | 669 +--------+ 670 link-2 672 Figure 3: Parallel Links and Adj-SIDs 674 Node A advertises following Adj-SIDs and weights: 676 o Link-1: Adj-SID 1000, weight: 1 678 o Link-2: Adj-SID 1000, weight: 2 680 Node S receives the advertisements of the parallel adjacencies and 681 understands that by using Adj-SID 1000 node A will load-balance the 682 traffic across the parallel links (link-1 and link-2) according to a 683 1:2 ratio. 685 The weight value is advertised with the Adj-SID as defined in IGP SR 686 extensions documents. 688 3.4.2. LAN Adjacency Segments 690 In LAN subnetworks, link-state protocols define the concept of 691 Designated Router (DR, in OSPF) or Designated Intermediate System 692 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 693 that describe the LAN topology in a special routing update (OSPF 694 Type2 LSA or IS-IS Pseudonode LSP). 696 The difficulty with LANs is that each router only advertises its 697 connectivity to the DR/DIS and not to each other individual nodes in 698 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 699 are necessary in order for each router in the LAN to advertise an 700 Adj-SID associated to each neighbor in the LAN. These extensions are 701 defined in IGP SR extensions documents. 703 3.5. Binding Segment 705 3.5.1. Mapping Server 707 A Remote-Binding SID S advertised by the mapping server M for remote 708 prefix R attached to non-SR-capable node N signals the same 709 information as if N had advertised S as a Prefix-SID. Further 710 details are described in the SR/LDP interworking procedures 711 ([I-D.ietf-spring-segment-routing-ldp-interop]. 713 The segment allocation and SRGB Maintenance rules are the same as 714 those defined for Prefix-SID. 716 3.5.2. Tunnel Head-end 718 The segment allocation and SRGB Maintenance rules are the same as 719 those defined for Adj-SID. A tunnel attached to a head-end H acts as 720 an adjacency attached to H. 722 Note: an alternative consists of representing tunnels as forwarding- 723 adjacencies ([RFC4206]). In such case, the tunnel is presented to 724 the routing area as a routing adjacency and is considered as such by 725 all area routers. The Remote-Binding SID is preferred as it allows 726 to advertise the presence of a tunnel without influencing the LSDB 727 and the SPF computation. 729 3.6. Inter-Area Considerations 731 In the following example diagram we assume an IGP deployed using 732 areas and where SR has been deployed. 734 The example here below assumes the IPv6 control plane with the MPLS 735 dataplane. 737 ! ! 738 ! ! 739 B------C-----F----G-----K 740 / | | | 741 S---A/ | | | 742 \ | | | 743 \D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150) 744 ! ! 745 Area-1 ! Backbone ! Area 2 746 ! area ! 748 Figure 4: Inter-Area Topology Example 750 In area 2, node Z allocates Node-SID 150 to his local IPv6 prefix 751 2001:DB8::2:1/128. 753 ABRs G and J will propagate the prefix and its SIDs into the backbone 754 area by creating a new instance of the prefix according to normal 755 inter-area/level IGP propagation rules. 757 Nodes C and I will apply the same behavior when leaking prefixes from 758 the backbone area down to area 1. Therefore, node S will see prefix 759 2001:DB8::2:1/128 with Prefix-SID 150 and advertised by nodes C and 760 I. 762 It therefore results that a Prefix-SID remains attached to its 763 related IGP Prefix through the inter-area process. 765 When node S sends traffic to 2001:DB8::2:1/128, it pushes Node- 766 SID(150) as active segment and forward it to A. 768 When packet arrives at ABR I (or C), the ABR forwards the packet 769 according to the active segment (Node-SID(150)). Forwarding 770 continues across area borders, using the same Node-SID(150), until 771 the packet reaches its destination. 773 When an ABR propagates a prefix from one area to another it MUST set 774 the R-Flag. 776 4. BGP Peering Segments 778 In the context of BGP Egress Peer Engineering (EPE), as described in 779 [I-D.ietf-spring-segment-routing-central-epe], an EPE enabled Egress 780 PE node MAY advertise segments corresponding to its attached peers. 781 These segments are called BGP peering segments or BGP peering SIDs. 782 They enable the expression of source-routed inter-domain paths. 784 An ingress border router of an AS may compose a list of segments to 785 steer a flow along a selected path within the AS, towards a selected 786 egress border router C of the AS and through a specific peer. At 787 minimum, a BGP peering Engineering policy applied at an ingress PE 788 involves two segments: the Node SID of the chosen egress PE and then 789 the BGP peering segment for the chosen egress PE peer or peering 790 interface. 792 Hereafter, we will define three types of BGP peering segments/SIDs: 793 PeerNode SID, PeerAdj SID and PeerSet SID. 795 o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At 796 the BGP node advertising it, its semantics is: 798 * SR header operation: NEXT. 800 * Next-Hop: the connected peering node to which the segment is 801 related. 803 o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the 804 BGP node advertising it, the semantic is: 806 * SR header operation: NEXT. 808 * Next-Hop: the peer connected through the interface to which the 809 segment is related. 811 o PeerSet SID. a BGP PeerSet segment/SID is a local segment. At the 812 BGP node advertising it, the semantic is: 814 * SR header operation: NEXT. 816 * Next-Hop: load-balance across any connected interface to any 817 peer in the related group. 819 A peer set could be all the connected peers from the same AS or a 820 subset of these. A group could also span across AS. The group 821 definition is a policy set by the operator. 823 The BGP extensions necessary in order to signal these BGP peering 824 segments will be defined in a separate document. 826 5. IGP Mirroring Context Segment 828 It is beneficial for an IGP node to be able to advertise its ability 829 to process traffic originally destined to another IGP node, called 830 the Mirrored node and identified by an IP address or a Node-SID, 831 provided that a "Mirroring Context" segment be inserted in the 832 segment list prior to any service segment local to the mirrored node. 834 When a given node B wants to provide egress node A protection, it 835 advertises a segment identifying node's A context. Such segment is 836 called "Mirror Context Segment" and identified by the Mirror SID. 838 The Mirror SID is advertised using the binding segment defined in SR 839 IGP protocol extensions ( [I-D.ietf-isis-segment-routing-extensions], 840 [I-D.ietf-ospf-segment-routing-extensions] and 841 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). 843 In the event of a failure, a point of local repair (PLR) diverting 844 traffic from A to B does a PUSH of the Mirror SID on the protected 845 traffic. B, when receiving the traffic with the Mirror SID as the 846 active segment, uses that segment and processes underlying segments 847 in the context of A. 849 6. Multicast 851 Segment Routing is defined for unicast. The application of the 852 source-route concept to Multicast is not in the scope of this 853 document. 855 7. IANA Considerations 857 This document does not require any action from IANA. 859 8. Security Considerations 861 Segment Routing is applicable to both MPLS and IPv6 data planes. 863 Segment Routing adds some meta-data (instructions) on the packet, 864 with the list of forwarding path elements (e.g.: nodes, links, 865 services, etc.) that the packet must traverse. It has to be noted 866 that the complete source routed path may be represented by a single 867 segment. This is the case of the Binding SID. 869 8.1. MPLS Data Plane 871 When applied to the MPLS data plane, Segment Routing does not 872 introduce any new behavior or any change in the way MPLS data plane 873 works. Therefore, from a security standpoint, this document does not 874 define any additional mechanism in the MPLS data plane. 876 SR allows the expression of a source routed path using a single 877 segment (the Binding SID). Compared to RSVP-TE which also provides 878 explicit routing capability, there are no fundamental differences in 879 term of information provided. Both RSVP-TE and Segment Routing may 880 express a source routed path using a single segment. 882 When a path is expressed using a single label, the syntax of the 883 meta-data is equivalent between RSVP-TE and SR. 885 When a source routed path is expressed with a list of segments 886 additional meta-data is added to the packet consisting of the source 887 routed path the packet must follow expressed as a segment list. 889 When a path is expressed using a label stack, if one has access to 890 the meaning (i.e.: the Forwarding Equivalence Class) of the labels, 891 one has the knowledge of the explicit path. For the MPLS data plane, 892 as no data plane modification is required, there is no fundamental 893 change of capability. Yet, the occurrence of label stacking will 894 increase. 896 From a network protection standpoint, there is an assumed trust model 897 such that any node imposing a label stack on a packet is assumed to 898 be allowed to do so. This is a significant change compared to plain 899 IP offering shortest path routing but not fundamentally different 900 compared to existing techniques providing explicit routing capability 901 such as RSVP-TE. By default, the explicit routing information MUST 902 NOT be leaked through the boundaries of the administered domain. 904 Segment Routing extensions that have been defined in various 905 protocols, leverage the security mechanisms of these protocols such 906 as encryption, authentication, filtering, etc. 908 In the general case, a segment routing capable router accepts and 909 install labels, only if these labels have been previously advertised 910 by a trusted source. The received information is validated using 911 existing control plane protocols providing authentication and 912 security mechanisms. Segment Routing does not define any additional 913 security mechanism in existing control plane protocols. 915 Segment Routing does not introduce signaling between the source and 916 the mid points of a source routed path. With SR, the source routed 917 path is computed using SIDs previously advertised in the IP control 918 plane. Therefore, in addition to filtering and controlled 919 advertisement of SIDs at the boundaries of the SR domain, filtering 920 in the data plane is also required. Filtering MUST be performed on 921 the forwarding plane at the boundaries of the SR domain and may 922 require looking at multiple labels/instruction. 924 For the MPLS data plane, there are no new requirement as the existing 925 MPLS architecture already allows such source routing by stacking 926 multiple labels. And for security protection, [RFC4381] section 2.4 927 and [RFC5920] section 8.2 already calls for the filtering of MPLS 928 packets on trust boundaries. 930 8.2. IPv6 Data Plane 932 When applied to the IPv6 data plane, Segment Routing does introduce 933 the Segment Routing Header (SRH, 934 [I-D.ietf-6man-segment-routing-header]) which is a type of Routing 935 Extension header as defined in [RFC2460]. 937 The SRH adds some meta-data on the IPv6 packet, with the list of 938 forwarding path elements (e.g.: nodes, links, services, etc.) that 939 the packet must traverse and that are represented by IPv6 addresses. 940 A complete source routed path may be encoded in the packet using a 941 single segment (single IPv6 address). 943 From a network protection standpoint, there is an assumed trust model 944 such that any node adding an SRH to the packet is assumed to be 945 allowed to do so. Therefore, by default, the explicit routing 946 information MUST NOT be leaked through the boundaries of the 947 administered domain. Segment Routing extensions that have been 948 defined in various protocols, leverage the security mechanisms of 949 these protocols such as encryption, authentication, filtering, etc. 951 In the general case, an SR IPv6 router accepts and install segments 952 identifiers (in the form of IPv6 addresses), only if these SIDs are 953 advertised by a trusted source. The received information is 954 validated using existing control plane protocols providing 955 authentication and security mechanisms. Segment Routing does not 956 define any additional security mechanism in existing control plane 957 protocols. 959 In addition, SR domain boundary routers, by default, MUST apply data 960 plane filters so to only accept packets whose DA and SRH (if any) 961 contain addresses previously advertised as SIDs. 963 There are a number of security concerns with source routing at the 964 IPv6 data plane [RFC5095]. The new IPv6-based segment routing header 965 is defined in [I-D.ietf-6man-segment-routing-header]. This document 966 also discusses the above security concerns. 968 9. Manageability Considerations 970 In SR enabled networks, the path the packet takes is encoded in the 971 header. As the path is not signaled through a protocol, OAM 972 mechanisms are necessary in order for the network operator to 973 validate the effectiveness of a path as well as to check and monitor 974 its liveness and performance. However, it has to be noted that SR 975 allows to reduce substantially the number of states in transit nodes 976 and hence the number of elements that a transit node has to manage is 977 smaller. 979 SR OAM use cases and requirements for the MPLS data plane are defined 980 in [I-D.ietf-spring-oam-usecase] and 981 [I-D.ietf-spring-sr-oam-requirement]. SR OAM procedures for the MPLS 982 data plane are defined in [I-D.ietf-mpls-spring-lsp-ping]. 984 SR routers receive advertisements of SIDs (index, label or IPv6 985 address) from the different routing protocols being extended for SR. 986 Each of these protocols have monitoring and troubleshooting 987 mechanisms to provide operation and management functions for IP 988 addresses that MUST be extended in order to include troubleshooting 989 and monitoring functions of the SID. 991 SR architecture introduces the usage of global segments. Each global 992 segment must be bound to a globally-unique index or address. The 993 management of the allocation of such index or address by the operator 994 is critical for the network behavior to avoid situations like mis- 995 routing. In addition to the allocation policy/tooling that the 996 operator will have in place, an implementation SHOULD protect the 997 network in case of conflict detection by providing a deterministic 998 resolution approach. 1000 An operator may implement tools in order to audit the network and 1001 ensure the good allocation of indexes, SIDs or IP addresses. 1002 Conflict detection between SIDs, including Mapping Server binding 1003 SIDs, and their resolution are addressed in 1004 [I-D.ietf-spring-conflict-resolution]. 1006 SR with the MPLS data plane, can be gracefully introduced in an 1007 existing LDP [RFC5036] network. This is described in 1008 [I-D.ietf-spring-segment-routing-ldp-interop]. SR and LDP may also 1009 inter-work. In this case, the introduction of mapping-server may 1010 introduce some additional manageability considerations that are 1011 discussed in [I-D.ietf-spring-segment-routing-ldp-interop]. 1013 When a path is expressed using a label stack, the occurrence of label 1014 stacking will increase. A node may want to signal in the control 1015 plane its ability in terms of size of the label stack it can support. 1017 A YANG data model [RFC6020] for segment routing configuration and 1018 operations has been defined in [I-D.ietf-spring-sr-yang]. 1020 When Segment Routing is applied to the IPv6 data plane, segments are 1021 identified through IPv6 addresses. The allocation, management and 1022 troubleshooting of segment identifiers is no different than the 1023 existing mechanisms applied to the allocation and management of IPv6 1024 addresses. 1026 The DA of the packet gives the active segment address. The segment 1027 list in the SRH gives the entire path of the packet. The validation 1028 of the source routed path is done through inspection of DA and SRH 1029 present in the packet header matched to the equivalent routing table 1030 entries. 1032 In the context of SR over the IPv6 data plane, the source routed path 1033 is encoded in the SRH as described in 1034 [I-D.ietf-6man-segment-routing-header]. The SR IPv6 source routed 1035 path is instantiated into the SRH as a list of IPv6 address where the 1036 active segment is in the Destination Address (DA) field of the IPv6 1037 packet header. Typically, by inspecting in any node the packet 1038 header, it is possible to derive the source routed path it belongs 1039 to. Similar to the context of SR over MPLS data plane, an 1040 implementation may originate path control and monitoring packets 1041 where the source routed path is inserted in the SRH and where each 1042 segment of the path inserts in the packet the relevant data in order 1043 to measure the end to end path and performance. 1045 10. Contributors 1047 The following people have substantially contributed to the definition 1048 of the Segment Routing architecture and to the editing of this 1049 document: 1051 Ahmed Bashandy 1052 Cisco Systems, Inc. 1053 Email: bashandy@cisco.com 1055 Martin Horneffer 1056 Deutsche Telekom 1057 Email: Martin.Horneffer@telekom.de 1059 Wim Henderickx 1060 Nokia 1061 Email: wim.henderickx@nokia.com 1063 Jeff Tantsura 1064 Email: jefftant@gmail.com 1066 Edward Crabbe 1067 Email: edward.crabbe@gmail.com 1069 Igor Milojevic 1070 Email: milojevicigor@gmail.com 1072 Saku Ytti 1073 TDC 1074 Email: saku@ytti.fi 1076 11. Acknowledgements 1078 We would like to thank Dave Ward, Peter Psenak, Dan Frost, Stewart 1079 Bryant, Pierre Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib, 1080 Hannes Gredler, Pushpasis Sarkar, Eric Rosen and Chris Bowers for 1081 their comments and review of this document. 1083 12. References 1085 12.1. Normative References 1087 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1088 Requirement Levels", BCP 14, RFC 2119, 1089 DOI 10.17487/RFC2119, March 1997, 1090 . 1092 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1093 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1094 December 1998, . 1096 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1097 Label Switching Architecture", RFC 3031, 1098 DOI 10.17487/RFC3031, January 2001, 1099 . 1101 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1102 Hierarchy with Generalized Multi-Protocol Label Switching 1103 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1104 DOI 10.17487/RFC4206, October 2005, 1105 . 1107 12.2. Informative References 1109 [I-D.ietf-6man-segment-routing-header] 1110 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 1111 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 1112 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 1113 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 1114 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1115 segment-routing-header-06 (work in progress), March 2017. 1117 [I-D.ietf-isis-segment-routing-extensions] 1118 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1119 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 1120 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1121 segment-routing-extensions-13 (work in progress), June 1122 2017. 1124 [I-D.ietf-mpls-spring-lsp-ping] 1125 Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, 1126 S., Gredler, H., and M. Chen, "Label Switched Path (LSP) 1127 Ping/Traceroute for Segment Routing Networks with MPLS 1128 Dataplane", draft-ietf-mpls-spring-lsp-ping-03 (work in 1129 progress), June 2017. 1131 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1132 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1133 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1134 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1135 segment-routing-extensions-09 (work in progress), March 1136 2017. 1138 [I-D.ietf-ospf-segment-routing-extensions] 1139 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1140 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1141 Extensions for Segment Routing", draft-ietf-ospf-segment- 1142 routing-extensions-16 (work in progress), May 2017. 1144 [I-D.ietf-pce-segment-routing] 1145 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1146 and J. Hardwick, "PCEP Extensions for Segment Routing", 1147 draft-ietf-pce-segment-routing-09 (work in progress), 1148 April 2017. 1150 [I-D.ietf-spring-conflict-resolution] 1151 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1152 "Segment Routing MPLS Conflict Resolution", draft-ietf- 1153 spring-conflict-resolution-04 (work in progress), May 1154 2017. 1156 [I-D.ietf-spring-ipv6-use-cases] 1157 Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and 1158 M. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring- 1159 ipv6-use-cases-11 (work in progress), June 2017. 1161 [I-D.ietf-spring-oam-usecase] 1162 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A 1163 Scalable and Topology-Aware MPLS Dataplane Monitoring 1164 System", draft-ietf-spring-oam-usecase-06 (work in 1165 progress), February 2017. 1167 [I-D.ietf-spring-resiliency-use-cases] 1168 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 1169 "Resiliency use cases in SPRING networks", draft-ietf- 1170 spring-resiliency-use-cases-11 (work in progress), May 1171 2017. 1173 [I-D.ietf-spring-segment-routing-central-epe] 1174 Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev, 1175 "Segment Routing Centralized BGP Egress Peer Engineering", 1176 draft-ietf-spring-segment-routing-central-epe-05 (work in 1177 progress), March 2017. 1179 [I-D.ietf-spring-segment-routing-ldp-interop] 1180 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 1181 S. Litkowski, "Segment Routing interworking with LDP", 1182 draft-ietf-spring-segment-routing-ldp-interop-08 (work in 1183 progress), June 2017. 1185 [I-D.ietf-spring-segment-routing-mpls] 1186 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1187 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1188 data plane", draft-ietf-spring-segment-routing-mpls-09 1189 (work in progress), June 2017. 1191 [I-D.ietf-spring-sr-oam-requirement] 1192 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 1193 and S. Litkowski, "OAM Requirements for Segment Routing 1194 Network", draft-ietf-spring-sr-oam-requirement-03 (work in 1195 progress), January 2017. 1197 [I-D.ietf-spring-sr-yang] 1198 Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG 1199 Data Model for Segment Routing", draft-ietf-spring-sr- 1200 yang-06 (work in progress), March 2017. 1202 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1203 Virtual Private Networks (VPNs)", RFC 4381, 1204 DOI 10.17487/RFC4381, February 2006, 1205 . 1207 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1208 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1209 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1210 . 1212 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1213 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1214 October 2007, . 1216 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1217 of Type 0 Routing Headers in IPv6", RFC 5095, 1218 DOI 10.17487/RFC5095, December 2007, 1219 . 1221 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1222 Topology (MT) Routing in Intermediate System to 1223 Intermediate Systems (IS-ISs)", RFC 5120, 1224 DOI 10.17487/RFC5120, February 2008, 1225 . 1227 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 1228 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 1229 . 1231 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1232 the Network Configuration Protocol (NETCONF)", RFC 6020, 1233 DOI 10.17487/RFC6020, October 2010, 1234 . 1236 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 1237 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 1238 March 2012, . 1240 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 1241 Ward, "IS-IS Multi-Instance", RFC 6822, 1242 DOI 10.17487/RFC6822, December 2012, 1243 . 1245 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1246 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1247 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1248 March 2016, . 1250 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1251 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1252 Packet Routing in Networking (SPRING) Problem Statement 1253 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1254 2016, . 1256 Authors' Addresses 1258 Clarence Filsfils (editor) 1259 Cisco Systems, Inc. 1260 Brussels 1261 BE 1263 Email: cfilsfil@cisco.com 1265 Stefano Previdi (editor) 1266 Cisco Systems, Inc. 1267 Italy 1269 Email: stefano@previdi.net 1271 Bruno Decraene 1272 Orange 1273 FR 1275 Email: bruno.decraene@orange.com 1276 Stephane Litkowski 1277 Orange 1278 FR 1280 Email: stephane.litkowski@orange.com 1282 Rob Shakir 1283 Google, Inc. 1284 1600 Amphitheatre Parkway 1285 Mountain View, CA 94043 1286 US 1288 Email: robjs@google.com