idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 31, 2015) is 3193 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-04 == Outdated reference: A later version (-02) exists of draft-francois-spring-segment-routing-ti-lfa-01 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-05 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-03 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-05 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-04 == Outdated reference: A later version (-08) exists of draft-ietf-spring-problem-statement-04 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-01 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-07 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: February 1, 2016 B. Decraene 6 S. Litkowski 7 Orange 8 R. Shakir 9 Individual 10 July 31, 2015 12 Segment Routing Architecture 13 draft-ietf-spring-segment-routing-04 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 extension header. A segment is encoded as an IPv6 33 address. An ordered list of segments is encoded as an ordered list 34 of IPv6 addresses in the routing extension header. The segment to 35 process is indicated by a pointer in the routing extension header. 36 Upon completion of a segment, the pointer is incremented. 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 February 1, 2016. 61 Copyright Notice 63 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 5 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.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . . 9 85 3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . . 9 86 3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . . 12 87 3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . . 13 88 3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . . 14 89 3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 14 90 3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . . 14 91 3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . . 15 92 3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 15 93 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . . 16 94 5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 101 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Introduction 106 With Segment Routing (SR), a node steers a packet through an ordered 107 list of instructions, called segments. A segment can represent any 108 instruction, topological or service-based. A segment can have a 109 local semantic to an SR node or global within an SR domain. SR 110 allows to enforce a flow through any path and service chain while 111 maintaining per-flow state only at the ingress node of the SR domain. 113 Segment Routing can be directly applied to the MPLS architecture (RFC 114 3031) with no change on the forwarding plane. A segment is encoded 115 as an MPLS label. An ordered list of segments is encoded as a stack 116 of labels. The active segment is on the top of the stack. A 117 completed segment is popped off the stack. The addition of a segment 118 is performed with a push. 120 In the Segment Routing MPLS instantiation, a segment could be of 121 several types: 123 o an IGP segment, 125 o a BGP Peering segments, 127 o an LDP LSP segment, 129 o an RSVP-TE LSP segment, 131 o a BGP LSP segment. 133 The first two (IGP and BGP Peering segments) types of segments 134 defined in this document. The use of the last three types of 135 segments is illustrated in [I-D.ietf-spring-segment-routing-mpls]. 137 Segment Routing can be applied to the IPv6 architecture (RFC2460), 138 with a new type of routing extension header. A segment is encoded as 139 an IPv6 address. An ordered list of segments is encoded as an 140 ordered list of IPv6 addresses in the routing extension header. The 141 active segment is indicated by a pointer in the routing extension 142 header. Upon completion of a segment, the pointer is incremented. A 143 segment can be inserted in the list and the pointer is updated 144 accordingly. 146 Numerous use-cases illustrate the benefits of source routing either 147 for FRR, OAM or Traffic Engineering reasons. 149 This document defines a set of instructions (called segments) that 150 are required to fulfill the described use-cases. These segments can 151 either be used in isolation (one single segment defines the source 152 route of the packet) or in combination (these segments are part of an 153 ordered list of segments that define the source route of the packet). 155 1.1. Companion Documents 157 This document defines the SR architecture, its routing model, the 158 IGP-based segments, the BGP-based segments and the service segments. 160 Use cases are described in [I-D.ietf-spring-problem-statement], 161 [I-D.filsfils-spring-segment-routing-central-epe], 162 [I-D.filsfils-spring-segment-routing-msdc], 163 [I-D.ietf-spring-ipv6-use-cases], 164 [I-D.ietf-spring-resiliency-use-cases], [I-D.geib-spring-oam-usecase] 165 and [I-D.kumar-spring-sr-oam-requirement]. 167 Segment Routing for MPLS dataplane is documented in 168 [I-D.ietf-spring-segment-routing-mpls]. 170 Segment Routing for IPv6 dataplane is documented in 171 [I-D.previdi-6man-segment-routing-header]. 173 IGP protocol extensions for Segment Routing are described in 174 [I-D.ietf-isis-segment-routing-extensions], 175 [I-D.ietf-ospf-segment-routing-extensions] and 176 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] referred in this 177 document as "IGP SR extensions documents". 179 The FRR solution for SR is documented in 180 [I-D.francois-spring-segment-routing-ti-lfa]. 182 The PCEP protocol extensions for Segment Routing are defined in 183 [I-D.ietf-pce-segment-routing]. 185 The interaction between SR/MPLS with other MPLS Signaling planes is 186 documented in [I-D.filsfils-spring-segment-routing-ldp-interop]. 188 2. Terminology 190 Segment: an instruction a node executes on the incoming packet (e.g.: 191 forward packet according to shortest path to destination, or, forward 192 packet through a specific interface, or, deliver the packet to a 193 given application/service instance). 195 SID: a Segment Identifier 197 Segment List: ordered list of SID's encoding the topological and 198 service source route of the packet. It is a stack of labels in the 199 MPLS architecture. It is an ordered list of IPv6 addresses in the 200 IPv6 architecture. 202 Active segment: the segment that MUST be used by the receiving router 203 to process the packet. It is identified by a pointer in the IPv6 204 architecture. It is the top label in the MPLS architecture. 206 PUSH: the insertion of a segment at the head of the Segment list. 208 NEXT: the active segment is completed, the next segment becomes 209 active. 211 CONTINUE: the active segment is not completed and hence remains 212 active. The CONTINUE instruction is implemented as the SWAP 213 instruction in the MPLS dataplane. 215 SR Global Block (SRGB): local property of an SR node. In the MPLS 216 architecture, SRGB is the set of local labels reserved for global 217 segments. In the IPv6 architecture, it is the set of locally 218 relevant IPv6 addresses. Using the same SRGB on all nodes within the 219 SR domain ease operations and troubleshooting and is expected to be a 220 deployment guideline. 222 Global Segment: the related instruction is supported by all the SR- 223 capable nodes in the domain. In the MPLS architecture, a Global 224 Segment has a globally-unique index. The related local label at a 225 given node N is found by adding the globally-unique index to the SRGB 226 of node N. In the IPv6 architecture, a global segment is a globally- 227 unique IPv6 address. 229 Local Segment: the related instruction is supported only by the node 230 originating it. In the MPLS architecture, this is a local label 231 outside the SRGB. In the IPv6 architecture, this is a link-local 232 address. 234 IGP Segment: the generic name for a segment attached to a piece of 235 information advertised by a link-state IGP, e.g. an IGP prefix or an 236 IGP adjacency. 238 IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP 239 segment attached to an IGP prefix. An IGP-Prefix Segment is always 240 global within the SR/IGP domain and identifies an instruction to 241 forward the packet over the ECMP-aware shortest-path computed by the 242 IGP to the related prefix. The Prefix-SID is the SID of the IGP- 243 Prefix Segment. 245 IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which 246 does not identify a specific router, but a set of routers. The terms 247 "Anycast Segment" or "Anycast-SID" are often used as an abbreviation. 249 IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to 250 an unidirectional adjacency or a set of unidirectional adjacencies. 251 By default, an IGP-Adjacency Segment is local (unless explicitly 252 advertised otherwise) to the node that advertises it. 254 IGP-Node: an IGP-Node Segment is an IGP-Prefix Segment which 255 identifies a specific router (e.g. a loopback). The terms "Node 256 Segment" or Node-SID" are often used as an abbreviation. 258 SR Tunnel: a list of segments to be pushed on the packets directed on 259 the tunnel. The list of segments can be specified explicitly or 260 implicitly via a set of abstract constraints (latency, affinity, 261 SRLG, ...). In the latter case, a constraint-based path computation 262 is used to determine the list of segments associated with the tunnel. 263 The computation can be local or delegated to a PCE server. An SR 264 tunnel can be configured by the operator, provisioned via netconf or 265 provisioned via PCEP. An SR tunnel can be used for traffic- 266 engineering, OAM or FRR reasons. 268 Segment List Depth: the number of segments of an SR tunnel. The 269 entity instantiating an SR Tunnel at a node N should be able to 270 discover the depth insertion capability of the node N. The PCEP 271 discovery capability is described in [I-D.ietf-pce-segment-routing]. 273 3. Link-State IGP Segments 275 Within a link-state IGP domain, an SR-capable IGP node advertises 276 segments for its attached prefixes and adjacencies. These segments 277 are called IGP segments or IGP SIDs. They play a key role in Segment 278 Routing and use-cases as they enable the expression of any 279 topological path throughout the IGP domain. Such a topological path 280 is either expressed as a single IGP segment or a list of multiple IGP 281 segments. 283 3.1. IGP Segment, IGP SID 285 The terms "IGP Segment" and "IGP SID" are the generic names for a 286 segment attached to a piece of information advertised by a link-state 287 IGP, e.g. an IGP prefix or an IGP adjacency. 289 3.2. IGP-Prefix Segment, Prefix-SID 291 An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. 292 An IGP-Prefix Segment is always global within the SR/IGP domain and 293 identifies the ECMP-aware shortest-path computed by the IGP to the 294 related prefix. The Prefix-SID is the SID of the IGP-Prefix Segment. 296 A packet injected anywhere within the SR/IGP domain with an active 297 Prefix-SID will be forwarded along the shortest-path to that prefix. 299 The IGP signaling extension for IGP-Prefix segment includes a set of 300 flags. The encoding details of the Prefix-SID and its flags are 301 described in IGP SR extensions documents. 303 The IGP signaling extension for IGP-Prefix segment includes the 304 P-Flag. A Node N advertising a Prefix-SID SID-R for its attached 305 prefix R resets the P-Flag to allow its connected neighbors to 306 perform the NEXT operation while processing SID-R. This behavior is 307 equivalent to Penultimate Hop Popping in MPLS. When set, the 308 neighbors of N must perform the CONTINUE operation while processing 309 SID-R. 311 While SR allows to attach a local segment to an IGP prefix (using the 312 L-Flag), we specifically assume that when the terms "IGP-Prefix 313 Segment" and "Prefix-SID" are used, the segment is global (the SID is 314 allocated from the SRGB). This is consistent with all the described 315 use-cases that 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 IGP SR extensions 322 documents). However, each prefix-SID MUST be associated with only 323 one topology. In other words: a prefix, within a topology, MUST have 324 only a single Prefix-SID. 326 A Prefix-SID is allocated from the SRGB according to a process 327 similar to IP address allocation. Typically the Prefix-SID is 328 allocated by policy by the operator (or NMS) and the SID very rarely 329 changes. 331 The allocation process MUST NOT allocate the same Prefix-SID to 332 different IP prefixes. 334 If a node learns a Prefix-SID having a value that falls outside the 335 locally configured SRGB range, then the node MUST NOT use the Prefix- 336 SID and SHOULD issue an error log warning for misconfiguration. 338 The required IGP protocol extensions are defined in IGP SR extensions 339 documents. 341 A node N attaching a Prefix-SID SID-R to its attached prefix R MUST 342 maintain the following FIB entry: 343 Incoming Active Segment: SID-R 344 Ingress Operation: NEXT 345 Egress interface: NULL 347 A remote node M MUST maintain the following FIB entry for any learned 348 Prefix-SID SID-R attached to IP prefix R: 349 Incoming Active Segment: SID-R 350 Ingress Operation: 351 If the next-hop of R is the originator of R 352 and instructed to remove the active segment: NEXT 353 Else: CONTINUE 354 Egress interface: the interface towards the next-hop along 355 the shortest-path to prefix R. 357 3.3. IGP-Node Segment, Node-SID 359 An IGP-Node Segment is a an IGP-Prefix Segment which identifies a 360 specific router (e.g. a loopback). The N flag is set. The terms 361 "Node Segment" or "Node-SID" are often used as an abbreviation. 363 A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere 364 in the network, it enforces the ECMP-aware shortest-path forwarding 365 of the packet towards the related node. 367 An IGP-Node-SID MUST NOT be associated with a prefix that is owned or 368 advertised by more than one router within the same routing domain. 370 3.4. IGP-Anycast Segment, Anycast SID 372 An IGP-Anycast Segment is an IGP-prefix segment which does not 373 identify a specific router, but a set of routers. The terms "Anycast 374 Segment" or "Anycast-SID" are often used as an abbreviation. 376 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 377 shortest-path forwarding towards the closest node of the anycast set. 378 This is useful to express macro-engineering policies or protection 379 mechanisms. 381 An IGP-Anycast Segment MUST NOT reference a particular node. 383 Within an anycast group, all routers MUST advertise the same prefix 384 with the same SID value. 386 +--------------+ 387 | Group A | 388 | 192.0.1.1/32 | 389 | SID:100 | 390 | | 391 +-----------A1---A3----------+ 392 | | | \ / | | | 393 SID:10 | | | / | | | SID:30 394 1.1.1.1/32 | | | / \ | | | 1.1.1.3/32 395 PE1------R1----------A2---A4---------R3------PE3 396 \ /| | | |\ / 397 \ / | +--------------+ | \ / 398 \ / | | \ / 399 / | | / 400 / \ | | / \ 401 / \ | +--------------+ | / \ 402 / \| | | |/ \ 403 PE2------R2----------B1---B3----+----R4------PE4 404 1.1.1.2/32 | | | \ / | | | 1.1.1.4/32 405 SID:20 | | | / | | | SID:40 406 | | | / \ | | | 407 +-----+-----B2---B4----+-----+ 408 | | 409 | Group B | 410 | 192.0.2.1/32 | 411 | SID:200 | 412 +--------------+ 414 Transit device groups 416 The figure above describes a network example with two groups of 417 transit devices. Group A consists of devices {A1, A2, A3 and A4}. 418 They are all provisioned with the anycast address 192.0.1.1/32 and 419 the anycast SID 100. 421 Similarly, group B consists of devices {B1, B2, B3 and B4} and are 422 all provisioned with the anycast address 192.0.1.2/32, anycast SID 423 200. In the above network topology, each PE device is connected to 424 two routers in each of the groups A and B. 426 PE1 can choose a particular transit device group when sending traffic 427 to PE3 or PE4. This will be done by pushing the anycast SID of the 428 group in the stack. 430 Processing the anycast, and subsequent segments, requires special 431 care. 433 Obviously, the value of the SID following the anycast SID MUST be 434 understood by all nodes advertising the same anycast segment. 435 +-------------------------+ 436 | Group A | 437 | 192.0.1.1/32 | 438 | SID:100 | 439 |-------------------------| 440 | | 441 | SRGB: SRGB: | 442 SID:10 |(1000-2000) (3000-4000)| SID:30 443 PE1---+ +-------A1-------------A3-------+ +---PE3 444 \ / | | \ / | | \ / 445 \ / | | +-----+ / | | \ / 446 SRGB: \ / | | \ / | | \ / SRGB: 447 (7000-8000) R1 | | \ | | R3 (6000-7000) 448 / \ | | / \ | | / \ 449 / \ | | +-----+ \ | | / \ 450 / \ | | / \ | | / \ 451 PE2---+ +-------A2-------------A4-------+ +---PE4 452 SID:20 | SRGB: SRGB: | SID:40 453 |(2000-3000) (4000-5000)| 454 | | 455 +-------------------------+ 457 Transit paths via anycast group A 459 Considering a MPLS deployment, in the above topology, if device PE1 460 (or PE2) requires to send a packet to the device PE3 (or PE4) it 461 needs to encapsulate the packet in a MPLS payload with the following 462 stack of labels. 464 o Label allocated by R1 for anycast SID 100 (outer label). 466 o Label allocated by the nearest router in group A for SID 30 (for 467 destination PE3). 469 While the first label is easy to compute, in this case since there 470 are more than one topologically nearest devices (A1 and A2), unless 471 A1 and A2 allocated the same label value to the same prefix, 472 determining the second label is impossible. Devices A1 and A2 may be 473 devices from different hardware vendors. If both don't allocate the 474 same label value for SID 30, it is impossible to use the anycast 475 group "A" as a transit anycast group towards PE3. Hence, PE1 (or 476 PE2) cannot compute an appropriate label stack to steer the packet 477 exclusively through the group A devices. Same holds true for devices 478 PE3 and PE4 when trying to send a packet to PE1 or PE2. 480 To ease the use of anycast segment in a short term, it is recommended 481 to configure the same SRGB on all nodes of a particular anycast 482 group. Using this method, as mentioned above, computation of the 483 label following the anycast segment is straightforward. 485 Using anycast segment without configuring the same SRGB on nodes 486 belonging to the same device group may lead to misrouting (in a MPLS 487 VPN deployment, some traffic may leak between VPNs). 489 3.5. IGP-Adjacency Segment, Adj-SID 491 An IGP-Adjacency Segment is an IGP segment attached to a 492 unidirectional adjacency or a set of unidirectional adjacencies. By 493 default, an IGP-Adjacency Segment is local to the node which 494 advertises it. However, an Adjacency Segment can be global if 495 advertised by the IGP as such. The SID of the IGP-Adjacency Segment 496 is called the Adj-SID. 498 The adjacency is formed by the local node (i.e., the node advertising 499 the adjacency in the IGP) and the remote node (i.e., the other end of 500 the adjacency). The local node MUST be an IGP node. The remote node 501 MAY be an adjacent IGP neighbor) or a non-adjacent neighbor (e.g.: a 502 Forwarding Adjacency, [RFC4206]). 504 A packet injected anywhere within the SR domain with a segment list 505 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 506 attached by node N to its adjacency over link L, will be forwarded 507 along the shortest-path to N and then be switched by N, without any 508 IP shortest-path consideration, towards link L. If the Adj-SID 509 identifies a set of adjacencies, then the node N load- balances the 510 traffic among the various members of the set. 512 Similarly, when using a global Adj-SID, a packet injected anywhere 513 within the SR domain with a segment list {SNL}, where SNL is a global 514 Adj-SID attached by node N to its adjacency over link L, will be 515 forwarded along the shortest-path to N and then be switched by N, 516 without any IP shortest-path consideration, towards link L. If the 517 Adj-SID identifies a set of adjacencies, then the node N load- 518 balances the traffic among the various members of the set. The use 519 of global Adj-SID allows to reduce the size of the segment list when 520 expressing a path at the cost of additional state (i.e.: the global 521 Adj-SID will be inserted by all routers within the area in their 522 forwarding table). 524 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 525 packet from a node towards a defined interface or set of interfaces. 526 This is key to theoretically prove that any path can be expressed as 527 a list of segments. 529 The encodings of the Adj-SID include the B-flag. When set, the Adj- 530 SID benefits from a local protection. 532 The encodings of the Adj-SID include the L-flag. When set, the Adj- 533 SID has local significance. By default the L-flag is set. 535 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 537 A node MAY allocate multiple Adj-SIDs to the same adjacency. An 538 example is where the adjacency is established over a bundle 539 interface. Each bundle member MAY have its own Adj-SID. 541 A node MAY allocate the same Adj-SID to multiple adjacencies. 543 Adjacency suppression MUST NOT be performed by the IGP. 545 A node MUST install a FIB entry for any Adj-SID of value V attached 546 to data-link L: 547 Incoming Active Segment: V 548 Operation: NEXT 549 Egress Interface: L 551 The Adj-SID implies, from the router advertising it, the forwarding 552 of the packet through the adjacency identified by the Adj-SID, 553 regardless its IGP/SPF cost. In other words, the use of Adjacency 554 Segments overrides the routing decision made by SPF algorithm. 556 3.5.1. Parallel Adjacencies 558 Adj-SIDs can be used in order to represent a set of parallel 559 interfaces between two adjacent routers. 561 A node MUST install a FIB entry for any locally originated Adjacency 562 Segment (Adj-SID) of value W attached to a set of link B with: 563 Incoming Active Segment: W 564 Ingress Operation: NEXT 565 Egress interface: loadbalance between any data-link within set B 567 When parallel adjacencies are used and associated to the same Adj- 568 SID, and in order to optimize the load balancing function, a "weight" 569 factor can be associated to the Adj-SID advertised with each 570 adjacency. The weight tells the ingress (or a SDN/orchestration 571 system) about the loadbalancing factor over the parallel adjacencies. 572 As shown in Figure 1, A and B are connected through two parallel 573 adjacencies 574 link-1 575 +--------+ 576 | | 577 S---A B---C 578 | | 579 +--------+ 580 link-2 582 Figure 1: Parallel Links and Adj-SIDs 584 Node A advertises following Adj-SIDs and weights: 586 o Link-1: Adj-SID 1000, weight: 1 588 o Link-2: Adj-SID 1000, weight: 2 590 Node S receives the advertisements of the parallel adjacencies and 591 understands that by using Adj-SID 1000 node A will loadbalance the 592 traffic across the parallel links (link-1 and link-2) according to a 593 1:2 ratio. 595 The weight value is advertised with the Adj-SID as defined in IGP SR 596 extensions documents. 598 3.5.2. LAN Adjacency Segments 600 In LAN subnetworks, link-state protocols define the concept of 601 Designated Router (DR, in OSPF) or Designated Intermediate System 602 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 603 that describe the LAN topology in a special routing update (OSPF 604 Type2 LSA or IS-IS Pseudonode LSP). 606 The difficulty with LANs is that each router only advertises its 607 connectivity to the DR/DIS and not to each other individual nodes in 608 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 609 are necessary in order for each router in the LAN to advertise an 610 Adj-SID associated to each neighbor in the LAN. These extensions are 611 defined in IGP SR extensions documents. 613 3.6. Binding Segment 615 3.6.1. Mapping Server 617 A Remote-Binding SID S advertised by the mapping server M for remote 618 prefix R attached to non-SR-capable node N signals the same 619 information as if N had advertised S as a Prefix-SID. Further 620 details are described in the SR/LDP interworking procedures 621 ([I-D.filsfils-spring-segment-routing-ldp-interop]. 623 The segment allocation and SRGB Maintenance rules are the same as 624 those defined for Prefix-SID. 626 3.6.2. Tunnel Headend 628 The segment allocation and SRGB Maintenance rules are the same as 629 those defined for Adj-SID. A tunnel attached to a head-end H acts as 630 an adjacency attached to H. 632 Note: an alternative would consist in representing tunnels as 633 forwarding-adjacencies ( [RFC4206]). In such case, the tunnel is 634 presented to the routing area as a routing adjacency and will be 635 considered as such by all area routers. The Remote-Binding SID is 636 preferred as it allows to advertise the presence of a tunnel without 637 influencing the LSDB and the SPF computation. 639 3.7. Inter-Area Considerations 641 In the following example diagram we assume an IGP deployed using 642 areas and where SR has been deployed. 644 ! ! 645 ! ! 646 B------C-----F----G-----K 647 / | | | 648 S---A/ | | | 649 \ | | | 650 \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) 651 ! ! 652 Area-1 ! Backbone ! Area 2 653 ! area ! 655 Figure 2: Inter-Area Topology Example 657 In area 2, node Z allocates Node-SID 150 to his local prefix 658 192.0.2.1/32. ABRs G and J will propagate the prefix into the 659 backbone area by creating a new instance of the prefix according to 660 normal inter-area/level IGP propagation rules. 662 Nodes C and I will apply the same behavior when leaking prefixes from 663 the backbone area down to area 1. Therefore, node S will see prefix 664 192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. 666 It therefore results that a Prefix-SID remains attached to its 667 related IGP Prefix through the inter-area process. 669 When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as 670 active segment and forward it to A. 672 When packet arrives at ABR I (or C), the ABR forwards the packet 673 according to the active segment (Node-SID(150)). Forwarding 674 continues across area borders, using the same Node-SID(150), until 675 the packet reaches its destination. 677 When an ABR propagates a prefix from one area to another it MUST set 678 the R-Flag. 680 4. BGP Peering Segments 682 In the context of BGP Egress Peer Engineering (EPE), as described in 683 [I-D.filsfils-spring-segment-routing-central-epe], an EPE enabled 684 Egress PE node MAY advertise segments corresponding to its attached 685 peers. These segments are called BGP peering segments or BGP Peering 686 SIDs. They enable the expression of source-routed inter-domain 687 paths. 689 An ingress border router of an AS may compose a list of segments to 690 steer a flow along a selected path within the AS, towards a selected 691 egress border router C of the AS and through a specific peer. At 692 minimum, a BGP Peering Engineering policy applied at an ingress PE 693 involves two segments: the Node SID of the chosen egress PE and then 694 the BGP Peering Segment for the chosen egress PE peer or peering 695 interface. 697 Hereafter, we will define three types of BGP peering segments/SID's: 698 PeerNodeSID, PeerAdjSID and PeerSetSID. 700 o PeerNode SID. A BGP PeerNode segment/SID is a local segment. At 701 the BGP node advertising it, its semantics is: 703 * SR header operation: NEXT. 705 * Next-Hop: the connected peering node to which the segment is 706 related. 708 o PeerAdj SID: A BGP PeerAdj segment/SID is a local segment. At the 709 BGP node advertising it, its semantics is: 711 * SR header operation: NEXT. 713 * Next-Hop: the peer connected through the interface to which the 714 segment is related. 716 o PeerSet SID. A BGP PeerSet segment/SID is a local segment. At 717 the BGP node advertising it, its semantics is: 719 * SR header operation: NEXT. 721 * Next-Hop: loadbalance across any connected interface to any 722 peer in the related group. 724 A peer set could be all the connected peers from the same AS or a 725 subset of these. A group could also span across AS. The group 726 definition is a policy set by the operator. 728 The BGP extensions necessary in order to signal these BGP peering 729 segments will be defined in a separate document. 731 5. Multicast 733 Segment Routing is defined for unicast. The application of the 734 source-route concept to Multicast is not in the scope of this 735 document. 737 6. IANA Considerations 739 This document does not require any action from IANA. 741 7. Security Considerations 743 This document doesn't introduce new security considerations when 744 applied to the MPLS dataplane. 746 There are a number of security concerns with source routing at the 747 IPv6 dataplane [RFC5095]. The new IPv6-based segment routing header 748 defined in [I-D.previdi-6man-segment-routing-header] and its 749 associated security measures address these concerns. The IPv6 750 Segment Routing Header is defined in a way that blind attacks are 751 never possible, i.e., attackers will be unable to send source routed 752 packets that get successfully processed, without being part of the 753 negations for setting up the source routes or being able to eavesdrop 754 legitimate source routed packets. In some networks this base level 755 security may be complemented with other mechanisms, such as packet 756 filtering, cryptographic security, etc. 758 8. Contributors 760 The following people have substantially contributed to the definition 761 of the Segment Routing architecture and to the editing of this 762 document: 764 Ahmed Bashandy 765 Cisco Systems, Inc. 766 Email: bashandy@cisco.com 767 Martin Horneffer 768 Deutsche Telekom 769 Email: Martin.Horneffer@telekom.de 770 Wim Henderickx 771 Alcatel-Lucent 772 Email: wim.henderickx@alcatel-lucent.com 773 Jeff Tantsura 774 Ericsson 775 Email: Jeff.Tantsura@ericsson.com 776 Edward Crabbe 777 Individual 778 Email: edward.crabbe@gmail.com 779 Igor Milojevic 780 Email: milojevicigor@gmail.com 781 Saku Ytti 782 TDC 783 Email: saku@ytti.fi 785 9. Acknowledgements 787 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 788 Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib, Hannes Gredler 789 and Pushpasis Sarkar for their comments and review of this document. 791 10. References 793 10.1. Normative References 795 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 796 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 797 RFC2119, March 1997, 798 . 800 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 801 Hierarchy with Generalized Multi-Protocol Label Switching 802 (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/ 803 RFC4206, October 2005, 804 . 806 10.2. Informative References 808 [I-D.filsfils-spring-segment-routing-central-epe] 809 Filsfils, C., Previdi, S., Patel, K., Aries, E., 810 shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment 811 Routing Centralized Egress Peer Engineering", 812 draft-filsfils-spring-segment-routing-central-epe-04 (work 813 in progress), July 2015. 815 [I-D.filsfils-spring-segment-routing-ldp-interop] 816 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 817 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 818 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 819 "Segment Routing interoperability with LDP", 820 draft-filsfils-spring-segment-routing-ldp-interop-03 (work 821 in progress), March 2015. 823 [I-D.filsfils-spring-segment-routing-msdc] 824 Filsfils, C., Previdi, S., Mitchell, J., Aries, E., 825 Lapukhov, P., Gaya, G., Afanasiev, D., Laberge, T., 826 Nkposong, E., Nanduri, M., Uttaro, J., and S. Ray, "BGP- 827 Prefix Segment in large-scale data centers", 828 draft-filsfils-spring-segment-routing-msdc-03 (work in 829 progress), July 2015. 831 [I-D.francois-spring-segment-routing-ti-lfa] 832 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 833 "Topology Independent Fast Reroute using Segment Routing", 834 draft-francois-spring-segment-routing-ti-lfa-01 (work in 835 progress), October 2014. 837 [I-D.geib-spring-oam-usecase] 838 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 839 case for a scalable and topology aware MPLS data plane 840 monitoring system", draft-geib-spring-oam-usecase-06 (work 841 in progress), July 2015. 843 [I-D.ietf-isis-segment-routing-extensions] 844 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 845 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 846 Extensions for Segment Routing", 847 draft-ietf-isis-segment-routing-extensions-05 (work in 848 progress), June 2015. 850 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 851 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 852 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 853 Extensions for Segment Routing", 854 draft-ietf-ospf-ospfv3-segment-routing-extensions-03 (work 855 in progress), June 2015. 857 [I-D.ietf-ospf-segment-routing-extensions] 858 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 859 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 860 Extensions for Segment Routing", 861 draft-ietf-ospf-segment-routing-extensions-05 (work in 862 progress), June 2015. 864 [I-D.ietf-pce-segment-routing] 865 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 866 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 867 "PCEP Extensions for Segment Routing", 868 draft-ietf-pce-segment-routing-05 (work in progress), 869 May 2015. 871 [I-D.ietf-spring-ipv6-use-cases] 872 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 873 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 874 "IPv6 SPRING Use Cases", 875 draft-ietf-spring-ipv6-use-cases-04 (work in progress), 876 March 2015. 878 [I-D.ietf-spring-problem-statement] 879 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 880 Horneffer, M., and R. Shakir, "SPRING Problem Statement 881 and Requirements", draft-ietf-spring-problem-statement-04 882 (work in progress), April 2015. 884 [I-D.ietf-spring-resiliency-use-cases] 885 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 886 "Use-cases for Resiliency in SPRING", 887 draft-ietf-spring-resiliency-use-cases-01 (work in 888 progress), March 2015. 890 [I-D.ietf-spring-segment-routing-mpls] 891 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 892 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 893 and E. Crabbe, "Segment Routing with MPLS data plane", 894 draft-ietf-spring-segment-routing-mpls-01 (work in 895 progress), May 2015. 897 [I-D.kumar-spring-sr-oam-requirement] 898 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 899 and S. Litkowski, "OAM Requirements for Segment Routing 900 Network", draft-kumar-spring-sr-oam-requirement-03 (work 901 in progress), March 2015. 903 [I-D.previdi-6man-segment-routing-header] 904 Previdi, S., Filsfils, C., Field, B., Leung, I., Aries, 905 E., Vyncke, E., and D. Lebrun, "IPv6 Segment Routing 906 Header (SRH)", 907 draft-previdi-6man-segment-routing-header-07 (work in 908 progress), July 2015. 910 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 911 of Type 0 Routing Headers in IPv6", RFC 5095, 912 DOI 10.17487/RFC5095, December 2007, 913 . 915 Authors' Addresses 917 Clarence Filsfils (editor) 918 Cisco Systems, Inc. 919 Brussels, 920 BE 922 Email: cfilsfil@cisco.com 924 Stefano Previdi (editor) 925 Cisco Systems, Inc. 926 Via Del Serafico, 200 927 Rome 00142 928 Italy 930 Email: sprevidi@cisco.com 932 Bruno Decraene 933 Orange 934 FR 936 Email: bruno.decraene@orange.com 938 Stephane Litkowski 939 Orange 940 FR 942 Email: stephane.litkowski@orange.com 944 Rob Shakir 945 Individual 947 Email: rjs@rob.sh