idnits 2.17.00 (12 Aug 2021) /tmp/idnits37263/draft-ietf-spring-segment-routing-00.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 24, 2014) is 2734 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-filsfils-spring-segment-routing-central-epe-02 == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-02 == Outdated reference: A later version (-02) exists of draft-francois-spring-segment-routing-ti-lfa-01 == Outdated reference: A later version (-06) exists of draft-geib-spring-oam-usecase-03 == Outdated reference: draft-ietf-isis-segment-routing-extensions has been published as RFC 8667 == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665 == Outdated reference: draft-ietf-pce-segment-routing has been published as RFC 8664 == Outdated reference: draft-ietf-spring-ipv6-use-cases has been published as RFC 8354 == Outdated reference: draft-ietf-spring-resiliency-use-cases has been published as RFC 8355 == Outdated reference: A later version (-03) exists of draft-kumar-spring-sr-oam-requirement-01 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-04 Summary: 0 errors (**), 0 flaws (~~), 12 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 A. Bashandy 5 Expires: May 28, 2015 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 M. Horneffer 10 Deutsche Telekom 11 R. Shakir 12 British Telecom 13 J. Tantsura 14 Ericsson 15 E. Crabbe 16 Individual 17 November 24, 2014 19 Segment Routing Architecture 20 draft-ietf-spring-segment-routing-00 22 Abstract 24 Segment Routing (SR) leverages the source routing paradigm. A node 25 steers a packet through an ordered list of instructions, called 26 segments. A segment can represent any instruction, topological or 27 service-based. A segment can have a local semantic to an SR node or 28 global within an SR domain. SR allows to enforce a flow through any 29 topological path and service chain while maintaining per-flow state 30 only at the ingress node to the SR domain. 32 Segment Routing can be directly applied to the MPLS architecture with 33 no change on the forwarding plane. A segment is encoded as an MPLS 34 label. An ordered list of segments is encoded as a stack of labels. 35 The segment to process is on the top of the stack. Upon completion 36 of a segment, the related label is popped from the stack. 38 Segment Routing can be applied to the IPv6 architecture, with a new 39 type of routing extension header. A segment is encoded as an IPv6 40 address. An ordered list of segments is encoded as an ordered list 41 of IPv6 addresses in the routing extension header. The segment to 42 process is indicated by a pointer in the routing extension header. 43 Upon completion of a segment, the pointer is incremented. 45 Requirements Language 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [RFC2119]. 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at http://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on May 28, 2015. 68 Copyright Notice 70 Copyright (c) 2014 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4 87 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 88 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 6 89 3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 7 90 3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 91 3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 8 92 3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 8 93 3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 9 94 3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 10 95 3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 10 96 3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 11 97 3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 11 98 3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 11 99 3.6.3. Mirroring Context . . . . . . . . . . . . . . . . . . 11 100 3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 11 101 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 12 102 5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 13 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 104 7. Manageability Considerations . . . . . . . . . . . . . . . . 14 105 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 106 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 107 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 109 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 110 11.2. Informative References . . . . . . . . . . . . . . . . . 14 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 113 1. Introduction 115 With Segment Routing (SR), a node steers a packet through an ordered 116 list of instructions, called segments. A segment can represent any 117 instruction, topological or service-based. A segment can have a 118 local semantic to an SR node or global within an SR domain. SR 119 allows to enforce a flow through any path and service chain while 120 maintaining per-flow state only at the ingress node of the SR domain. 122 Segment Routing can be directly applied to the MPLS architecture (RFC 123 3031) with no change on the forwarding plane. A segment is encoded 124 as an MPLS label. An ordered list of segments is encoded as a stack 125 of labels. The active segment is on the top of the stack. A 126 completed segment is popped off the stack. The addition of a segment 127 is performed with a push. 129 In the Segment Routing MPLS instantiation, a segment could be of 130 several types: 132 o an IGP segment, 134 o a BGP Peering segments, 136 o an LDP LSP segment, 138 o an RSVP-TE LSP segment, 140 o a BGP LSP segment. 142 The first two (IGP and BGP Peering segments) types of segments 143 defined in this document. The use of the last three types of 144 segments is illustrated in 145 [I-D.filsfils-spring-segment-routing-mpls]. 147 Segment Routing can be applied to the IPv6 architecture (RFC2460), 148 with a new type of routing extension header. A segment is encoded as 149 an IPv6 address. An ordered list of segments is encoded as an 150 ordered list of IPv6 addresses in the routing extension header. The 151 active segment is indicated by a pointer in the routing extension 152 header. Upon completion of a segment, the pointer is incremented. A 153 segment can be inserted in the list and the pointer is updated 154 accordingly. 156 Numerous use-cases illustrate the benefits of source routing either 157 for FRR, OAM or Traffic Engineering reasons. 159 This document defines a set of instructions (called segments) that 160 are required to fulfill the described use-cases. These segments can 161 either be used in isolation (one single segment defines the source 162 route of the packet) or in combination (these segments are part of an 163 ordered list of segments that define the source route of the packet). 165 1.1. Companion Documents 167 This document defines the SR architecture, its routing model, the 168 IGP-based segments, the BGP-based segments and the service segments. 170 Use cases are described in 171 [I-D.filsfils-spring-segment-routing-use-cases], 172 [I-D.ietf-spring-ipv6-use-cases], 173 [I-D.ietf-spring-resiliency-use-cases], [I-D.geib-spring-oam-usecase] 174 and [I-D.kumar-spring-sr-oam-requirement]. 176 Segment Routing for MPLS dataplane is documented in 177 [I-D.filsfils-spring-segment-routing-mpls]. 179 Segment Routing for IPv6 dataplane is documented in 180 [I-D.previdi-6man-segment-routing-header]. 182 IGP protocol extensions for Segment Routing are described in 183 [I-D.ietf-isis-segment-routing-extensions] and 184 [I-D.ietf-ospf-segment-routing-extensions] 186 The FRR solution for SR is documented in 187 [I-D.francois-spring-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.filsfils-spring-segment-routing-ldp-interop]. 195 2. Terminology 197 Segment: a segment identifies an instruction 199 SID: a Segment Identifier 201 Segment List: ordered list of SID's encoding the topological and 202 service source route of the packet. It is a stack of labels in the 203 MPLS architecture. It is an ordered list of IPv6 addresses in the 204 IPv6 architecture. 206 Active segment: the segment that MUST be used by the receiving router 207 to process the packet. It is identified by a pointer in the IPv6 208 architecture. It is the top label in the MPLS architecture. 210 PUSH: the insertion of a segment at the head of the Segment list. 212 NEXT: the active segment is completed, the next segment becomes 213 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. 219 SR Global Block (SRGB): local property of an SR node. In the MPLS 220 architecture, SRGB is the set of local labels reserved for global 221 segments. In the IPv6 architecture, it is the set of locally 222 relevant IPv6 addresses. 224 Global Segment: the related instruction is supported by all the SR- 225 capable nodes in the domain. In the MPLS architecture, a Global 226 Segment has a globally-unique index. The related local label at a 227 given node N is found by adding the globally-unique index to the SRGB 228 of node N. In the IPv6 architecture, a global segment is a globally- 229 unique IPv6 address. 231 Local Segment: the related instruction is supported only by the node 232 originating it. In the MPLS architecture, this is a local label 233 outside the SRGB. In the IPv6 architecture, this is a link-local 234 address. 236 IGP Segment: the generic name for a segment attached to a piece of 237 information advertised by a link-state IGP, e.g. an IGP prefix or an 238 IGP adjacency. 240 IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP 241 segment attached to an IGP prefix. An IGP-Prefix Segment is always 242 global within the SR/IGP domain and identifies an instruction to 243 forward the packet over the ECMP-aware shortest-path computed by the 244 IGP to the related prefix. The Prefix-SID is the SID of the IGP- 245 Prefix Segment. 247 IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which 248 does not identify a specific router, but a set of routers. The terms 249 "Anycast Segment" or "Anycast-SID" are often used as an abbreviation. 251 IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to 252 an unidirectional adjacency or a set of unidirectional adjacencies. 253 By default, an IGP-Adjacency Segment is local (unless explicitly 254 advertised otherwise) to the node that advertises it. 256 IGP-Node: an IGP-Node Segment is an IGP-Prefix Segment which 257 identifies a specific router (e.g. a loopback). The terms "Node 258 Segment" or Node-SID" are often used as an abbreviation. 260 SR Tunnel: a list of segments to be pushed on the packets directed on 261 the tunnel. The list of segments can be specified explicitly or 262 implicitly via a set of abstract constraints (latency, affinity, 263 SRLG, ...). In the latter case, a constrained-based path computation 264 is used to determine the list of segments associated with the tunnel. 265 The computation can be local or delegated to a PCE server. An SR 266 tunnel can be configured by the operator, provisioned via netconf or 267 provisioned via PCEP. An SR tunnel can be used for traffic- 268 engineering, OAM or FRR reasons. 270 Segment List Depth: the number of segments of an SR tunnel. The 271 entity instantiating an SR Tunnel at a node N should be able to 272 discover the depth insertion capability of the node N. The PCEP 273 discovery capability is described in [I-D.ietf-pce-segment-routing]. 275 3. Link-State IGP Segments 277 Within a link-state IGP domain, an SR-capable IGP node advertises 278 segments for its attached prefixes and adjacencies. These segments 279 are called IGP segments or IGP SIDs. They play a key role in Segment 280 Routing and use-cases 281 ([I-D.filsfils-spring-segment-routing-use-cases]) as they enable the 282 expression of any topological path throughout the IGP domain. Such a 283 topological path is either expressed as a single IGP segment or a 284 list of multiple IGP segments. 286 3.1. IGP Segment, IGP SID 288 The terms "IGP Segment" and "IGP SID" are the generic names for a 289 segment attached to a piece of information advertised by a link-state 290 IGP, e.g. an IGP prefix or an IGP adjacency. 292 3.2. IGP-Prefix Segment, Prefix-SID 294 An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. 295 An IGP-Prefix Segment is always global within the SR/IGP domain and 296 identifies the ECMP-aware shortest-path computed by the IGP to the 297 related prefix. The Prefix-SID is the SID of the IGP-Prefix Segment. 299 A packet injected anywhere within the SR/IGP domain with an active 300 Prefix-SID will be forwarded along the shortest-path to that prefix. 302 The IGP signaling extension for IGP-Prefix segment includes the 303 P-Flag. A Node N advertising a Prefix-SID SID-R for its attached 304 prefix R resets the P-Flag to allow its connected neighbors to 305 perform the NEXT operation while processing SID-R. This behavior is 306 equivalent to Penultimate Hop Popping in MPLS. When set, the 307 neighbors of N must perform the CONTINUE operation while processing 308 SID-R. 310 While SR allows to attach a local segment to an IGP prefix (using the 311 L-Flag), we specifically assume that when the terms "IGP-Prefix 312 Segment" and "Prefix-SID" are used, the segment is global (the SID is 313 allocated from the SRGB). This is consistent with 314 [I-D.filsfils-spring-segment-routing-use-cases] as all the described 315 use-cases require global segments attached to IGP prefixes. 317 A single Prefix-SID is allocated to an IGP Prefix in a topology. 319 In the context of multiple topologies, multiple Prefix-SID's MAY be 320 allocated to the same IGP Prefix (e.g.: using the "algorithm" field 321 in the IGP advertisement as described in 322 [I-D.ietf-isis-segment-routing-extensions] and 323 [I-D.ietf-ospf-segment-routing-extensions]). However, each prefix- 324 SID MUST be associated with only one topology. In other words: a 325 prefix, within a topology, MUST have only a single Prefix-SID. 327 A Prefix-SID is allocated from the SRGB according to a process 328 similar to IP address allocation. Typically the Prefix-SID is 329 allocated by policy by the operator (or NMS) and the SID very rarely 330 changes. 332 The allocation process MUST NOT allocate the same Prefix-SID to 333 different IP prefixes. 335 If a node learns a Prefix-SID having a value that falls outside the 336 locally configured SRGB range, then the node MUST NOT use the Prefix- 337 SID and SHOULD issue an error log warning for misconfiguration. 339 The required IGP protocol extensions are defined in 340 [I-D.ietf-isis-segment-routing-extensions]and 341 [I-D.ietf-ospf-segment-routing-extensions]. 343 A node N attaching a Prefix-SID SID-R to its attached prefix R MUST 344 maintain the following FIB entry: 346 Incoming Active Segment: SID-R 347 Ingress Operation: NEXT 348 Egress interface: NULL 350 A remote node M MUST maintain the following FIB entry for any learned 351 Prefix-SID SID-R attached to IP prefix R: 353 Incoming Active Segment: SID-R 354 Ingress Operation: 355 If the next-hop of R is the originator of R 356 and instructed to remove the active segment: NEXT 357 Else: CONTINUE 358 Egress interface: the interface towards the next-hop along 359 the shortest-path to prefix R. 361 3.3. IGP-Node Segment, Node-SID 363 An IGP-Node Segment is a an IGP-Prefix Segment which identifies a 364 specific router (e.g. a loopback). The N flag is set. The terms 365 "Node Segment" or "Node-SID" are often used as an abbreviation. 367 A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere 368 in the network, it enforces the ECMP-aware shortest- path forwarding 369 of the packet towards the related node as explained in 370 [I-D.filsfils-spring-segment-routing-use-cases]. 372 An IGP-Node-SID MUST NOT be associated with a prefix that is owned or 373 advertised by more than one router within the same routing domain. 375 3.4. IGP-Anycast Segment, Anycast SID 377 An IGP-Anycast Segment is an IGP-prefix segment which does not 378 identify a specific router, but a set of routers. The terms "Anycast 379 Segment" or "Anycast-SID" are often used as an abbreviation. 381 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 382 shortest-path forwarding towards the closest node of the anycast set. 383 This is useful to express macro-engineering policies or protection 384 mechanisms as described in 385 [I-D.filsfils-spring-segment-routing-use-cases]. 387 The Anycast SID MUST be advertised with the N-flag unset. 389 3.5. IGP-Adjacency Segment, Adj-SID 391 An IGP-Adjacency Segment is an IGP segment attached to a 392 unidirectional adjacency or a set of unidirectional adjacencies. By 393 default, an IGP-Adjacency Segment is local to the node which 394 advertises it. However, an Adjacency Segment can be global if 395 advertised by the IGP as such. The SID of the IGP-Adjacency Segment 396 is called the Adj-SID. 398 The adjacency is formed by the local node (i.e., the node advertising 399 the adjacency in the IGP) and the remote node (i.e., the other end of 400 the adjacency). The local node MUST be an IGP node. The remote node 401 MAY be an adjacent IGP neighbor) or a non-adjacent neighbor (e.g.: a 402 Forwarding Adjacency, [RFC4206]). 404 A packet injected anywhere within the SR domain with a segment list 405 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 406 attached by node N to its adjacency over link L, will be forwarded 407 along the shortest-path to N and then be switched by N, without any 408 IP shortest-path consideration, towards link L. If the Adj-SID 409 identifies a set of adjacencies, then the node N load- balances the 410 traffic among the various members of the set. 412 Similarly, when using a global Adj-SID, a packet injected anywhere 413 within the SR domain with a segment list {SNL}, where SNL is a global 414 Adj-SID attached by node N to its adjacency over link L, will be 415 forwarded along the shortest-path to N and then be switched by N, 416 without any IP shortest-path consideration, towards link L. If the 417 Adj-SID identifies a set of adjacencies, then the node N load- 418 balances the traffic among the various members of the set. The use 419 of global Adj-SID allows to reduce the size of the segment list when 420 expressing a path at the cost of additional state (i.e.: the global 421 Adj-SID will be inserted by all routers within the area in their 422 forwarding table). 424 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 425 packet from a node towards a defined interface or set of interfaces. 426 This is key to theoretically prove that any path can be expressed as 427 a list of segments as explained in 428 [I-D.filsfils-spring-segment-routing-use-cases]. 430 The encodings of the Adj-SID include the B-flag. When set, the Adj- 431 SID benefits from a local protection. 433 The encodings of the Adj-SID include the L-flag. When set, the Adj- 434 SID has local significance. By default the L-flag is set. 436 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 438 A node MAY allocate multiple Adj-SIDs to the same adjacency. An 439 example is where the adjacency is established over a bundle 440 interface. Each bundle member MAY have its own Adj-SID. 442 A node MAY allocate the same Adj-SID to multiple adjacencies. 444 Adjacency suppression MUST NOT be performed by the IGP. 446 A node MUST install a FIB entry for any Adj-SID of value V attached 447 to data-link L: 449 Incoming Active Segment: V 450 Operation: NEXT 451 Egress Interface: L 453 The Adj-SID implies, from the router advertising it, the forwarding 454 of the packet through the adjacency identified by the Adj-SID, 455 regardless its IGP/SPF cost. In other words, the use of Adjacency 456 Segments overrides the routing decision made by SPF algorithm. 458 3.5.1. Parallel Adjacencies 460 Adj-SIDs can be used in order to represent a set of parallel 461 interfaces between two adjacent routers. 463 A node MUST install a FIB entry for any locally originated Adjacency 464 Segment (Adj-SID) of value W attached to a set of link B with: 466 Incoming Active Segment: W 467 Ingress Operation: NEXT 468 Egress interface: loadbalance between any data-link within set B 470 3.5.2. LAN Adjacency Segments 472 In LAN subnetworks, link-state protocols define the concept of 473 Designated Router (DR, in OSPF) or Designated Intermediate System 474 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 475 that describe the LAN topology in a special routing update (OSPF 476 Type2 LSA or IS-IS Pseudonode LSP). 478 The difficulty with LANs is that each router only advertises its 479 connectivity to the DR/DIS and not to each other individual nodes in 480 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 481 are necessary in order for each router in the LAN to advertise an 482 Adj-SID associated to each neighbor in the LAN. These extensions are 483 defined in [I-D.ietf-isis-segment-routing-extensions] and 484 [I-D.ietf-ospf-segment-routing-extensions]. 486 3.6. Binding Segment 488 3.6.1. Mapping Server 490 A Remote-Binding SID S advertised by the mapping server M for remote 491 prefix R attached to non-SR-capable node N signals the same 492 information as if N had advertised S as a Prefix-SID. Further 493 details are described in the SR/LDP interworking procedures 494 ([I-D.filsfils-spring-segment-routing-ldp-interop]. 496 The segment allocation and SRDB Maintenance rules are the same as 497 those defined for Prefix-SID. 499 3.6.2. Tunnel Headend 501 The segment allocation and SRDB Maintenance rules are the same as 502 those defined for Adj-SID. A tunnel attached to a head-end H acts as 503 an adjacency attached to H. 505 Note: an alternative would consist in representing tunnels as 506 forwarding-adjacencies ( [RFC4206]). The Remote-Binding SID is 507 preferred as it allows to advertise the presence of a tunnel without 508 influencing the LSDB and the SPF computation. 510 3.6.3. Mirroring Context 512 TBD. 514 3.7. Inter-Area Considerations 516 In the following example diagram we assume an IGP deployed using 517 areas and where SR has been deployed. 519 ! ! 520 ! ! 521 B------C-----F----G-----K 522 / | | | 523 S---A/ | | | 524 \ | | | 525 \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) 526 ! ! 527 Area-1 ! Backbone ! Area 2 528 ! area ! 530 Figure 1: Inter-Area Topology Example 532 In area 2, node Z allocates Node-SID 150 to his local prefix 533 192.0.2.1/32. ABRs G and J will propagate the prefix into the 534 backbone area by creating a new instance of the prefix according to 535 normal inter-area/level IGP propagation rules. 537 Nodes C and I will apply the same behavior when leaking prefixes from 538 the backbone area down to area 1. Therefore, node S will see prefix 539 192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. 541 It therefore results that a Prefix-SID remains attached to its 542 related IGP Prefix through the inter-area process. 544 When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as 545 active segment and forward it to A. 547 When packet arrives at ABR I (or C), the ABR forwards the packet 548 according to the active segment (Node-SID(150)). Forwarding 549 continues across area borders, using the same Node-SID(150), until 550 the packet reaches its destination. 552 When an ABR propagates a prefix from one area to another it MUST set 553 the R-Flag. 555 4. BGP Peering Segments 557 In the context of BGP Egress Peer Engineering (EPE), as described in 558 [I-D.filsfils-spring-segment-routing-central-epe], an EPE enabled 559 Egress PE node MAY advertise segments corresponding to its attached 560 peers. These segments are called BGP peering segments or BGP Peering 561 SIDs. They enable the expression of source-routed inter-domain 562 paths. 564 An ingress border router of an AS may compose a list of segments to 565 steer a flow along a selected path within the AS, towards a selected 566 egress border router C of the AS and through a specific peer. At 567 minimum, a BGP Peering Engineering policy applied at an ingress PE 568 involves two segments: the Node SID of the chosen egress PE and then 569 the BGP Peering Segment for the chosen egress PE peer or peering 570 interface. 572 Hereafter, we will define three types of BGP peering segments/SID's: 573 PeerNodeSID, PeerAdjSID and PeerSetSID. 575 o PeerNode SID. A BGP PeerNode segment/SID is a local segment. At 576 the BGP node advertising it, its semantics is: 578 * SR header operation: NEXT. 580 * Next-Hop: the connected peering node to which the segment is 581 related. 583 o PeerAdj SID: A BGP PeerAdj segment/SID is a local segment. At the 584 BGP node advertising it, its semantics is: 586 * SR header operation: NEXT. 588 * Next-Hop: the peer connected through the interface to which the 589 segment is related. 591 o PeerSet SID. A BGP PeerSet segment/SID is a local segment. At 592 the BGP node advertising it, its semantics is: 594 * SR header operation: NEXT. 596 * Next-Hop: loadbalance across any connected interface to any 597 peer in the related group. 599 A peer set could be all the connected peers from the same AS or a 600 subset of these. A group could also span across AS. The group 601 definition is a policy set by the operator. 603 The BGP extensions necessary in order to signal these BGP peering 604 segments will be defined in a separate document. 606 5. Multicast 608 Segment Routing is defined for unicast. The application of the 609 source-route concept to Multicast is not in the scope of this 610 document. 612 6. IANA Considerations 614 TBD 616 7. Manageability Considerations 618 TBD 620 8. Security Considerations 622 TBD 624 9. Contributors 626 The following contributors have substantially helped the definition 627 and editing of the content of this document: 629 Wim Henderickx 630 Email: wim.henderickx@alcatel-lucent.com 632 Igor Milojevic 633 Email: milojevicigor@gmail.com 635 Saku Ytti 636 Email: saku@ytti.fi 638 10. Acknowledgements 640 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 641 Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes 642 Gredler for their comments and review of this document. 644 11. References 646 11.1. Normative References 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, March 1997. 651 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 652 Hierarchy with Generalized Multi-Protocol Label Switching 653 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 655 11.2. Informative References 657 [I-D.filsfils-spring-segment-routing-central-epe] 658 Filsfils, C., Previdi, S., Patel, K., Aries, E., 659 shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment 660 Routing Centralized Egress Peer Engineering", draft- 661 filsfils-spring-segment-routing-central-epe-02 (work in 662 progress), July 2014. 664 [I-D.filsfils-spring-segment-routing-ldp-interop] 665 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 666 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 667 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 668 "Segment Routing interoperability with LDP", draft- 669 filsfils-spring-segment-routing-ldp-interop-02 (work in 670 progress), September 2014. 672 [I-D.filsfils-spring-segment-routing-mpls] 673 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 674 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 675 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 676 "Segment Routing with MPLS data plane", draft-filsfils- 677 spring-segment-routing-mpls-03 (work in progress), August 678 2014. 680 [I-D.filsfils-spring-segment-routing-use-cases] 681 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 682 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 683 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 684 Crabbe, "Segment Routing Use Cases", draft-filsfils- 685 spring-segment-routing-use-cases-01 (work in progress), 686 October 2014. 688 [I-D.francois-spring-segment-routing-ti-lfa] 689 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 690 "Topology Independent Fast Reroute using Segment Routing", 691 draft-francois-spring-segment-routing-ti-lfa-01 (work in 692 progress), October 2014. 694 [I-D.geib-spring-oam-usecase] 695 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 696 case for a scalable and topology aware MPLS data plane 697 monitoring system", draft-geib-spring-oam-usecase-03 (work 698 in progress), October 2014. 700 [I-D.ietf-isis-segment-routing-extensions] 701 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 702 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 703 Extensions for Segment Routing", draft-ietf-isis-segment- 704 routing-extensions-03 (work in progress), October 2014. 706 [I-D.ietf-ospf-segment-routing-extensions] 707 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 708 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 709 Extensions for Segment Routing", draft-ietf-ospf-segment- 710 routing-extensions-02 (work in progress), August 2014. 712 [I-D.ietf-pce-segment-routing] 713 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 714 Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions 715 for Segment Routing", draft-ietf-pce-segment-routing-00 716 (work in progress), October 2014. 718 [I-D.ietf-spring-ipv6-use-cases] 719 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 720 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 721 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 722 cases-03 (work in progress), November 2014. 724 [I-D.ietf-spring-resiliency-use-cases] 725 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 726 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 727 resiliency-use-cases-00 (work in progress), May 2014. 729 [I-D.kumar-spring-sr-oam-requirement] 730 Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G. 731 Mirsky, "OAM Requirements for Segment Routing Network", 732 draft-kumar-spring-sr-oam-requirement-01 (work in 733 progress), July 2014. 735 [I-D.previdi-6man-segment-routing-header] 736 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 737 Segment Routing Header (SRH)", draft-previdi-6man-segment- 738 routing-header-04 (work in progress), November 2014. 740 Authors' Addresses 742 Clarence Filsfils (editor) 743 Cisco Systems, Inc. 744 Brussels 745 BE 747 Email: cfilsfil@cisco.com 748 Stefano Previdi (editor) 749 Cisco Systems, Inc. 750 Via Del Serafico, 200 751 Rome 00142 752 Italy 754 Email: sprevidi@cisco.com 756 Ahmed Bashandy 757 Cisco Systems, Inc. 758 170, West Tasman Drive 759 San Jose, CA 95134 760 US 762 Email: bashandy@cisco.com 764 Bruno Decraene 765 Orange 766 FR 768 Email: bruno.decraene@orange.com 770 Stephane Litkowski 771 Orange 772 FR 774 Email: stephane.litkowski@orange.com 776 Martin Horneffer 777 Deutsche Telekom 778 Hammer Str. 216-226 779 Muenster 48153 780 DE 782 Email: Martin.Horneffer@telekom.de 784 Rob Shakir 785 British Telecom 786 London 787 UK 789 Email: rob.shakir@bt.com 790 Jeff Tantsura 791 Ericsson 792 300 Holger Way 793 San Jose, CA 95134 794 US 796 Email: Jeff.Tantsura@ericsson.com 798 Edward Crabbe 799 Individual 801 Email: edward.crabbe@gmail.com