idnits 2.17.1 draft-ietf-spring-segment-routing-10.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 19, 2016) is 2708 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 (-13) exists of draft-filsfils-spring-large-scale-interconnect-04 == Outdated reference: A later version (-04) exists of draft-francois-rtgwg-segment-routing-ti-lfa-02 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-02 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-09 == Outdated reference: A later version (-13) exists of draft-ietf-mpls-spring-lsp-ping-01 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-07 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-10 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-08 == Outdated reference: A later version (-05) exists of draft-ietf-spring-conflict-resolution-02 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-07 == Outdated reference: A later version (-10) exists of draft-ietf-spring-oam-usecase-04 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-08 == Outdated reference: A later version (-10) exists of draft-ietf-spring-segment-routing-central-epe-02 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-ldp-interop-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-05 == Outdated reference: A later version (-11) exists of draft-ietf-spring-segment-routing-msdc-02 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-oam-requirement-02 == Outdated reference: A later version (-30) exists of draft-ietf-spring-sr-yang-05 -- Obsolete informational reference (is this intentional?): RFC 6822 (Obsoleted by RFC 8202) Summary: 1 error (**), 0 flaws (~~), 19 warnings (==), 3 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: May 23, 2017 B. Decraene 6 S. Litkowski 7 Orange 8 R. Shakir 9 Google 10 November 19, 2016 12 Segment Routing Architecture 13 draft-ietf-spring-segment-routing-10 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 local semantic 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 node 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 May 23, 2017. 61 Copyright Notice 63 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 7 82 3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 7 83 3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 84 3.2.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 7 85 3.2.2. MPLS Dataplane . . . . . . . . . . . . . . . . . . . 9 86 3.2.3. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . 10 87 3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 10 88 3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 11 89 3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 14 90 3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 15 91 3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 16 92 3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 16 93 3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 16 94 3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 17 95 3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 17 96 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 18 97 5. IGP Mirroring Context Segment . . . . . . . . . . . . . . . 19 98 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 101 8.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 20 102 8.2. IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 21 103 9. Manageability Considerations . . . . . . . . . . . . . . . . 22 104 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 105 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 108 12.2. Informative References . . . . . . . . . . . . . . . . . 25 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 111 1. Introduction 113 With Segment Routing (SR), a node steers a packet through an ordered 114 list of instructions, called segments. A segment can represent any 115 instruction, topological or service-based. A segment can have a 116 local semantic to an SR node or global within an SR domain. SR 117 allows to enforce a flow through any path and service chain while 118 maintaining per-flow state only at the ingress node of the SR domain. 120 Segment Routing can be directly applied to the MPLS architecture 121 ([RFC3031]) with no change on the forwarding plane. A segment is 122 encoded as an MPLS label. An ordered list of segments is encoded as 123 a stack of labels. The active segment is on the top of the stack. A 124 completed segment is popped off the stack. The addition of a segment 125 is performed with a push. 127 In the Segment Routing MPLS instantiation, a segment could be of 128 several types: 130 o an IGP segment, 132 o a BGP Peering segments, 134 o an LDP LSP segment, 136 o an RSVP-TE LSP segment, 138 o a BGP LSP segment. 140 The first two (IGP and BGP Peering segments) types of segments are 141 defined in this document. The use of the last three types of 142 segments is illustrated in [I-D.ietf-spring-segment-routing-mpls]. 144 Segment Routing can be applied to the IPv6 architecture ([RFC2460]), 145 with a new type of routing header. A segment is encoded as an IPv6 146 address. An ordered list of segments is encoded as an ordered list 147 of IPv6 addresses in the routing header. The active segment is 148 indicated by the Destination Address of the packet. Upon completion 149 of a segment, a pointer in the new routing header is incremented and 150 indicates the next segment. 152 Numerous use-cases illustrate the benefits of source routing either 153 for FRR, OAM or Traffic Engineering reasons. 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 Use cases are described in [RFC7855], 167 [I-D.ietf-spring-segment-routing-central-epe], 168 [I-D.ietf-spring-segment-routing-msdc], 169 [I-D.filsfils-spring-large-scale-interconnect], 170 [I-D.ietf-spring-ipv6-use-cases], 171 [I-D.ietf-spring-resiliency-use-cases], [I-D.ietf-spring-oam-usecase] 172 and [I-D.ietf-spring-sr-oam-requirement]. 174 Segment Routing for MPLS dataplane is documented in 175 [I-D.ietf-spring-segment-routing-mpls]. 177 Segment Routing for IPv6 dataplane is documented in 178 [I-D.ietf-6man-segment-routing-header]. 180 IGP protocol extensions for Segment Routing are described in 181 [I-D.ietf-isis-segment-routing-extensions], 182 [I-D.ietf-ospf-segment-routing-extensions] and 183 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] referred in this 184 document as "IGP SR extensions documents". 186 The FRR solution for SR is documented in 187 [I-D.francois-rtgwg-segment-routing-ti-lfa]. 189 The PCEP protocol extensions for Segment Routing are defined in 190 [I-D.ietf-pce-segment-routing]. 192 The interaction between SR/MPLS with other MPLS Signaling planes is 193 documented in [I-D.ietf-spring-segment-routing-ldp-interop]. 195 2. Terminology 197 Segment: an instruction a node executes on the incoming packet (e.g.: 198 forward packet according to shortest path to destination, or, forward 199 packet through a specific interface, or, deliver the packet to a 200 given application/service instance). 202 SID: a Segment Identifier. Examples of SIDs are: a MPLS label, an 203 index value in a MPLS label space, an IPv6 address. Other types of 204 SIDs can be defined in the future. 206 Segment List: ordered list of SID's encoding the topological and 207 service source route of the packet. It is a stack of labels in the 208 MPLS architecture. It is an ordered list of IPv6 addresses in the 209 IPv6 architecture. 211 Segment Routing Domain (SR Domain): the set of nodes participating 212 into the source based routing model. These nodes may be connected to 213 the same physical infrastructure (e.g.: a Service Provider's network) 214 as well as nodes remotely connected to each other (e.g.: an 215 enterprise VPN or an overlay). Note that a SR domain may also be 216 confined within an IGP instance, in which case it is named SR-IGP 217 Domain. 219 Active segment: the segment that MUST be used by the receiving router 220 to process the packet. In the MPLS dataplane is the top label. In 221 the IPv6 dataplane is the destination address of a packet having the 222 Segment Routing Header as defined in 223 [I-D.ietf-6man-segment-routing-header]. 225 PUSH: the insertion of a segment at the head of the Segment list. 227 NEXT: the active segment is completed, the next segment becomes 228 active. 230 CONTINUE: the active segment is not completed and hence remains 231 active. The CONTINUE instruction is implemented as the SWAP 232 instruction in the MPLS dataplane. In IPv6, this is the plain IPv6 233 forwarding action of a regular IPv6 packet according to its 234 Destination Address. 236 SR Global Block (SRGB): local property of an SR node. In the MPLS 237 architecture, SRGB is the set of local labels reserved for global 238 segments. Using the same SRGB on all nodes within the SR domain ease 239 operations and troubleshooting and is expected to be a deployment 240 guideline. In the IPv6 architecture, the equivalent of the SRGB is 241 in fact the set of addresses used as global segments. Since there 242 are no restrictions on which IPv6 address can be used, the concept of 243 the SRGB includes all IPv6 global address space used within the SR 244 domain. 246 Global Segment: the related instruction is supported by all the SR- 247 capable nodes in the domain. In the MPLS architecture, a Global 248 Segment has a globally-unique index. The related local label at a 249 given node N is found by adding the globally-unique index to the SRGB 250 of node N. In the IPv6 architecture, a global segment is a globally- 251 unique IPv6 address. 253 Local Segment: the related instruction is supported only by the node 254 originating it. In the MPLS architecture, this is a local label 255 outside the SRGB. In the IPv6 architecture, this can be any IPv6 256 address whose reachability is not advertised in any routing protocol 257 (hence, the segment is known only by the local node). 259 IGP Segment: the generic name for a segment attached to a piece of 260 information advertised by a link-state IGP, e.g. an IGP prefix or an 261 IGP adjacency. 263 IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP 264 segment attached to an IGP prefix. An IGP-Prefix Segment is global 265 (unless explicitly advertised otherwise) within the SR IGP instance/ 266 topology and identifies an instruction to forward the packet along 267 the path computed using the routing algorithm specified in the 268 algorithm field, in the topology and the IGP instance where it is 269 advertised. The Prefix-SID is the SID of the IGP-Prefix Segment. 271 IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which 272 does not identify a specific router, but a set of routers. The terms 273 "Anycast Segment" or "Anycast-SID" are often used as an abbreviation. 275 IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to 276 an unidirectional adjacency or a set of unidirectional adjacencies. 277 By default, an IGP-Adjacency Segment is local (unless explicitly 278 advertised otherwise) to the node that advertises it. 280 IGP-Node: an IGP-Node Segment is an IGP-Prefix Segment which 281 identifies a specific router (e.g. a loopback). The terms "Node 282 Segment" or Node-SID" are often used as an abbreviation. 284 SR Tunnel: a list of segments to be pushed on the packets directed on 285 the tunnel. The list of segments can be specified explicitly or 286 implicitly via a set of abstract constraints (latency, affinity, 287 SRLG, ...). In the latter case, a constraint-based path computation 288 is used to determine the list of segments associated with the tunnel. 289 The computation can be local or delegated to a PCE server. An SR 290 tunnel can be configured by the operator, provisioned via netconf or 291 provisioned via PCEP. An SR tunnel can be used for traffic- 292 engineering, OAM or FRR reasons. 294 Segment List Depth: the number of segments of an SR tunnel. The 295 entity instantiating an SR Tunnel at a node N should be able to 296 discover the depth insertion capability of the node N. The PCEP 297 discovery capability is described in [I-D.ietf-pce-segment-routing]. 299 3. Link-State IGP Segments 301 Within a link-state IGP domain, an SR-capable IGP node advertises 302 segments for its attached prefixes and adjacencies. These segments 303 are called IGP segments or IGP SIDs. They play a key role in Segment 304 Routing and use-cases as they enable the expression of any 305 topological path throughout the IGP domain. Such a topological path 306 is either expressed as a single IGP segment or a list of multiple IGP 307 segments. 309 3.1. IGP Segment, IGP SID 311 The terms "IGP Segment" and "IGP SID" are the generic names for a 312 segment attached to a piece of information advertised by a link-state 313 IGP, e.g. an IGP prefix or an IGP adjacency. 315 3.2. IGP-Prefix Segment, Prefix-SID 317 An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. 318 An IGP-Prefix Segment is global (unless explicitly advertised 319 otherwise) within the SR/IGP domain. 321 The required IGP protocol extensions are defined in IGP SR extensions 322 documents. 324 3.2.1. Prefix-SID Algorithm 326 The IGP protocol extensions for Segment Routing define the Prefix-SID 327 advertisement which includes a set of flags and the algorithm field. 328 The algorithm field has the purpose of associating a given Prefix-SID 329 to a routing algorithm. 331 In the context of an instance and a topology, multiple Prefix-SID's 332 MAY be allocated to the same IGP Prefix as long as the algorithm 333 value is different in each one. 335 Multiple instances and topologies are defined in IS-IS and OSPF in: 336 [RFC5120], [RFC6822], [RFC6549] and [RFC4915]. 338 Initially, two "algorithms" have been defined: 340 o "Shortest Path": this algorithm is the default behavior. The 341 packet is forwarded along the well known ECMP-aware SPF algorithm 342 however it is explicitly allowed for a midpoint to implement 343 another forwarding based on local policy.. The "Shortest Path" 344 algorithm is in fact the default and current behavior of most of 345 the networks where local policies may override the SPF decision. 347 o "Strict Shortest Path": This algorithm mandates that the packet is 348 forwarded according to ECMP-aware SPF algorithm and instruct any 349 router in the path to ignore any possible local policy overriding 350 SPF decision. The SID advertised with "Strict Shortest Path" 351 algorithm ensures that the path the packet is going to take is the 352 expected, and not altered, SPF path. 354 An IGP-Prefix Segment identifies the path, to the related prefix, 355 along the path computed as per the algorithm field. 357 A packet injected anywhere within the SR/IGP domain with an active 358 Prefix-SID will be forwarded along path computed by the algorithm 359 expressed in the algorithm field. 361 The ingress node of an SR domain validates that the path to a prefix, 362 advertised with a given algorithm, includes nodes all supporting the 363 advertised algorithm. As a consequence, if a node on the path does 364 not support algorithm X, the IGP-Prefix segment will be interrupted 365 and will drop packet on that node. It's the responsibility of the 366 ingress node using a segment to check that all downstream nodes 367 support the algorithm of the segment. 369 A router MUST NOT forward any SR traffic associated with the SR 370 algorithm to the adjacent router, if the adjacent router has not 371 advertised support for such SR algorithm. 373 It has to be noted that Fast Reroute (FRR) mechanisms, such as the 374 one described in [I-D.francois-rtgwg-segment-routing-ti-lfa], that 375 are based on post-convergence SPF, are still compliant to the Strict- 376 SPF algorithm definition. 378 Details of the two defined algorithms are defined in 379 [I-D.ietf-isis-segment-routing-extensions], 380 [I-D.ietf-ospf-segment-routing-extensions] and 381 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 383 3.2.2. MPLS Dataplane 385 When SR is used over the MPLS dataplane: 387 o the IGP signaling extension for IGP-Prefix segment includes the 388 P-Flag ([I-D.ietf-isis-segment-routing-extensions]) or the NP-Flag 389 ([I-D.ietf-ospf-segment-routing-extensions]). A Node N 390 advertising a Prefix-SID SID-R for its attached prefix R unset the 391 P-Flag (or NP-Flag) in order to instruct its connected neighbors 392 to perform the NEXT operation while processing SID-R. This 393 behavior is equivalent to Penultimate Hop Popping in MPLS. When 394 the flag is unset, the neighbors of N MUST perform the NEXT 395 operation while processing SID-R. When the flag is set, the 396 neighbors of N MUST perform the CONTINUE operation while 397 processing SID-R. 399 o A Prefix-SID is allocated in the form of an index in the SRGB (or 400 as a local MPLS label) according to a process similar to IP 401 address allocation. Typically the Prefix-SID is allocated by 402 policy by the operator (or NMS) and the SID very rarely changes. 404 o While SR allows to attach a local segment to an IGP prefix (using 405 the L-Flag), we specifically assume that when the terms "IGP- 406 Prefix Segment" and "Prefix-SID" are used, the segment is global 407 (the SID is allocated from the SRGB or as an index). This is 408 consistent with all the described use-cases that require global 409 segments attached to IGP prefixes. 411 o The allocation process MUST NOT allocate the same Prefix-SID to 412 different IP prefixes. 414 o If a node learns a Prefix-SID having a value that falls outside 415 the locally configured SRGB range, then the node MUST NOT use the 416 Prefix-SID and SHOULD issue an error log warning for 417 misconfiguration. 419 o If a node N advertises Prefix-SID SID-R for a prefix R that is 420 attached to N, N MUST either clear the P-Flag in the advertisement 421 of SID-R, or else maintain the following FIB entry: 423 Incoming Active Segment: SID-R 424 Ingress Operation: NEXT 425 Egress interface: NULL 427 o A remote node M MUST maintain the following FIB entry for any 428 learned Prefix-SID SID-R attached to IP prefix R: 430 Incoming Active Segment: SID-R 431 Ingress Operation: 432 If the next-hop of R is the originator of R 433 and instructed to remove the active segment: NEXT 434 Else: CONTINUE 435 Egress interface: the interface towards the next-hop along the 436 path computed using the algorithm advertised with 437 the SID toward prefix R. 439 3.2.3. IPv6 Dataplane 441 When SR is used over the IPv6 dataplane: 443 o The Prefix-SID is the prefix itself. No additional identifier is 444 needed for Segment Routing over IPv6. 446 o Any address belonging to any of the node's prefixes can be used as 447 Prefix-SIDs. 449 o An operator may want to explicitly indicate which of the node's 450 prefixes can be used as Prefix-SIDs through the setting of a flag 451 (e.g.: using the IGP prefix attribute defined in [RFC7794]) in the 452 routing protocol used for advertising the prefix. 454 o A global SID is instantiated through any globally advertised IPv6 455 address. 457 o A local SID is instantiated through a local IPv6 prefix not being 458 advertised and therefore known only by the local node. 460 A node N advertising an IPv6 address R usable as a segment identifier 461 MUST maintain the following FIB entry: 463 Incoming Active Segment: R 464 Ingress Operation: NEXT 465 Egress interface: NULL 467 Regardless Segment Routing, any remote IPv6 node will maintain a 468 plain IPv6 FIB entry for any prefix, no matter if they represent a 469 segment or not. 471 3.3. IGP-Node Segment, Node-SID 473 An IGP Node Segment is a an IGP Prefix Segment which identifies a 474 specific router (e.g. a loopback). The terms "Node Segment" or 475 "Node-SID" are often used as an abbreviation. The IGP SR extensions 476 define a flag that identifies Node-SIDs. 478 A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere 479 in the network, it enforces the ECMP-aware shortest-path forwarding 480 of the packet towards the related node. 482 An IGP Node-SID MUST NOT be associated with a prefix that is owned by 483 more than one router within the same routing domain. 485 3.4. IGP-Anycast Segment, Anycast SID 487 An IGP-Anycast Segment is an IGP-prefix segment which does not 488 identify a specific router, but a set of routers. The terms "Anycast 489 Segment" or "Anycast-SID" are often used as an abbreviation. 491 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 492 shortest-path forwarding towards the closest node of the anycast set. 493 This is useful to express macro-engineering policies or protection 494 mechanisms. 496 An IGP-Anycast Segment MUST NOT reference a particular node. 498 Within an anycast group, all routers MUST advertise the same prefix 499 with the same SID value. 501 +--------------+ 502 | Group A | 503 |192.0.2.10/32 | 504 | SID:100 | 505 | | 506 +-----------A1---A3----------+ 507 | | | \ / | | | 508 SID:10 | | | / | | | SID:30 509 203.0.113.1/32 | | | / \ | | | 203.0.113.3/32 510 PE1------R1----------A2---A4---------R3------PE3 511 \ /| | | |\ / 512 \ / | +--------------+ | \ / 513 \ / | | \ / 514 / | | / 515 / \ | | / \ 516 / \ | +--------------+ | / \ 517 / \| | | |/ \ 518 PE2------R2----------B1---B3----+----R4------PE4 519 203.0.113.2/32 | | | \ / | | | 203.0.113.4/32 520 SID:20 | | | / | | | SID:40 521 | | | / \ | | | 522 +-----+-----B2---B4----+-----+ 523 | | 524 | Group B | 525 | 192.0.2.1/32 | 526 | SID:200 | 527 +--------------+ 529 Transit device groups 531 The figure above describes a network example with two groups of 532 transit devices. Group A consists of devices {A1, A2, A3 and A4}. 533 They are all provisioned with the anycast address 192.0.2.10/32 and 534 the anycast SID 100. 536 Similarly, group B consists of devices {B1, B2, B3 and B4} and are 537 all provisioned with the anycast address 192.0.2.1/32, anycast SID 538 200. In the above network topology, each PE device is connected to 539 two routers in each of the groups A and B. 541 PE1 can choose a particular transit device group when sending traffic 542 to PE3 or PE4. This will be done by pushing the anycast SID of the 543 group in the stack. 545 Processing the anycast, and subsequent segments, requires special 546 care. 548 Obviously, the value of the SID following the anycast SID MUST be 549 understood by all nodes advertising the same anycast segment. 551 +-------------------------+ 552 | Group A | 553 | 192.0.2.10/32 | 554 | SID:100 | 555 |-------------------------| 556 | | 557 | SRGB: SRGB: | 558 SID:10 |(1000-2000) (3000-4000)| SID:30 559 PE1---+ +-------A1-------------A3-------+ +---PE3 560 \ / | | \ / | | \ / 561 \ / | | +-----+ / | | \ / 562 SRGB: \ / | | \ / | | \ / SRGB: 563 (7000-8000) R1 | | \ | | R3 (6000-7000) 564 / \ | | / \ | | / \ 565 / \ | | +-----+ \ | | / \ 566 / \ | | / \ | | / \ 567 PE2---+ +-------A2-------------A4-------+ +---PE4 568 SID:20 | SRGB: SRGB: | SID:40 569 |(2000-3000) (4000-5000)| 570 | | 571 +-------------------------+ 573 Transit paths via anycast group A 575 Considering a MPLS deployment, in the above topology, if device PE1 576 (or PE2) requires to send a packet to the device PE3 (or PE4) it 577 needs to encapsulate the packet in a MPLS payload with the following 578 stack of labels. 580 o Label allocated by R1 for anycast SID 100 (outer label). 582 o Label allocated by the nearest router in group A for SID 30 (for 583 destination PE3). 585 While the first label is easy to compute, in this case since there 586 are more than one topologically nearest devices (A1 and A2), unless 587 A1 and A2 allocated the same label value to the same prefix, 588 determining the second label is impossible. Devices A1 and A2 may be 589 devices from different hardware vendors. If both don't allocate the 590 same label value for SID 30, it is impossible to use the anycast 591 group "A" as a transit anycast group towards PE3. Hence, PE1 (or 592 PE2) cannot compute an appropriate label stack to steer the packet 593 exclusively through the group A devices. Same holds true for devices 594 PE3 and PE4 when trying to send a packet to PE1 or PE2. 596 To ease the use of anycast segment in a short term, it is recommended 597 to configure the same SRGB on all nodes of a particular anycast 598 group. Using this method, as mentioned above, computation of the 599 label following the anycast segment is straightforward. 601 Using anycast segment without configuring the same SRGB on nodes 602 belonging to the same device group may lead to misrouting (in a MPLS 603 VPN deployment, some traffic may leak between VPNs). 605 3.5. IGP-Adjacency Segment, Adj-SID 607 An IGP-Adjacency Segment is an IGP segment attached to a 608 unidirectional adjacency or a set of unidirectional adjacencies. By 609 default, an IGP-Adjacency Segment is local to the node which 610 advertises it. However, an Adjacency Segment can be global if 611 advertised by the IGP as such. The SID of the IGP-Adjacency Segment 612 is called the Adj-SID. 614 The adjacency is formed by the local node (i.e., the node advertising 615 the adjacency in the IGP) and the remote node (i.e., the other end of 616 the adjacency). The local node MUST be an IGP node. The remote node 617 MAY be an adjacent IGP neighbor or a non-adjacent neighbor (e.g.: a 618 Forwarding Adjacency, [RFC4206]). 620 A packet injected anywhere within the SR domain with a segment list 621 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 622 attached by node N to its adjacency over link L, will be forwarded 623 along the shortest-path to N and then be switched by N, without any 624 IP shortest-path consideration, towards link L. If the Adj-SID 625 identifies a set of adjacencies, then the node N load- balances the 626 traffic among the various members of the set. 628 Similarly, when using a global Adj-SID, a packet injected anywhere 629 within the SR domain with a segment list {SNL}, where SNL is a global 630 Adj-SID attached by node N to its adjacency over link L, will be 631 forwarded along the shortest-path to N and then be switched by N, 632 without any IP shortest-path consideration, towards link L. If the 633 Adj-SID identifies a set of adjacencies, then the node N load- 634 balances the traffic among the various members of the set. The use 635 of global Adj-SID allows to reduce the size of the segment list when 636 expressing a path at the cost of additional state (i.e.: the global 637 Adj-SID will be inserted by all routers within the area in their 638 forwarding table). 640 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 641 packet from a node towards a defined interface or set of interfaces. 642 This is key to theoretically prove that any path can be expressed as 643 a list of segments. 645 The encodings of the Adj-SID include the B-flag. When set, the Adj- 646 SID refers to an adjacency that is eligible for protection (e.g.: 647 using IPFRR or MPLS-FRR). 649 The encodings of the Adj-SID include the L-flag. When set, the Adj- 650 SID has local significance. By default the L-flag is set. 652 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 654 A node MAY allocate multiple Adj-SIDs to the same adjacency. An 655 example is where the adjacency is established over a bundle 656 interface. Each bundle member MAY have its own Adj-SID. 658 A node MAY allocate the same Adj-SID to multiple adjacencies. 660 Adjacency suppression MUST NOT be performed by the IGP. 662 A node MUST install a FIB entry for any Adj-SID of value V attached 663 to data-link L: 665 Incoming Active Segment: V 666 Operation: NEXT 667 Egress Interface: L 669 The Adj-SID implies, from the router advertising it, the forwarding 670 of the packet through the adjacency identified by the Adj-SID, 671 regardless its IGP/SPF cost. In other words, the use of Adjacency 672 Segments overrides the routing decision made by SPF algorithm. 674 3.5.1. Parallel Adjacencies 676 Adj-SIDs can be used in order to represent a set of parallel 677 interfaces between two adjacent routers. 679 A node MUST install a FIB entry for any locally originated Adjacency 680 Segment (Adj-SID) of value W attached to a set of link B with: 682 Incoming Active Segment: W 683 Ingress Operation: NEXT 684 Egress interface: loadbalance between any data-link within set B 686 When parallel adjacencies are used and associated to the same Adj- 687 SID, and in order to optimize the load balancing function, a "weight" 688 factor can be associated to the Adj-SID advertised with each 689 adjacency. The weight tells the ingress (or a SDN/orchestration 690 system) about the loadbalancing factor over the parallel adjacencies. 691 As shown in Figure 1, A and B are connected through two parallel 692 adjacencies 693 link-1 694 +--------+ 695 | | 696 S---A B---C 697 | | 698 +--------+ 699 link-2 701 Figure 1: Parallel Links and Adj-SIDs 703 Node A advertises following Adj-SIDs and weights: 705 o Link-1: Adj-SID 1000, weight: 1 707 o Link-2: Adj-SID 1000, weight: 2 709 Node S receives the advertisements of the parallel adjacencies and 710 understands that by using Adj-SID 1000 node A will loadbalance the 711 traffic across the parallel links (link-1 and link-2) according to a 712 1:2 ratio. 714 The weight value is advertised with the Adj-SID as defined in IGP SR 715 extensions documents. 717 3.5.2. LAN Adjacency Segments 719 In LAN subnetworks, link-state protocols define the concept of 720 Designated Router (DR, in OSPF) or Designated Intermediate System 721 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 722 that describe the LAN topology in a special routing update (OSPF 723 Type2 LSA or IS-IS Pseudonode LSP). 725 The difficulty with LANs is that each router only advertises its 726 connectivity to the DR/DIS and not to each other individual nodes in 727 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 728 are necessary in order for each router in the LAN to advertise an 729 Adj-SID associated to each neighbor in the LAN. These extensions are 730 defined in IGP SR extensions documents. 732 3.6. Binding Segment 734 3.6.1. Mapping Server 736 A Remote-Binding SID S advertised by the mapping server M for remote 737 prefix R attached to non-SR-capable node N signals the same 738 information as if N had advertised S as a Prefix-SID. Further 739 details are described in the SR/LDP interworking procedures 740 ([I-D.ietf-spring-segment-routing-ldp-interop]. 742 The segment allocation and SRGB Maintenance rules are the same as 743 those defined for Prefix-SID. 745 3.6.2. Tunnel Headend 747 The segment allocation and SRGB Maintenance rules are the same as 748 those defined for Adj-SID. A tunnel attached to a head-end H acts as 749 an adjacency attached to H. 751 Note: an alternative consists of representing tunnels as forwarding- 752 adjacencies ( [RFC4206]). In such case, the tunnel is presented to 753 the routing area as a routing adjacency and is considered as such by 754 all area routers. The Remote-Binding SID is preferred as it allows 755 to advertise the presence of a tunnel without influencing the LSDB 756 and the SPF computation. 758 3.7. Inter-Area Considerations 760 In the following example diagram we assume an IGP deployed using 761 areas and where SR has been deployed. 763 ! ! 764 ! ! 765 B------C-----F----G-----K 766 / | | | 767 S---A/ | | | 768 \ | | | 769 \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) 770 ! ! 771 Area-1 ! Backbone ! Area 2 772 ! area ! 774 Figure 2: Inter-Area Topology Example 776 In area 2, node Z allocates Node-SID 150 to his local prefix 777 192.0.2.1/32. ABRs G and J will propagate the prefix into the 778 backbone area by creating a new instance of the prefix according to 779 normal inter-area/level IGP propagation rules. 781 Nodes C and I will apply the same behavior when leaking prefixes from 782 the backbone area down to area 1. Therefore, node S will see prefix 783 192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. 785 It therefore results that a Prefix-SID remains attached to its 786 related IGP Prefix through the inter-area process. 788 When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as 789 active segment and forward it to A. 791 When packet arrives at ABR I (or C), the ABR forwards the packet 792 according to the active segment (Node-SID(150)). Forwarding 793 continues across area borders, using the same Node-SID(150), until 794 the packet reaches its destination. 796 When an ABR propagates a prefix from one area to another it MUST set 797 the R-Flag. 799 4. BGP Peering Segments 801 In the context of BGP Egress Peer Engineering (EPE), as described in 802 [I-D.ietf-spring-segment-routing-central-epe], an EPE enabled Egress 803 PE node MAY advertise segments corresponding to its attached peers. 804 These segments are called BGP peering segments or BGP Peering SIDs. 805 They enable the expression of source-routed inter-domain paths. 807 An ingress border router of an AS may compose a list of segments to 808 steer a flow along a selected path within the AS, towards a selected 809 egress border router C of the AS and through a specific peer. At 810 minimum, a BGP Peering Engineering policy applied at an ingress PE 811 involves two segments: the Node SID of the chosen egress PE and then 812 the BGP Peering Segment for the chosen egress PE peer or peering 813 interface. 815 Hereafter, we will define three types of BGP peering segments/SID's: 816 PeerNodeSID, PeerAdjSID and PeerSetSID. 818 o PeerNode SID. A BGP PeerNode segment/SID is a local segment. At 819 the BGP node advertising it, its semantics is: 821 * SR header operation: NEXT. 823 * Next-Hop: the connected peering node to which the segment is 824 related. 826 o PeerAdj SID: A BGP PeerAdj segment/SID is a local segment. At the 827 BGP node advertising it, its semantics is: 829 * SR header operation: NEXT. 831 * Next-Hop: the peer connected through the interface to which the 832 segment is related. 834 o PeerSet SID. A BGP PeerSet segment/SID is a local segment. At 835 the BGP node advertising it, its semantics is: 837 * SR header operation: NEXT. 839 * Next-Hop: loadbalance across any connected interface to any 840 peer in the related group. 842 A peer set could be all the connected peers from the same AS or a 843 subset of these. A group could also span across AS. The group 844 definition is a policy set by the operator. 846 The BGP extensions necessary in order to signal these BGP peering 847 segments will be defined in a separate document. 849 5. IGP Mirroring Context Segment 851 It is beneficial for an IGP node to be able to advertise its ability 852 to process traffic originally destined to another IGP node, called 853 the Mirrored node and identified by an IP address or a Node-SID, 854 provided that a "Mirroring Context" segment be inserted in the 855 segment list prior to any service segment local to the mirrored node. 857 When a given node B wants to provide egress node A protection, it 858 advertises a segment identifying node's A context. Such segment is 859 called "Mirror Context Segment" and identified by the Mirror SID. 861 The Mirror SID is advertised using the Binding Segment defined in SR 862 IGP protocol extensions ( [I-D.ietf-isis-segment-routing-extensions], 863 [I-D.ietf-ospf-segment-routing-extensions] and 864 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). 866 In the event of a failure, a point of local repair (PLR) diverting 867 traffic from A to B does a PUSH of the Mirror SID on the protected 868 traffic. B, when receiving the traffic with the Mirror SID as the 869 active segment, uses that segment and process underlying segments in 870 the context of A. 872 6. Multicast 874 Segment Routing is defined for unicast. The application of the 875 source-route concept to Multicast is not in the scope of this 876 document. 878 7. IANA Considerations 880 This document does not require any action from IANA. 882 8. Security Considerations 884 Segment Routing is applicable to both MPLS and IPv6 data planes. 886 Segment Routing adds some meta-data on the packet, with the list of 887 forwarding path elements (e.g.: nodes, links, services, etc.) that 888 the packet must traverse. It has to be noted that the complete 889 source routed path may be represented by a single segment. This is 890 the case of the Binding SID. 892 8.1. MPLS Data Plane 894 When applied to the MPLS data plane, Segment Routing does not 895 introduce any new behavior or any change in the way MPLS data plane 896 works. Therefore, from a security standpoint, this document does not 897 define any additional mechanism in the MPLS data plane. 899 SR allows the expression of a source routed path using a single 900 segment (the Binding SID). Compared to RSVP-TE which also provides 901 explicit routing capability, there are no fundamental differences in 902 term of information provided. Both RSVP-TE and Segment Routing may 903 express a source routed path using a single segment. 905 When a path is expressed using a single label, the syntax of the 906 meta-data is equivalent between RSVP-TE and SR. 908 When a source routed path is expressed with a list of segments 909 additional meta-data is added to the packet consisting of the source 910 routed path the packet must follow expressed as a segment list. 912 When a path is expressed using a label stack, if one has access to 913 the meaning (i.e.: the Forwarding Equivalence Class) of the labels, 914 one has the knowledge of the explicit path. For the MPLS data plane, 915 as no data plane modification is required, there is no fundamental 916 change of capability. Yet, the occurrence of label stacking will 917 increase. 919 From a network protection standpoint, there is an assumed trust model 920 such that any node imposing a label stack on a packet is assumed to 921 be allowed to do so. This is a significant change compared to plain 922 IP offering shortest path routing but not fundamentally different 923 compared to existing techniques providing explicit routing capability 924 such as RSVP-TE. By default, the explicit routing information MUST 925 NOT be leaked through the boundaries of the administered domain. 926 Segment Routing extensions that have been defined in various 927 protocols, leverage the security mechanisms of these protocols such 928 as encryption, authentication, filtering, etc. 930 In the general case, a segment routing capable router accepts and 931 install labels, only if these labels have been previously advertised 932 by a trusted source. The received information is validated using 933 existing control plane protocols providing authentication and 934 security mechanisms. Segment routing does not define any additional 935 security mechanism in existing control plane protocols. 937 Segment Routing does not introduce signaling between the source and 938 the mid points of a source routed path. With SR, the source routed 939 path is computed using SIDs previously advertised in the IP control 940 plane. Therefore, in addition to filtering and controlled 941 advertisement of SIDs at the boundaries of the SR domain, filtering 942 in the data plane is also required. Filtering MUST be performed on 943 the forwarding plane at the boundaries of the SR domain and may 944 require looking at multiple labels/instruction. 946 For the MPLS data plane, there are no new requirement as the existing 947 MPLS architecture already allow such source routing by stacking 948 multiple labels. And for security protection, [RFC4381] section 2.4 949 and [RFC5920] section 8.2 already calls for the filtering of MPLS 950 packets on trust boundaries. 952 8.2. IPv6 Data Plane 954 When applied to the IPv6 data plane, Segment Routing does introduce 955 the Segment Routing Header (SRH, 956 [I-D.ietf-6man-segment-routing-header]) which is a type of Routing 957 Extension header as defined in [RFC2460]. 959 The SRH adds some meta-data on the IPv6 packet, with the list of 960 forwarding path elements (e.g.: nodes, links, services, etc.) that 961 the packet must traverse and that are represented by IPv6 addresses. 962 A complete source routed path may be encoded in the packet using a 963 single segment (single IPv6 address). 965 From a network protection standpoint, there is an assumed trust model 966 such that any node adding an SRH to the packet is assumed to be 967 allowed to do so. Therefore, by default, the explicit routing 968 information MUST NOT be leaked through the boundaries of the 969 administered domain. Segment Routing extensions that have been 970 defined in various protocols, leverage the security mechanisms of 971 these protocols such as encryption, authentication, filtering, etc. 973 In the general case, an SR IPv6 router accepts and install segments 974 identifiers (in the form of IPv6 addresses), only if these SIDs are 975 advertised by a trusted source. The received information is 976 validated using existing control plane protocols providing 977 authentication and security mechanisms. Segment routing does not 978 define any additional security mechanism in existing control plane 979 protocols. 981 In addition, SR domain boundary routers, by default, MUST apply data 982 plane filters so to only accept packets whose DA and SRH (if any) 983 contain addresses previously advertised as SIDs. 985 There are a number of security concerns with source routing at the 986 IPv6 data plane [RFC5095]. The new IPv6-based segment routing header 987 defined in [I-D.ietf-6man-segment-routing-header] and its associated 988 security measures address these concerns. The IPv6 Segment Routing 989 Header is defined in a way that blind attacks are never possible, 990 i.e., attackers will be unable to send source routed packets that get 991 successfully processed, without being part of the negations for 992 setting up the source routes or being able to eavesdrop legitimate 993 source routed packets. In some networks this base level security may 994 be complemented with other mechanisms, such as packet filtering, 995 cryptographic security, etc. 997 9. Manageability Considerations 999 In SR enabled networks, the path the packet takes is encoded in the 1000 header. As the path is not signaled through a protocol, OAM 1001 mechanisms are necessary in order for the network operator to 1002 validate the effectiveness of a path as well as to check and monitor 1003 its liveness and performance. However, it has to be noted that SR 1004 allows to reduce substantially the number of states in transit nodes 1005 and hence the number of elements that a transit node has to manage is 1006 smaller. 1008 SR OAM use cases and requirements for the MPLS data plane are defined 1009 in [I-D.ietf-spring-oam-usecase] and 1010 [I-D.ietf-spring-sr-oam-requirement]. OAM procedures for the MPLS 1011 data plane are defined in [I-D.ietf-mpls-spring-lsp-ping]. 1013 SR routers receive advertisement of SIDs (index, label or IPv6 1014 address) from the different routing protocols being extended for SR. 1015 Each of these protocols have monitoring and troubleshooting 1016 mechanisms so to provide operation and management functions for IP 1017 addresses that MUST be extended in order to include troubleshooting 1018 and monitoring functions of the SID. 1020 SR architecture introduces the usage of global segments. Each global 1021 segment must be bound to a globally-unique index or address. The 1022 management of the allocation of such index or address by the operator 1023 is critical for the network behavior to avoid situations like mis- 1024 routing. In addition to the allocation policy/tooling that the 1025 operator will have in place, an implementation SHOULD protect the 1026 network in case of conflict detection by providing a deterministic 1027 resolution approach. 1029 An operator may implement tools in order to audit the network and 1030 ensure the good allocation of indexes, SIDs or IP addresses. 1031 Conflict detection between SIDs, including Mapping Server binding 1032 SIDs, and their resolution are addressed in 1033 [I-D.ietf-spring-conflict-resolution]. 1035 SR with the MPLS data plane, can be gracefully introduced in an 1036 existing LDP [RFC5036] network. This is described in 1037 [I-D.ietf-spring-segment-routing-ldp-interop]. SR and LDP may also 1038 inter-work. In this case, the introduction of mapping-server may 1039 introduce some additional manageability considerations that are 1040 discussed in [I-D.ietf-spring-segment-routing-ldp-interop]. 1042 When a path is expressed using a a label stack, the occurrence of 1043 label stacking will increase. A node may want to signal in the 1044 control plane it's ability in terms of size of the label stack it can 1045 support. 1047 A YANG data model [RFC6020] for segment routing configuration and 1048 operations has been defined in [I-D.ietf-spring-sr-yang]. 1050 When Segment Routing is applied to the IPv6 data plane, segments are 1051 identified through IPv6 addresses. The allocation, management and 1052 troubleshooting of segment identifiers is no different than the 1053 existing mechanisms applied to the allocation and management of IPv6 1054 addresses. 1056 In the SR over IPv6 data plane context, the allocation of SIDs 1057 results into the allocation of IPv6 addresses. Therefore, 1058 management, troubleshooting, monitoring functions are the same as the 1059 one used for IPv6 addresses. 1061 The control of a source routed path of an IPv6 packet having an SRH 1062 SHOULD be implemented through the inspection of the packet header and 1063 more precisely its DA and segment list (in the SRH). The DA of the 1064 packet gives the active segment address. The segment list in the SRH 1065 gives the entire path of the packet. The validation of the source 1066 routed path is done through inspection of DA and SRH present in the 1067 packet header matched to the equivalent routing table entries. 1069 In the context of SR over the IPv6 data plane, the source routed path 1070 is encoded in the SRH as described in 1071 [I-D.ietf-6man-segment-routing-header]. The SR IPv6 source routed 1072 path is instantiated into the SRH as a list of IPv6 address where the 1073 active segment is in the Destination Address (DA) field of the IPv6 1074 packet header. Typically, by inspecting in any node the packet 1075 header, it is possible to derive the source routed path it belongs 1076 to. Similar to the context of SR over MPLS data plane, an 1077 implementation may originate path control and monitoring packets 1078 where the source routed path is inserted in the SRH and where each 1079 segment of the path inserts in the packet the relevant data in order 1080 to measure the end to end path and performance. 1082 10. Contributors 1084 The following people have substantially contributed to the definition 1085 of the Segment Routing architecture and to the editing of this 1086 document: 1088 Ahmed Bashandy 1089 Cisco Systems, Inc. 1090 Email: bashandy@cisco.com 1092 Martin Horneffer 1093 Deutsche Telekom 1094 Email: Martin.Horneffer@telekom.de 1096 Wim Henderickx 1097 Alcatel-Lucent 1098 Email: wim.henderickx@alcatel-lucent.com 1100 Jeff Tantsura 1101 Ericsson 1102 Email: Jeff.Tantsura@ericsson.com 1104 Edward Crabbe 1105 Individual 1106 Email: edward.crabbe@gmail.com 1108 Igor Milojevic 1109 Email: milojevicigor@gmail.com 1111 Saku Ytti 1112 TDC 1113 Email: saku@ytti.fi 1115 11. Acknowledgements 1117 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 1118 Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib, Hannes 1119 Gredler, Pushpasis Sarkar, Eric Rosen and Chris Bowers for their 1120 comments and review of this document. 1122 12. References 1124 12.1. Normative References 1126 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1127 Requirement Levels", BCP 14, RFC 2119, 1128 DOI 10.17487/RFC2119, March 1997, 1129 . 1131 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1132 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1133 December 1998, . 1135 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1136 Label Switching Architecture", RFC 3031, 1137 DOI 10.17487/RFC3031, January 2001, 1138 . 1140 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1141 Hierarchy with Generalized Multi-Protocol Label Switching 1142 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1143 DOI 10.17487/RFC4206, October 2005, 1144 . 1146 12.2. Informative References 1148 [I-D.filsfils-spring-large-scale-interconnect] 1149 Filsfils, C., Cai, D., Previdi, S., Henderickx, W., 1150 Cooper, D., Ferguson, F., Laberge, T., Lin, S., Decraene, 1151 B., Jalil, L., jefftant@gmail.com, j., and R. Shakir, 1152 "Interconnecting Millions Of Endpoints With Segment 1153 Routing", draft-filsfils-spring-large-scale- 1154 interconnect-04 (work in progress), October 2016. 1156 [I-D.francois-rtgwg-segment-routing-ti-lfa] 1157 Francois, P., Bashandy, A., and C. Filsfils, "Abstract", 1158 draft-francois-rtgwg-segment-routing-ti-lfa-02 (work in 1159 progress), November 2016. 1161 [I-D.ietf-6man-segment-routing-header] 1162 Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, 1163 J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, 1164 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 1165 segment-routing-header-02 (work in progress), September 1166 2016. 1168 [I-D.ietf-isis-segment-routing-extensions] 1169 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1170 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 1171 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 1172 segment-routing-extensions-09 (work in progress), October 1173 2016. 1175 [I-D.ietf-mpls-spring-lsp-ping] 1176 Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, 1177 S., Gredler, H., and M. Chen, "Label Switched Path (LSP) 1178 Ping/Trace for Segment Routing Networks Using MPLS 1179 Dataplane", draft-ietf-mpls-spring-lsp-ping-01 (work in 1180 progress), October 2016. 1182 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 1183 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1184 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 1185 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 1186 segment-routing-extensions-07 (work in progress), October 1187 2016. 1189 [I-D.ietf-ospf-segment-routing-extensions] 1190 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1191 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1192 Extensions for Segment Routing", draft-ietf-ospf-segment- 1193 routing-extensions-10 (work in progress), October 2016. 1195 [I-D.ietf-pce-segment-routing] 1196 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 1197 Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and 1198 J. Hardwick, "PCEP Extensions for Segment Routing", draft- 1199 ietf-pce-segment-routing-08 (work in progress), October 1200 2016. 1202 [I-D.ietf-spring-conflict-resolution] 1203 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1204 "Segment Routing Conflict Resolution", draft-ietf-spring- 1205 conflict-resolution-02 (work in progress), October 2016. 1207 [I-D.ietf-spring-ipv6-use-cases] 1208 Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and 1209 R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring- 1210 ipv6-use-cases-07 (work in progress), July 2016. 1212 [I-D.ietf-spring-oam-usecase] 1213 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A 1214 Scalable and Topology-Aware MPLS Dataplane Monitoring 1215 System", draft-ietf-spring-oam-usecase-04 (work in 1216 progress), October 2016. 1218 [I-D.ietf-spring-resiliency-use-cases] 1219 Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, 1220 "Resiliency use cases in SPRING networks", draft-ietf- 1221 spring-resiliency-use-cases-08 (work in progress), October 1222 2016. 1224 [I-D.ietf-spring-segment-routing-central-epe] 1225 Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. 1226 Afanasiev, "Segment Routing Centralized BGP Peer 1227 Engineering", draft-ietf-spring-segment-routing-central- 1228 epe-02 (work in progress), September 2016. 1230 [I-D.ietf-spring-segment-routing-ldp-interop] 1231 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and 1232 S. Litkowski, "Segment Routing interworking with LDP", 1233 draft-ietf-spring-segment-routing-ldp-interop-04 (work in 1234 progress), July 2016. 1236 [I-D.ietf-spring-segment-routing-mpls] 1237 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1238 Litkowski, S., Horneffer, M., Shakir, R., 1239 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 1240 with MPLS data plane", draft-ietf-spring-segment-routing- 1241 mpls-05 (work in progress), July 2016. 1243 [I-D.ietf-spring-segment-routing-msdc] 1244 Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. 1245 Lapukhov, "BGP-Prefix Segment in large-scale data 1246 centers", draft-ietf-spring-segment-routing-msdc-02 (work 1247 in progress), October 2016. 1249 [I-D.ietf-spring-sr-oam-requirement] 1250 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 1251 and S. Litkowski, "OAM Requirements for Segment Routing 1252 Network", draft-ietf-spring-sr-oam-requirement-02 (work in 1253 progress), July 2016. 1255 [I-D.ietf-spring-sr-yang] 1256 Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG 1257 Data Model for Segment Routing", draft-ietf-spring-sr- 1258 yang-05 (work in progress), October 2016. 1260 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1261 Virtual Private Networks (VPNs)", RFC 4381, 1262 DOI 10.17487/RFC4381, February 2006, 1263 . 1265 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1266 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1267 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1268 . 1270 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 1271 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 1272 October 2007, . 1274 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1275 of Type 0 Routing Headers in IPv6", RFC 5095, 1276 DOI 10.17487/RFC5095, December 2007, 1277 . 1279 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1280 Topology (MT) Routing in Intermediate System to 1281 Intermediate Systems (IS-ISs)", RFC 5120, 1282 DOI 10.17487/RFC5120, February 2008, 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 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 1299 Ward, "IS-IS Multi-Instance", RFC 6822, 1300 DOI 10.17487/RFC6822, December 2012, 1301 . 1303 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1304 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1305 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1306 March 2016, . 1308 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1309 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1310 Packet Routing in Networking (SPRING) Problem Statement 1311 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1312 2016, . 1314 Authors' Addresses 1316 Clarence Filsfils (editor) 1317 Cisco Systems, Inc. 1318 Brussels 1319 BE 1321 Email: cfilsfil@cisco.com 1323 Stefano Previdi (editor) 1324 Cisco Systems, Inc. 1325 Via Del Serafico, 200 1326 Rome 00142 1327 Italy 1329 Email: sprevidi@cisco.com 1331 Bruno Decraene 1332 Orange 1333 FR 1335 Email: bruno.decraene@orange.com 1337 Stephane Litkowski 1338 Orange 1339 FR 1341 Email: stephane.litkowski@orange.com 1343 Rob Shakir 1344 Google, Inc. 1345 1600 Amphitheatre Parkway 1346 Mountain View, CA 94043 1348 Email: robjs@google.com