idnits 2.17.1 draft-filsfils-spring-segment-routing-04.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 (July 3, 2014) is 3585 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 (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-01 == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-mpls-02 == Outdated reference: A later version (-01) exists of draft-filsfils-spring-segment-routing-use-cases-00 == Outdated reference: A later version (-06) exists of draft-geib-spring-oam-usecase-01 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-02 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-00 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-00 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-00 == Outdated reference: A later version (-03) exists of draft-kumar-spring-sr-oam-requirement-00 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-01 == Outdated reference: A later version (-03) exists of draft-sivabalan-pce-segment-routing-02 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: January 4, 2015 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 M. Horneffer 10 Deutsche Telekom 11 I. Milojevic 12 Telekom Srbija 13 R. Shakir 14 British Telecom 15 S. Ytti 16 TDC Oy 17 W. Henderickx 18 Alcatel-Lucent 19 J. Tantsura 20 Ericsson 21 E. Crabbe 22 Google, Inc. 23 July 3, 2014 25 Segment Routing Architecture 26 draft-filsfils-spring-segment-routing-04 28 Abstract 30 Segment Routing (SR) leverages the source routing paradigm. A node 31 steers a packet through an ordered list of instructions, called 32 segments. A segment can represent any instruction, topological or 33 service-based. A segment can have a local semantic to an SR node or 34 global within an SR domain. SR allows to enforce a flow through any 35 topological path and service chain while maintaining per-flow state 36 only at the ingress node to the SR domain. 38 Segment Routing can be directly applied to the MPLS architecture with 39 no change on the forwarding plane. A segment is encoded as an MPLS 40 label. An ordered list of segments is encoded as a stack of labels. 41 The segment to process is on the top of the stack. Upon completion 42 of a segment, the related label is popped from the stack. 44 Segment Routing can be applied to the IPv6 architecture, with a new 45 type of routing extension header. A segment is encoded as an IPv6 46 address. An ordered list of segments is encoded as an ordered list 47 of IPv6 addresses in the routing extension header. The segment to 48 process is indicated by a pointer in the routing extension header. 49 Upon completion of a segment, the pointer is incremented. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Status of This Memo 59 This Internet-Draft is submitted in full conformance with the 60 provisions of BCP 78 and BCP 79. 62 Internet-Drafts are working documents of the Internet Engineering 63 Task Force (IETF). Note that other groups may also distribute 64 working documents as Internet-Drafts. The list of current Internet- 65 Drafts is at http://datatracker.ietf.org/drafts/current/. 67 Internet-Drafts are draft documents valid for a maximum of six months 68 and may be updated, replaced, or obsoleted by other documents at any 69 time. It is inappropriate to use Internet-Drafts as reference 70 material or to cite them other than as "work in progress." 72 This Internet-Draft will expire on January 4, 2015. 74 Copyright Notice 76 Copyright (c) 2014 IETF Trust and the persons identified as the 77 document authors. All rights reserved. 79 This document is subject to BCP 78 and the IETF Trust's Legal 80 Provisions Relating to IETF Documents 81 (http://trustee.ietf.org/license-info) in effect on the date of 82 publication of this document. Please review these documents 83 carefully, as they describe your rights and restrictions with respect 84 to this document. Code Components extracted from this document must 85 include Simplified BSD License text as described in Section 4.e of 86 the Trust Legal Provisions and are provided without warranty as 87 described in the Simplified BSD License. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 92 1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4 93 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 94 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 7 95 3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 7 96 3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 97 3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 8 98 3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 9 99 3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 9 100 3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 10 101 3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 11 102 3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 11 103 3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 11 104 3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 11 105 3.6.3. Mirroring Context . . . . . . . . . . . . . . . . . . 12 106 3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 12 107 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 13 108 5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 14 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 110 7. Manageability Considerations . . . . . . . . . . . . . . . . 14 111 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 112 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 113 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 114 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 115 10.2. Informative References . . . . . . . . . . . . . . . . . 14 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 118 1. Introduction 120 With Segment Routing (SR), a node steers a packet through an ordered 121 list of instructions, called segments. A segment can represent any 122 instruction, topological or service-based. A segment can have a 123 local semantic to an SR node or global within an SR domain. SR 124 allows to enforce a flow through any path and service chain while 125 maintaining per-flow state only at the ingress node of the SR domain. 127 Segment Routing can be directly applied to the MPLS architecture (RFC 128 3031) with no change on the forwarding plane. A segment is encoded 129 as an MPLS label. An ordered list of segments is encoded as a stack 130 of labels. The active segment is on the top of the stack. A 131 completed segment is popped off the stack. The addition of a segment 132 is performed with a push. 134 In the Segment Routing MPLS instantiation, a segment could be of 135 several types: 137 o an IGP segment, 139 o a BGP Peering segments, 141 o an LDP LSP segment, 143 o an RSVP-TE LSP segment, 145 o a BGP LSP segment. 147 The first two (IGP and BGP Peering segments) types of segments 148 defined in this document. The use of the last three types of 149 segments is illustrated in 150 [I-D.filsfils-spring-segment-routing-mpls]. 152 Segment Routing can be applied to the IPv6 architecture (RFC2460), 153 with a new type of routing extension header. A segment is encoded as 154 an IPv6 address. An ordered list of segments is encoded as an 155 ordered list of IPv6 addresses in the routing extension header. The 156 active segment is indicated by a pointer in the routing extension 157 header. Upon completion of a segment, the pointer is incremented. A 158 segment can be inserted in the list and the pointer is updated 159 accordingly. 161 Numerous use-cases illustrate the benefits of source routing either 162 for FRR, OAM or Traffic Engineering reasons. 164 This document defines a set of instructions (called segments) that 165 are required to fulfill the described use-cases. These segments can 166 either be used in isolation (one single segment defines the source 167 route of the packet) or in combination (these segments are part of an 168 ordered list of segments that define the source route of the packet). 170 1.1. Companion Documents 172 This document defines the SR architecture, its routing model, the 173 IGP-based segments, the BGP-based segments and the service segments. 175 Use cases are described in 176 [I-D.filsfils-spring-segment-routing-use-cases], 177 [I-D.ietf-spring-ipv6-use-cases], 178 [I-D.ietf-spring-resiliency-use-cases], [I-D.geib-spring-oam-usecase] 179 and [I-D.kumar-spring-sr-oam-requirement]. 181 Segment Routing for MPLS dataplane is documented in 182 [I-D.filsfils-spring-segment-routing-mpls]. 184 Segment Routing for IPv6 dataplane is documented in 185 [I-D.previdi-6man-segment-routing-header]. 187 IGP protocol extensions for Segment Routing are described in 188 [I-D.ietf-isis-segment-routing-extensions] and 189 [I-D.ietf-ospf-segment-routing-extensions] 191 The FRR solution for SR is documented in 192 [I-D.francois-segment-routing-ti-lfa]. 194 The PCEP protocol extensions for Segment Routing are defined in 195 [I-D.sivabalan-pce-segment-routing]. 197 The interaction between SR/MPLS with other MPLS Signaling planes is 198 documented in [I-D.filsfils-spring-segment-routing-ldp-interop]. 200 2. Terminology 202 Segment: a segment identifies an instruction 204 SID: a Segment Identifier 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 Active segment: the segment that MUST be used by the receiving router 212 to process the packet. It is identified by a pointer in the IPv6 213 architecture. It is the top label in the MPLS architecture. 215 PUSH: the insertion of a segment at the head of the Segment list. 217 NEXT: the active segment is completed, the next segment becomes 218 active. 220 CONTINUE: the active segment is not completed and hence remains 221 active. The CONTINUE instruction is implemented as the SWAP 222 instruction in the MPLS dataplane. 224 SR Global Block (SRGB): local property of an SR node. In the MPLS 225 architecture, SRGB is the set of local labels reserved for global 226 segments. In the IPv6 architecture, it is the set of locally 227 relevant IPv6 addresses. 229 Global Segment: the related instruction is supported by all the SR- 230 capable nodes in the domain. In the MPLS architecture, a Global 231 Segment has a globally-unique index. The related local label at a 232 given node N is found by adding the globally-unique index to the SRGB 233 of node N. In the IPv6 architecture, a global segment is a globally- 234 unique IPv6 address. 236 Local Segment: the related instruction is supported only by the node 237 originating it. In the MPLS architecture, this is a local label 238 outside the SRGB. In the IPv6 architecture, this is a link-local 239 address. 241 IGP Segment: the generic name for a segment attached to a piece of 242 information advertised by a link-state IGP, e.g. an IGP prefix or an 243 IGP adjacency. 245 IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP 246 segment attached to an IGP prefix. An IGP-Prefix Segment is always 247 global within the SR/IGP domain and identifies an instruction to 248 forward the packet over the ECMP-aware shortest-path computed by the 249 IGP to the related prefix. The Prefix-SID is the SID of the IGP- 250 Prefix Segment. 252 IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which 253 does not identify a specific router, but a set of routers. The terms 254 "Anycast Segment" or "Anycast-SID" are often used as an abbreviation. 256 IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to 257 an unidirectional adjacency or a set of unidirectional adjacencies. 258 By default, an IGP-Adjacency Segment is local (unless explicitly 259 advertised otherwise) to the node that advertises it. 261 IGP-Node: an IGP-Node Segment is an IGP-Prefix Segment which 262 identifies a specific router (e.g. a loopback). The terms "Node 263 Segment" or Node-SID" are often used as an abbreviation. 265 SR Tunnel: a list of segments to be pushed on the packets directed on 266 the tunnel. The list of segments can be specified explicitly or 267 implicitly via a set of abstract constraints (latency, affinity, 268 SRLG, ...). In the latter case, a constrained-based path computation 269 is used to determine the list of segments associated with the tunnel. 270 The computation can be local or delegated to a PCE server. An SR 271 tunnel can be configured by the operator, provisioned via netconf or 272 provisioned via PCEP. An SR tunnel can be used for traffic- 273 engineering, OAM or FRR reasons. 275 Segment List Depth: the number of segments of an SR tunnel. The 276 entity instantiating an SR Tunnel at a node N should be able to 277 discover the depth insertion capability of the node N. The PCEP 278 discovery capability is described in 279 [I-D.sivabalan-pce-segment-routing]. 281 3. Link-State IGP Segments 283 Within a link-state IGP domain, an SR-capable IGP node advertises 284 segments for its attached prefixes and adjacencies. These segments 285 are called IGP segments or IGP SIDs. They play a key role in Segment 286 Routing and use-cases 287 ([I-D.filsfils-spring-segment-routing-use-cases]) as they enable the 288 expression of any topological path throughout the IGP domain. Such a 289 topological path is either expressed as a single IGP segment or a 290 list of multiple IGP segments. 292 3.1. IGP Segment, IGP SID 294 The terms "IGP Segment" and "IGP SID" are the generic names for a 295 segment attached to a piece of information advertised by a link-state 296 IGP, e.g. an IGP prefix or an IGP adjacency. 298 3.2. IGP-Prefix Segment, Prefix-SID 300 An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. 301 An IGP-Prefix Segment is always global within the SR/IGP domain and 302 identifies the ECMP-aware shortest-path computed by the IGP to the 303 related prefix. The Prefix-SID is the SID of the IGP-Prefix Segment. 305 A packet injected anywhere within the SR/IGP domain with an active 306 Prefix-SID will be forwarded along the shortest-path to that prefix. 308 The IGP signaling extension for IGP-Prefix segment includes the 309 P-Flag. A Node N advertising a Prefix-SID SID-R for its attached 310 prefix R resets the P-Flag to allow its connected neighbors to 311 perform the NEXT operation while processing SID-R. This behavior is 312 equivalent to Penultimate Hop Popping in MPLS. When set, the 313 neighbors of N must perform the CONTINUE operation while processing 314 SID-R. 316 While SR allows to attach a local segment to an IGP prefix (using the 317 L-Flag), we specifically assume that when the terms "IGP-Prefix 318 Segment" and "Prefix-SID" are used, the segment is global (the SID is 319 allocated from the SRGB). This is consistent with 320 [I-D.filsfils-spring-segment-routing-use-cases] as all the described 321 use-cases require global segments attached to IGP prefixes. 323 A single Prefix-SID is allocated to an IGP Prefix in a topology. 325 In the context of multiple topologies, multiple Prefix-SID's MAY be 326 allocated to the same IGP Prefix (e.g.: using the "algorithm" field 327 in the IGP advertisement as described in 328 [I-D.ietf-isis-segment-routing-extensions] and 330 [I-D.ietf-ospf-segment-routing-extensions]). However, each prefix- 331 SID MUST be associated with only one topology. In other words: a 332 prefix, within a topology, MUST have only a single Prefix-SID. 334 A Prefix-SID is allocated from the SRGB according to a process 335 similar to IP address allocation. Typically the Prefix-SID is 336 allocated by policy by the operator (or NMS) and the SID very rarely 337 changes. 339 The allocation process MUST NOT allocate the same Prefix-SID to 340 different IP prefixes. 342 If a node learns a Prefix-SID having a value that falls outside the 343 locally configured SRGB range, then the node MUST NOT use the Prefix- 344 SID and SHOULD issue an error log warning for misconfiguration. 346 The required IGP protocol extensions are defined in 347 [I-D.ietf-isis-segment-routing-extensions]and 348 [I-D.ietf-ospf-segment-routing-extensions]. 350 A node N attaching a Prefix-SID SID-R to its attached prefix R MUST 351 maintain the following FIB entry: 353 Incoming Active Segment: SID-R 354 Ingress Operation: NEXT 355 Egress interface: NULL 357 A remote node M MUST maintain the following FIB entry for any learned 358 Prefix-SID SID-R attached to IP prefix R: 360 Incoming Active Segment: SID-R 361 Ingress Operation: 362 If the next-hop of R is the originator of R 363 and instructed to remove the active segment: NEXT 364 Else: CONTINUE 365 Egress interface: the interface towards the next-hop along 366 the shortest-path to prefix R. 368 3.3. IGP-Node Segment, Node-SID 370 An IGP-Node Segment is a an IGP-Prefix Segment which identifies a 371 specific router (e.g. a loopback). The N flag is set. The terms 372 "Node Segment" or "Node-SID" are often used as an abbreviation. 374 A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere 375 in the network, it enforces the ECMP-aware shortest- path forwarding 376 of the packet towards the related node as explained in 377 [I-D.filsfils-spring-segment-routing-use-cases]. 379 An IGP-Node-SID MUST NOT be associated with a prefix that is owned or 380 advertised by more than one router within the same routing domain. 382 3.4. IGP-Anycast Segment, Anycast SID 384 An IGP-Anycast Segment is an IGP-prefix segment which does not 385 identify a specific router, but a set of routers. The terms "Anycast 386 Segment" or "Anycast-SID" are often used as an abbreviation. 388 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 389 shortest-path forwarding towards the closest node of the anycast set. 390 This is useful to express macro-engineering policies or protection 391 mechanisms as described in 392 [I-D.filsfils-spring-segment-routing-use-cases]. 394 The Anycast SID MUST be advertised with the N-flag unset. 396 3.5. IGP-Adjacency Segment, Adj-SID 398 An IGP-Adjacency Segment is an IGP segment attached to a 399 unidirectional adjacency or a set of unidirectional adjacencies. By 400 default, an IGP-Adjacency Segment is local to the node which 401 advertises it. However, an Adjacency Segment can be global if 402 advertised by the IGP as such. The SID of the IGP-Adjacency Segment 403 is called the Adj-SID. 405 The adjacency is formed by the local node (i.e., the node advertising 406 the adjacency in the IGP) and the remote node (i.e., the other end of 407 the adjacency). The local node MUST be an IGP node. The remote node 408 MAY be an adjacent IGP neighbor) or a non-adjacent neighbor (e.g.: a 409 Forwarding Adjacency, [RFC4206]). 411 A packet injected anywhere within the SR domain with a segment list 412 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 413 attached by node N to its adjacency over link L, will be forwarded 414 along the shortest-path to N and then be switched by N, without any 415 IP shortest-path consideration, towards link L. If the Adj-SID 416 identifies a set of adjacencies, then the node N load- balances the 417 traffic among the various members of the set. 419 Similarly, when using a global Adj-SID, a packet injected anywhere 420 within the SR domain with a segment list {SNL}, where SNL is a global 421 Adj-SID attached by node N to its adjacency over link L, will be 422 forwarded along the shortest-path to N and then be switched by N, 423 without any IP shortest-path consideration, towards link L. If the 424 Adj-SID identifies a set of adjacencies, then the node N load- 425 balances the traffic among the various members of the set. The use 426 of global Adj-SID allows to reduce the size of the segment list when 427 expressing a path at the cost of additional state (i.e.: the global 428 Adj-SID will be inserted by all routers within the area in their 429 forwarding table). 431 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 432 packet from a node towards a defined interface or set of interfaces. 433 This is key to theoretically prove that any path can be expressed as 434 a list of segments as explained in 435 [I-D.filsfils-spring-segment-routing-use-cases]. 437 The encodings of the Adj-SID include the B-flag. When set, the Adj- 438 SID benefits from a local protection. 440 The encodings of the Adj-SID include the L-flag. When set, the Adj- 441 SID has local significance. By default the L-flag is set. 443 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 445 A node MAY allocate multiple Adj-SIDs to the same adjacency. An 446 example is where the adjacency is established over a bundle 447 interface. Each bundle member MAY have its own Adj-SID. 449 A node MAY allocate the same Adj-SID to multiple adjacencies. 451 Adjacency suppression MUST NOT be performed by the IGP. 453 A node MUST install a FIB entry for any Adj-SID of value V attached 454 to data-link L: 456 Incoming Active Segment: V 457 Operation: NEXT 458 Egress Interface: L 460 The Adj-SID implies, from the router advertising it, the forwarding 461 of the packet through the adjacency identified by the Adj-SID, 462 regardless its IGP/SPF cost. In other words, the use of Adjacency 463 Segments overrides the routing decision made by SPF algorithm. 465 3.5.1. Parallel Adjacencies 467 Adj-SIDs can be used in order to represent a set of parallel 468 interfaces between two adjacent routers. 470 A node MUST install a FIB entry for any locally originated Adjacency 471 Segment (Adj-SID) of value W attached to a set of link B with: 473 Incoming Active Segment: W 474 Ingress Operation: NEXT 475 Egress interface: loadbalance between any data-link within set B 477 3.5.2. LAN Adjacency Segments 479 In LAN subnetworks, link-state protocols define the concept of 480 Designated Router (DR, in OSPF) or Designated Intermediate System 481 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 482 that describe the LAN topology in a special routing update (OSPF 483 Type2 LSA or IS-IS Pseudonode LSP). 485 The difficulty with LANs is that each router only advertises its 486 connectivity to the DR/DIS and not to each other individual nodes in 487 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 488 are necessary in order for each router in the LAN to advertise an 489 Adj-SID associated to each neighbor in the LAN. These extensions are 490 defined in [I-D.ietf-isis-segment-routing-extensions] and 491 [I-D.ietf-ospf-segment-routing-extensions]. 493 3.6. Binding Segment 495 3.6.1. Mapping Server 497 A Remote-Binding SID S advertised by the mapping server M for remote 498 prefix R attached to non-SR-capable node N signals the same 499 information as if N had advertised S as a Prefix-SID. Further 500 details are described in the SR/LDP interworking procedures 501 ([I-D.filsfils-spring-segment-routing-ldp-interop]. 503 The segment allocation and SRDB Maintenance rules are the same as 504 those defined for Prefix-SID. 506 3.6.2. Tunnel Headend 508 The segment allocation and SRDB Maintenance rules are the same as 509 those defined for Adj-SID. A tunnel attached to a head-end H acts as 510 an adjacency attached to H. 512 Note: an alternative would consist in representing tunnels as 513 forwarding-adjacencies ( [RFC4206]). The Remote-Binding SID is 514 preferred as it allows to advertise the presence of a tunnel without 515 influencing the LSDB and the SPF computation. 517 3.6.3. Mirroring Context 519 TBD. 521 3.7. Inter-Area Considerations 523 In the following example diagram we assume an IGP deployed using 524 areas and where SR has been deployed. 526 ! ! 527 ! ! 528 B------C-----F----G-----K 529 / | | | 530 S---A/ | | | 531 \ | | | 532 \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) 533 ! ! 534 Area-1 ! Backbone ! Area 2 535 ! area ! 537 Figure 1: Inter-Area Topology Example 539 In area 2, node Z allocates Node-SID 150 to his local prefix 540 192.0.2.1/32. ABRs G and J will propagate the prefix into the 541 backbone area by creating a new instance of the prefix according to 542 normal inter-area/level IGP propagation rules. 544 Nodes C and I will apply the same behavior when leaking prefixes from 545 the backbone area down to area 1. Therefore, node S will see prefix 546 192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. 548 It therefore results that a Prefix-SID remains attached to its 549 related IGP Prefix through the inter-area process. 551 When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as 552 active segment and forward it to A. 554 When packet arrives at ABR I (or C), the ABR forwards the packet 555 according to the active segment (Node-SID(150)). Forwarding 556 continues across area borders, using the same Node-SID(150), until 557 the packet reaches its destination. 559 When an ABR propagates a prefix from one area to another it MUST set 560 the R-Flag. 562 4. BGP Peering Segments 564 In the context of BGP Egress Peer Engineering (EPE), as described in 565 [draft-filsfils-spring-segment-routing-central-epe], an EPE enabled 566 Egress PE node MAY advertise segments corresponding to its attached 567 peers. These segments are called BGP peering segments or BGP Peering 568 SIDs. They enable the expression of source-routed inter-domain 569 paths. 571 An ingress border router of an AS may compose a list of segments to 572 steer a flow along a selected path within the AS, towards a selected 573 egress border router C of the AS and through a specific peer. At 574 minimum, a BGP Peering Engineering policy applied at an ingress PE 575 involves two segments: the Node SID of the chosen egress PE and then 576 the BGP Peering Segment for the chosen egress PE peer or peering 577 interface. 579 Hereafter, we will define three types of BGP peering segments/SID's: 580 PeerNodeSID, PeerAdjSID and PeerSetSID. 582 o PeerNode SID. A BGP PeerNode segment/SID is a local segment. At 583 the BGP node advertising it, its semantics is: 585 * SR header operation: NEXT. 587 * Next-Hop: the connected peering node to which the segment is 588 related. 590 o PeerAdj SID: A BGP PeerAdj segment/SID is a local segment. At the 591 BGP node advertising it, its semantics is: 593 * SR header operation: NEXT. 595 * Next-Hop: the peer connected through the interface to which the 596 segment is related. 598 o PeerSet SID. A BGP PeerSet segment/SID is a local segment. At 599 the BGP node advertising it, its semantics is: 601 * SR header operation: NEXT. 603 * Next-Hop: loadbalance across any connected interface to any 604 peer in the related group. 606 A peer set could be all the connected peers from the same AS or a 607 subset of these. A group could also span across AS. The group 608 definition is a policy set by the operator. 610 The BGP extensions necessary in order to signal these BGP peering 611 segments will be defined in a separate document. 613 5. Multicast 615 Segment Routing is defined for unicast. The application of the 616 source-route concept to Multicast is not in the scope of this 617 document. 619 6. IANA Considerations 621 TBD 623 7. Manageability Considerations 625 TBD 627 8. Security Considerations 629 TBD 631 9. Acknowledgements 633 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 634 Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes 635 Gredler for their contribution to the content of this document. 637 10. References 639 10.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 645 Hierarchy with Generalized Multi-Protocol Label Switching 646 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 648 10.2. Informative References 650 [I-D.filsfils-spring-segment-routing-ldp-interop] 651 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 652 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 653 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 654 "Segment Routing interoperability with LDP", draft- 655 filsfils-spring-segment-routing-ldp-interop-01 (work in 656 progress), April 2014. 658 [I-D.filsfils-spring-segment-routing-mpls] 659 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 660 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 661 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 662 "Segment Routing with MPLS data plane", draft-filsfils- 663 spring-segment-routing-mpls-02 (work in progress), June 664 2014. 666 [I-D.filsfils-spring-segment-routing-use-cases] 667 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 668 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 669 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 670 Crabbe, "Segment Routing Use Cases", draft-filsfils- 671 spring-segment-routing-use-cases-00 (work in progress), 672 March 2014. 674 [I-D.francois-segment-routing-ti-lfa] 675 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 676 "Topology Independent Fast Reroute using Segment Routing", 677 draft-francois-segment-routing-ti-lfa-00 (work in 678 progress), November 2013. 680 [I-D.geib-spring-oam-usecase] 681 Geib, R. and C. Filsfils, "Use case for a scalable and 682 topology aware MPLS data plane monitoring system", draft- 683 geib-spring-oam-usecase-01 (work in progress), February 684 2014. 686 [I-D.ietf-isis-segment-routing-extensions] 687 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 688 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 689 Extensions for Segment Routing", draft-ietf-isis-segment- 690 routing-extensions-02 (work in progress), June 2014. 692 [I-D.ietf-ospf-segment-routing-extensions] 693 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 694 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 695 Extensions for Segment Routing", draft-ietf-ospf-segment- 696 routing-extensions-00 (work in progress), June 2014. 698 [I-D.ietf-spring-ipv6-use-cases] 699 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 700 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 701 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 702 cases-00 (work in progress), May 2014. 704 [I-D.ietf-spring-resiliency-use-cases] 705 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 706 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 707 resiliency-use-cases-00 (work in progress), May 2014. 709 [I-D.kumar-spring-sr-oam-requirement] 710 Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G. 711 Mirsky, "OAM Requirements for Segment Routing Network", 712 draft-kumar-spring-sr-oam-requirement-00 (work in 713 progress), February 2014. 715 [I-D.previdi-6man-segment-routing-header] 716 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 717 Segment Routing Header (SRH)", draft-previdi-6man-segment- 718 routing-header-01 (work in progress), June 2014. 720 [I-D.sivabalan-pce-segment-routing] 721 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and 722 R. Raszuk, "PCEP Extensions for Segment Routing", draft- 723 sivabalan-pce-segment-routing-02 (work in progress), 724 October 2013. 726 [draft-filsfils-spring-segment-routing-central-epe] 727 Filsfils, C. and S. Previdi, "Segment Routing Centralized 728 Egress Peer Engineering", May 2013. 730 Authors' Addresses 732 Clarence Filsfils (editor) 733 Cisco Systems, Inc. 734 Brussels 735 BE 737 Email: cfilsfil@cisco.com 739 Stefano Previdi (editor) 740 Cisco Systems, Inc. 741 Via Del Serafico, 200 742 Rome 00142 743 Italy 745 Email: sprevidi@cisco.com 746 Ahmed Bashandy 747 Cisco Systems, Inc. 748 170, West Tasman Drive 749 San Jose, CA 95134 750 US 752 Email: bashandy@cisco.com 754 Bruno Decraene 755 Orange 756 FR 758 Email: bruno.decraene@orange.com 760 Stephane Litkowski 761 Orange 762 FR 764 Email: stephane.litkowski@orange.com 766 Martin Horneffer 767 Deutsche Telekom 768 Hammer Str. 216-226 769 Muenster 48153 770 DE 772 Email: Martin.Horneffer@telekom.de 774 Igor Milojevic 775 Telekom Srbija 776 Takovska 2 777 Belgrade 778 RS 780 Email: igormilojevic@telekom.rs 782 Rob Shakir 783 British Telecom 784 London 785 UK 787 Email: rob.shakir@bt.com 788 Saku Ytti 789 TDC Oy 790 Mechelininkatu 1a 791 TDC 00094 792 FI 794 Email: saku@ytti.fi 796 Wim Henderickx 797 Alcatel-Lucent 798 Copernicuslaan 50 799 Antwerp 2018 800 BE 802 Email: wim.henderickx@alcatel-lucent.com 804 Jeff Tantsura 805 Ericsson 806 300 Holger Way 807 San Jose, CA 95134 808 US 810 Email: Jeff.Tantsura@ericsson.com 812 Edward Crabbe 813 Google, Inc. 814 1600 Amphitheatre Parkway 815 Mountain View, CA 94043 816 US 818 Email: edc@google.com