idnits 2.17.1 draft-ietf-spring-segment-routing-03.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 (May 28, 2015) is 3255 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-03 == 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-04 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-04 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-02 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-04 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-04 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-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-00 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-06 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 Cisco Systems, Inc. 5 Expires: November 29, 2015 B. Decraene 6 S. Litkowski 7 Orange 8 R. Shakir 9 British Telecom 10 May 28, 2015 12 Segment Routing Architecture 13 draft-ietf-spring-segment-routing-03 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 November 29, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 6 82 3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 6 83 3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 84 3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 8 85 3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 8 86 3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 9 87 3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 10 88 3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 11 89 3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 11 90 3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 12 91 3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 12 92 3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 12 93 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 13 94 5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 97 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 101 10.2. Informative References . . . . . . . . . . . . . . . . . 16 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 161 [I-D.filsfils-spring-segment-routing-use-cases], 162 [I-D.ietf-spring-ipv6-use-cases], 163 [I-D.ietf-spring-resiliency-use-cases], [I-D.geib-spring-oam-usecase] 164 and [I-D.kumar-spring-sr-oam-requirement]. 166 Segment Routing for MPLS dataplane is documented in 167 [I-D.ietf-spring-segment-routing-mpls]. 169 Segment Routing for IPv6 dataplane is documented in 170 [I-D.previdi-6man-segment-routing-header]. 172 IGP protocol extensions for Segment Routing are described in 173 [I-D.ietf-isis-segment-routing-extensions], 174 [I-D.ietf-ospf-segment-routing-extensions] and 175 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] referred in this 176 document as "IGP SR extensions documents". 178 The FRR solution for SR is documented in 179 [I-D.francois-spring-segment-routing-ti-lfa]. 181 The PCEP protocol extensions for Segment Routing are defined in 182 [I-D.ietf-pce-segment-routing]. 184 The interaction between SR/MPLS with other MPLS Signaling planes is 185 documented in [I-D.filsfils-spring-segment-routing-ldp-interop]. 187 2. Terminology 189 Segment: an instruction a node executes on the incoming packet (e.g.: 190 forward packet according to shortest path to destination, or, forward 191 packet through a specific interface, or, deliver the packet to a 192 given application/service instance). 194 SID: a Segment Identifier 196 Segment List: ordered list of SID's encoding the topological and 197 service source route of the packet. It is a stack of labels in the 198 MPLS architecture. It is an ordered list of IPv6 addresses in the 199 IPv6 architecture. 201 Active segment: the segment that MUST be used by the receiving router 202 to process the packet. It is identified by a pointer in the IPv6 203 architecture. It is the top label in the MPLS architecture. 205 PUSH: the insertion of a segment at the head of the Segment list. 207 NEXT: the active segment is completed, the next segment becomes 208 active. 210 CONTINUE: the active segment is not completed and hence remains 211 active. The CONTINUE instruction is implemented as the SWAP 212 instruction in the MPLS dataplane. 214 SR Global Block (SRGB): local property of an SR node. In the MPLS 215 architecture, SRGB is the set of local labels reserved for global 216 segments. In the IPv6 architecture, it is the set of locally 217 relevant IPv6 addresses. Using the same SRGB on all nodes within the 218 SR domain ease operations and troubleshooting and is expected to be a 219 deployment guideline. 221 Global Segment: the related instruction is supported by all the SR- 222 capable nodes in the domain. In the MPLS architecture, a Global 223 Segment has a globally-unique index. The related local label at a 224 given node N is found by adding the globally-unique index to the SRGB 225 of node N. In the IPv6 architecture, a global segment is a globally- 226 unique IPv6 address. 228 Local Segment: the related instruction is supported only by the node 229 originating it. In the MPLS architecture, this is a local label 230 outside the SRGB. In the IPv6 architecture, this is a link-local 231 address. 233 IGP Segment: the generic name for a segment attached to a piece of 234 information advertised by a link-state IGP, e.g. an IGP prefix or an 235 IGP adjacency. 237 IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP 238 segment attached to an IGP prefix. An IGP-Prefix Segment is always 239 global within the SR/IGP domain and identifies an instruction to 240 forward the packet over the ECMP-aware shortest-path computed by the 241 IGP to the related prefix. The Prefix-SID is the SID of the IGP- 242 Prefix Segment. 244 IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which 245 does not identify a specific router, but a set of routers. The terms 246 "Anycast Segment" or "Anycast-SID" are often used as an abbreviation. 248 IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to 249 an unidirectional adjacency or a set of unidirectional adjacencies. 250 By default, an IGP-Adjacency Segment is local (unless explicitly 251 advertised otherwise) to the node that advertises it. 253 IGP-Node: an IGP-Node Segment is an IGP-Prefix Segment which 254 identifies a specific router (e.g. a loopback). The terms "Node 255 Segment" or Node-SID" are often used as an abbreviation. 257 SR Tunnel: a list of segments to be pushed on the packets directed on 258 the tunnel. The list of segments can be specified explicitly or 259 implicitly via a set of abstract constraints (latency, affinity, 260 SRLG, ...). In the latter case, a constraint-based path computation 261 is used to determine the list of segments associated with the tunnel. 262 The computation can be local or delegated to a PCE server. An SR 263 tunnel can be configured by the operator, provisioned via netconf or 264 provisioned via PCEP. An SR tunnel can be used for traffic- 265 engineering, OAM or FRR reasons. 267 Segment List Depth: the number of segments of an SR tunnel. The 268 entity instantiating an SR Tunnel at a node N should be able to 269 discover the depth insertion capability of the node N. The PCEP 270 discovery capability is described in [I-D.ietf-pce-segment-routing]. 272 3. Link-State IGP Segments 274 Within a link-state IGP domain, an SR-capable IGP node advertises 275 segments for its attached prefixes and adjacencies. These segments 276 are called IGP segments or IGP SIDs. They play a key role in Segment 277 Routing and use-cases 278 ([I-D.filsfils-spring-segment-routing-use-cases]) as they enable the 279 expression of any topological path throughout the IGP domain. Such a 280 topological path is either expressed as a single IGP segment or a 281 list of multiple IGP 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 315 [I-D.filsfils-spring-segment-routing-use-cases] as all the described 316 use-cases require global segments attached to IGP prefixes. 318 A single Prefix-SID is allocated to an IGP Prefix in a topology. 320 In the context of multiple topologies, multiple Prefix-SID's MAY be 321 allocated to the same IGP Prefix (e.g.: using the "algorithm" field 322 in the IGP advertisement as described in IGP SR extensions 323 documents). However, each prefix-SID MUST be associated with only 324 one topology. In other words: a prefix, within a topology, MUST have 325 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 IGP SR extensions 340 documents. 342 A node N attaching a Prefix-SID SID-R to its attached prefix R MUST 343 maintain the following FIB entry: 345 Incoming Active Segment: SID-R 346 Ingress Operation: NEXT 347 Egress interface: NULL 349 A remote node M MUST maintain the following FIB entry for any learned 350 Prefix-SID SID-R attached to IP prefix R: 352 Incoming Active Segment: SID-R 353 Ingress Operation: 354 If the next-hop of R is the originator of R 355 and instructed to remove the active segment: NEXT 356 Else: CONTINUE 357 Egress interface: the interface towards the next-hop along 358 the shortest-path to prefix R. 360 3.3. IGP-Node Segment, Node-SID 362 An IGP-Node Segment is a an IGP-Prefix Segment which identifies a 363 specific router (e.g. a loopback). The N flag is set. The terms 364 "Node Segment" or "Node-SID" are often used as an abbreviation. 366 A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere 367 in the network, it enforces the ECMP-aware shortest- path forwarding 368 of the packet towards the related node as explained in 369 [I-D.filsfils-spring-segment-routing-use-cases]. 371 An IGP-Node-SID MUST NOT be associated with a prefix that is owned or 372 advertised by more than one router within the same routing domain. 374 3.4. IGP-Anycast Segment, Anycast SID 376 An IGP-Anycast Segment is an IGP-prefix segment which does not 377 identify a specific router, but a set of routers. The terms "Anycast 378 Segment" or "Anycast-SID" are often used as an abbreviation. 380 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 381 shortest-path forwarding towards the closest node of the anycast set. 382 This is useful to express macro-engineering policies or protection 383 mechanisms as described in 384 [I-D.filsfils-spring-segment-routing-use-cases]. 386 The Anycast SID MUST be advertised with the N-flag unset. 388 When anycast is used and multiple nodes advertise the same prefix 389 (with its SID), these nodes MUST use the same SRGB. 391 The SID following the anycast SID MUST be understood by all nodes 392 sharing the anycast SID. 394 3.5. IGP-Adjacency Segment, Adj-SID 396 An IGP-Adjacency Segment is an IGP segment attached to a 397 unidirectional adjacency or a set of unidirectional adjacencies. By 398 default, an IGP-Adjacency Segment is local to the node which 399 advertises it. However, an Adjacency Segment can be global if 400 advertised by the IGP as such. The SID of the IGP-Adjacency Segment 401 is called the Adj-SID. 403 The adjacency is formed by the local node (i.e., the node advertising 404 the adjacency in the IGP) and the remote node (i.e., the other end of 405 the adjacency). The local node MUST be an IGP node. The remote node 406 MAY be an adjacent IGP neighbor) or a non-adjacent neighbor (e.g.: a 407 Forwarding Adjacency, [RFC4206]). 409 A packet injected anywhere within the SR domain with a segment list 410 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 411 attached by node N to its adjacency over link L, will be forwarded 412 along the shortest-path to N and then be switched by N, without any 413 IP shortest-path consideration, towards link L. If the Adj-SID 414 identifies a set of adjacencies, then the node N load- balances the 415 traffic among the various members of the set. 417 Similarly, when using a global Adj-SID, a packet injected anywhere 418 within the SR domain with a segment list {SNL}, where SNL is a global 419 Adj-SID attached by node N to its adjacency over link L, will be 420 forwarded along the shortest-path to N and then be switched by N, 421 without any IP shortest-path consideration, towards link L. If the 422 Adj-SID identifies a set of adjacencies, then the node N load- 423 balances the traffic among the various members of the set. The use 424 of global Adj-SID allows to reduce the size of the segment list when 425 expressing a path at the cost of additional state (i.e.: the global 426 Adj-SID will be inserted by all routers within the area in their 427 forwarding table). 429 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 430 packet from a node towards a defined interface or set of interfaces. 432 This is key to theoretically prove that any path can be expressed as 433 a list of segments as explained in 434 [I-D.filsfils-spring-segment-routing-use-cases]. 436 The encodings of the Adj-SID include the B-flag. When set, the Adj- 437 SID benefits from a local protection. 439 The encodings of the Adj-SID include the L-flag. When set, the Adj- 440 SID has local significance. By default the L-flag is set. 442 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 444 A node MAY allocate multiple Adj-SIDs to the same adjacency. An 445 example is where the adjacency is established over a bundle 446 interface. Each bundle member MAY have its own Adj-SID. 448 A node MAY allocate the same Adj-SID to multiple adjacencies. 450 Adjacency suppression MUST NOT be performed by the IGP. 452 A node MUST install a FIB entry for any Adj-SID of value V attached 453 to data-link L: 455 Incoming Active Segment: V 456 Operation: NEXT 457 Egress Interface: L 459 The Adj-SID implies, from the router advertising it, the forwarding 460 of the packet through the adjacency identified by the Adj-SID, 461 regardless its IGP/SPF cost. In other words, the use of Adjacency 462 Segments overrides the routing decision made by SPF algorithm. 464 3.5.1. Parallel Adjacencies 466 Adj-SIDs can be used in order to represent a set of parallel 467 interfaces between two adjacent routers. 469 A node MUST install a FIB entry for any locally originated Adjacency 470 Segment (Adj-SID) of value W attached to a set of link B with: 472 Incoming Active Segment: W 473 Ingress Operation: NEXT 474 Egress interface: loadbalance between any data-link within set B 476 When parallel adjacencies are used and associated to the same Adj- 477 SID, and in order to optimize the load balancing function, a "weight" 478 factor can be associated to the Adj-SID advertised with each 479 adjacency. The weight tells the ingress (or a SDN/orchestration 480 system) about the loadbalancing factor over the parallel adjacencies. 481 As shown in Figure 1, A and B are connected through two parallel 482 adjacencies 484 link-1 485 +--------+ 486 | | 487 S---A B---C 488 | | 489 +--------+ 490 link-2 492 Figure 1: Parallel Links and Adj-SIDs 494 Node A advertises following Adj-SIDs and weights: 496 o Link-1: Adj-SID 1000, weight: 1 498 o Link-2: Adj-SID 1000, weight: 2 500 Node S receives the advertisements of the parallel adjacencies and 501 understands that by using Adj-SID 1000 node A will loadbalance the 502 traffic across the parallel links (link-1 and link-2) according to a 503 1:2 ratio. 505 The weight value is advertised with the Adj-SID as defined in IGP SR 506 extensions documents. 508 3.5.2. LAN Adjacency Segments 510 In LAN subnetworks, link-state protocols define the concept of 511 Designated Router (DR, in OSPF) or Designated Intermediate System 512 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 513 that describe the LAN topology in a special routing update (OSPF 514 Type2 LSA or IS-IS Pseudonode LSP). 516 The difficulty with LANs is that each router only advertises its 517 connectivity to the DR/DIS and not to each other individual nodes in 518 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 519 are necessary in order for each router in the LAN to advertise an 520 Adj-SID associated to each neighbor in the LAN. These extensions are 521 defined in IGP SR extensions documents. 523 3.6. Binding Segment 524 3.6.1. Mapping Server 526 A Remote-Binding SID S advertised by the mapping server M for remote 527 prefix R attached to non-SR-capable node N signals the same 528 information as if N had advertised S as a Prefix-SID. Further 529 details are described in the SR/LDP interworking procedures 530 ([I-D.filsfils-spring-segment-routing-ldp-interop]. 532 The segment allocation and SRGB Maintenance rules are the same as 533 those defined for Prefix-SID. 535 3.6.2. Tunnel Headend 537 The segment allocation and SRGB Maintenance rules are the same as 538 those defined for Adj-SID. A tunnel attached to a head-end H acts as 539 an adjacency attached to H. 541 Note: an alternative would consist in representing tunnels as 542 forwarding-adjacencies ( [RFC4206]). In such case, the tunnel is 543 presented to the routing area as a routing adjacency and will be 544 considered as such by all area routers. The Remote-Binding SID is 545 preferred as it allows to advertise the presence of a tunnel without 546 influencing the LSDB and the SPF computation. 548 3.7. Inter-Area Considerations 550 In the following example diagram we assume an IGP deployed using 551 areas and where SR has been deployed. 553 ! ! 554 ! ! 555 B------C-----F----G-----K 556 / | | | 557 S---A/ | | | 558 \ | | | 559 \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) 560 ! ! 561 Area-1 ! Backbone ! Area 2 562 ! area ! 564 Figure 2: Inter-Area Topology Example 566 In area 2, node Z allocates Node-SID 150 to his local prefix 567 192.0.2.1/32. ABRs G and J will propagate the prefix into the 568 backbone area by creating a new instance of the prefix according to 569 normal inter-area/level IGP propagation rules. 571 Nodes C and I will apply the same behavior when leaking prefixes from 572 the backbone area down to area 1. Therefore, node S will see prefix 573 192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. 575 It therefore results that a Prefix-SID remains attached to its 576 related IGP Prefix through the inter-area process. 578 When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as 579 active segment and forward it to A. 581 When packet arrives at ABR I (or C), the ABR forwards the packet 582 according to the active segment (Node-SID(150)). Forwarding 583 continues across area borders, using the same Node-SID(150), until 584 the packet reaches its destination. 586 When an ABR propagates a prefix from one area to another it MUST set 587 the R-Flag. 589 4. BGP Peering Segments 591 In the context of BGP Egress Peer Engineering (EPE), as described in 592 [I-D.filsfils-spring-segment-routing-central-epe], an EPE enabled 593 Egress PE node MAY advertise segments corresponding to its attached 594 peers. These segments are called BGP peering segments or BGP Peering 595 SIDs. They enable the expression of source-routed inter-domain 596 paths. 598 An ingress border router of an AS may compose a list of segments to 599 steer a flow along a selected path within the AS, towards a selected 600 egress border router C of the AS and through a specific peer. At 601 minimum, a BGP Peering Engineering policy applied at an ingress PE 602 involves two segments: the Node SID of the chosen egress PE and then 603 the BGP Peering Segment for the chosen egress PE peer or peering 604 interface. 606 Hereafter, we will define three types of BGP peering segments/SID's: 607 PeerNodeSID, PeerAdjSID and PeerSetSID. 609 o PeerNode SID. A BGP PeerNode segment/SID is a local segment. At 610 the BGP node advertising it, its semantics is: 612 * SR header operation: NEXT. 614 * Next-Hop: the connected peering node to which the segment is 615 related. 617 o PeerAdj SID: A BGP PeerAdj segment/SID is a local segment. At the 618 BGP node advertising it, its semantics is: 620 * SR header operation: NEXT. 622 * Next-Hop: the peer connected through the interface to which the 623 segment is related. 625 o PeerSet SID. A BGP PeerSet segment/SID is a local segment. At 626 the BGP node advertising it, its semantics is: 628 * SR header operation: NEXT. 630 * Next-Hop: loadbalance across any connected interface to any 631 peer in the related group. 633 A peer set could be all the connected peers from the same AS or a 634 subset of these. A group could also span across AS. The group 635 definition is a policy set by the operator. 637 The BGP extensions necessary in order to signal these BGP peering 638 segments will be defined in a separate document. 640 5. Multicast 642 Segment Routing is defined for unicast. The application of the 643 source-route concept to Multicast is not in the scope of this 644 document. 646 6. IANA Considerations 648 This document does not require any action from IANA. 650 7. Security Considerations 652 This document doesn't introduce new security considerations when 653 applied to the MPLS dataplane. 655 There are a number of security concerns with source routing at the 656 IPv6 dataplane [RFC5095]. The new IPv6-based segment routing header 657 defined in [I-D.previdi-6man-segment-routing-header] and its 658 associated security measures described in 659 [I-D.vyncke-6man-segment-routing-security] address these concerns. 660 The IPv6 Segment Routing Header is defined in a way that blind 661 attacks are never possible, i.e., attackers will be unable to send 662 source routed packets that get successfully processed, without being 663 part of the negations for setting up the source routes or being able 664 to eavesdrop legitimate source routed packets. In some networks this 665 base level security may be complemented with other mechanisms, such 666 as packet filtering, cryptographic security, etc. 668 8. Contributors 670 The following people have substantially contributed to the definition 671 of the Segment Routing architecture and to the editing of this 672 document: 674 Ahmed Bashandy 675 Cisco Systems, Inc. 676 Email: bashandy@cisco.com 678 Martin Horneffer 679 Deutsche Telekom 680 Email: Martin.Horneffer@telekom.de 682 Wim Henderickx 683 Alcatel-Lucent 684 Email: wim.henderickx@alcatel-lucent.com 686 Jeff Tantsura 687 Ericsson 688 Email: Jeff.Tantsura@ericsson.com 690 Edward Crabbe 691 Individual 692 Email: edward.crabbe@gmail.com 694 Igor Milojevic 695 Email: milojevicigor@gmail.com 697 Saku Ytti 698 TDC 699 Email: saku@ytti.fi 701 9. Acknowledgements 703 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 704 Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes 705 Gredler for their comments and review of this document. 707 10. References 709 10.1. Normative References 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, March 1997. 714 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 715 Hierarchy with Generalized Multi-Protocol Label Switching 716 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 718 10.2. Informative References 720 [I-D.filsfils-spring-segment-routing-central-epe] 721 Filsfils, C., Previdi, S., Patel, K., Aries, E., 722 shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment 723 Routing Centralized Egress Peer Engineering", draft- 724 filsfils-spring-segment-routing-central-epe-03 (work in 725 progress), January 2015. 727 [I-D.filsfils-spring-segment-routing-ldp-interop] 728 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 729 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 730 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 731 "Segment Routing interoperability with LDP", draft- 732 filsfils-spring-segment-routing-ldp-interop-03 (work in 733 progress), March 2015. 735 [I-D.filsfils-spring-segment-routing-use-cases] 736 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 737 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 738 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 739 Crabbe, "Segment Routing Use Cases", draft-filsfils- 740 spring-segment-routing-use-cases-01 (work in progress), 741 October 2014. 743 [I-D.francois-spring-segment-routing-ti-lfa] 744 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 745 "Topology Independent Fast Reroute using Segment Routing", 746 draft-francois-spring-segment-routing-ti-lfa-01 (work in 747 progress), October 2014. 749 [I-D.geib-spring-oam-usecase] 750 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 751 case for a scalable and topology aware MPLS data plane 752 monitoring system", draft-geib-spring-oam-usecase-04 (work 753 in progress), March 2015. 755 [I-D.ietf-isis-segment-routing-extensions] 756 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 757 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 758 Extensions for Segment Routing", draft-ietf-isis-segment- 759 routing-extensions-04 (work in progress), May 2015. 761 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 762 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 763 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 764 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 765 segment-routing-extensions-02 (work in progress), February 766 2015. 768 [I-D.ietf-ospf-segment-routing-extensions] 769 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 770 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 771 Extensions for Segment Routing", draft-ietf-ospf-segment- 772 routing-extensions-04 (work in progress), February 2015. 774 [I-D.ietf-pce-segment-routing] 775 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 776 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 777 "PCEP Extensions for Segment Routing", draft-ietf-pce- 778 segment-routing-04 (work in progress), May 2015. 780 [I-D.ietf-spring-ipv6-use-cases] 781 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 782 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 783 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 784 cases-04 (work in progress), March 2015. 786 [I-D.ietf-spring-resiliency-use-cases] 787 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 788 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 789 resiliency-use-cases-01 (work in progress), March 2015. 791 [I-D.ietf-spring-segment-routing-mpls] 792 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 793 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 794 and E. Crabbe, "Segment Routing with MPLS data plane", 795 draft-ietf-spring-segment-routing-mpls-00 (work in 796 progress), December 2014. 798 [I-D.kumar-spring-sr-oam-requirement] 799 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 800 and S. Litkowski, "OAM Requirements for Segment Routing 801 Network", draft-kumar-spring-sr-oam-requirement-03 (work 802 in progress), March 2015. 804 [I-D.previdi-6man-segment-routing-header] 805 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 806 Segment Routing Header (SRH)", draft-previdi-6man-segment- 807 routing-header-06 (work in progress), May 2015. 809 [I-D.vyncke-6man-segment-routing-security] 810 Vyncke, E., Previdi, S., and D. Lebrun, "IPv6 Segment 811 Routing Security Considerations", draft-vyncke-6man- 812 segment-routing-security-02 (work in progress), February 813 2015. 815 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 816 of Type 0 Routing Headers in IPv6", RFC 5095, December 817 2007. 819 Authors' Addresses 821 Clarence Filsfils (editor) 822 Cisco Systems, Inc. 823 Brussels 824 BE 826 Email: cfilsfil@cisco.com 828 Stefano Previdi (editor) 829 Cisco Systems, Inc. 830 Via Del Serafico, 200 831 Rome 00142 832 Italy 834 Email: sprevidi@cisco.com 836 Bruno Decraene 837 Orange 838 FR 840 Email: bruno.decraene@orange.com 842 Stephane Litkowski 843 Orange 844 FR 846 Email: stephane.litkowski@orange.com 847 Rob Shakir 848 British Telecom 849 London 850 UK 852 Email: rob.shakir@bt.com