idnits 2.17.1 draft-ietf-spring-segment-routing-01.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 (February 5, 2015) is 3368 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 (-25) exists of draft-ietf-isis-segment-routing-extensions-03 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-00 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-04 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-05 == Outdated reference: A later version (-02) exists of draft-vyncke-6man-segment-routing-security-01 == Outdated reference: A later version (-05) exists of draft-filsfils-spring-segment-routing-central-epe-03 == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-02 == Outdated reference: A later version (-02) exists of draft-francois-spring-segment-routing-ti-lfa-01 == Outdated reference: A later version (-06) exists of draft-geib-spring-oam-usecase-03 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-00 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-03 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-00 == Outdated reference: A later version (-03) exists of draft-kumar-spring-sr-oam-requirement-02 Summary: 0 errors (**), 0 flaws (~~), 15 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: August 9, 2015 Cisco Systems, Inc. 6 B. Decraene 7 S. Litkowski 8 Orange 9 M. Horneffer 10 Deutsche Telekom 11 R. Shakir 12 British Telecom 13 J. Tantsura 14 Ericsson 15 E. Crabbe 16 Individual 17 February 5, 2015 19 Segment Routing Architecture 20 draft-ietf-spring-segment-routing-01 22 Abstract 24 Segment Routing (SR) leverages the source routing paradigm. A node 25 steers a packet through an ordered list of instructions, called 26 segments. A segment can represent any instruction, topological or 27 service-based. A segment can have a local semantic to an SR node or 28 global within an SR domain. SR allows to enforce a flow through any 29 topological path and service chain while maintaining per-flow state 30 only at the ingress node to the SR domain. 32 Segment Routing can be directly applied to the MPLS architecture with 33 no change on the forwarding plane. A segment is encoded as an MPLS 34 label. An ordered list of segments is encoded as a stack of labels. 35 The segment to process is on the top of the stack. Upon completion 36 of a segment, the related label is popped from the stack. 38 Segment Routing can be applied to the IPv6 architecture, with a new 39 type of routing extension header. A segment is encoded as an IPv6 40 address. An ordered list of segments is encoded as an ordered list 41 of IPv6 addresses in the routing extension header. The segment to 42 process is indicated by a pointer in the routing extension header. 43 Upon completion of a segment, the pointer is incremented. 45 Requirements Language 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [RFC2119]. 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at http://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on August 9, 2015. 68 Copyright Notice 70 Copyright (c) 2015 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4 87 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 88 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 6 89 3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 7 90 3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 91 3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 8 92 3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 9 93 3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 9 94 3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 10 95 3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 11 96 3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 12 97 3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 12 98 3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 12 99 3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 12 100 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 13 101 5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 14 102 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 108 10.2. Informative References . . . . . . . . . . . . . . . . . 16 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 111 1. Introduction 113 With Segment Routing (SR), a node steers a packet through an ordered 114 list of instructions, called segments. A segment can represent any 115 instruction, topological or service-based. A segment can have a 116 local semantic to an SR node or global within an SR domain. SR 117 allows to enforce a flow through any path and service chain while 118 maintaining per-flow state only at the ingress node of the SR domain. 120 Segment Routing can be directly applied to the MPLS architecture (RFC 121 3031) with no change on the forwarding plane. A segment is encoded 122 as an MPLS label. An ordered list of segments is encoded as a stack 123 of labels. The active segment is on the top of the stack. A 124 completed segment is popped off the stack. The addition of a segment 125 is performed with a push. 127 In the Segment Routing MPLS instantiation, a segment could be of 128 several types: 130 o an IGP segment, 132 o a BGP Peering segments, 134 o an LDP LSP segment, 136 o an RSVP-TE LSP segment, 138 o a BGP LSP segment. 140 The first two (IGP and BGP Peering segments) types of segments 141 defined in this document. The use of the last three types of 142 segments is illustrated in [I-D.ietf-spring-segment-routing-mpls]. 144 Segment Routing can be applied to the IPv6 architecture (RFC2460), 145 with a new type of routing extension header. A segment is encoded as 146 an IPv6 address. An ordered list of segments is encoded as an 147 ordered list of IPv6 addresses in the routing extension header. The 148 active segment is indicated by a pointer in the routing extension 149 header. Upon completion of a segment, the pointer is incremented. A 150 segment can be inserted in the list and the pointer is updated 151 accordingly. 153 Numerous use-cases illustrate the benefits of source routing either 154 for FRR, OAM or Traffic Engineering reasons. 156 This document defines a set of instructions (called segments) that 157 are required to fulfill the described use-cases. These segments can 158 either be used in isolation (one single segment defines the source 159 route of the packet) or in combination (these segments are part of an 160 ordered list of segments that define the source route of the packet). 162 1.1. Companion Documents 164 This document defines the SR architecture, its routing model, the 165 IGP-based segments, the BGP-based segments and the service segments. 167 Use cases are described in 168 [I-D.filsfils-spring-segment-routing-use-cases], 169 [I-D.ietf-spring-ipv6-use-cases], 170 [I-D.ietf-spring-resiliency-use-cases], [I-D.geib-spring-oam-usecase] 171 and [I-D.kumar-spring-sr-oam-requirement]. 173 Segment Routing for MPLS dataplane is documented in 174 [I-D.ietf-spring-segment-routing-mpls]. 176 Segment Routing for IPv6 dataplane is documented in 177 [I-D.previdi-6man-segment-routing-header]. 179 IGP protocol extensions for Segment Routing are described in 180 [I-D.ietf-isis-segment-routing-extensions], 181 [I-D.ietf-ospf-segment-routing-extensions] and 182 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] referred in this 183 document as "IGP SR extensions documents". 185 The FRR solution for SR is documented in 186 [I-D.francois-spring-segment-routing-ti-lfa]. 188 The PCEP protocol extensions for Segment Routing are defined in 189 [I-D.ietf-pce-segment-routing]. 191 The interaction between SR/MPLS with other MPLS Signaling planes is 192 documented in [I-D.filsfils-spring-segment-routing-ldp-interop]. 194 2. Terminology 196 Segment: an instruction a node executes on the incoming packet (e.g.: 197 forward packet according to shortest path to destination, or, forward 198 packet through a specific interface, or, deliver the packet to a 199 given application/service instance). 201 SID: a Segment Identifier 203 Segment List: ordered list of SID's encoding the topological and 204 service source route of the packet. It is a stack of labels in the 205 MPLS architecture. It is an ordered list of IPv6 addresses in the 206 IPv6 architecture. 208 Active segment: the segment that MUST be used by the receiving router 209 to process the packet. It is identified by a pointer in the IPv6 210 architecture. It is the top label in the MPLS architecture. 212 PUSH: the insertion of a segment at the head of the Segment list. 214 NEXT: the active segment is completed, the next segment becomes 215 active. 217 CONTINUE: the active segment is not completed and hence remains 218 active. The CONTINUE instruction is implemented as the SWAP 219 instruction in the MPLS dataplane. 221 SR Global Block (SRGB): local property of an SR node. In the MPLS 222 architecture, SRGB is the set of local labels reserved for global 223 segments. In the IPv6 architecture, it is the set of locally 224 relevant IPv6 addresses. 226 Global Segment: the related instruction is supported by all the SR- 227 capable nodes in the domain. In the MPLS architecture, a Global 228 Segment has a globally-unique index. The related local label at a 229 given node N is found by adding the globally-unique index to the SRGB 230 of node N. In the IPv6 architecture, a global segment is a globally- 231 unique IPv6 address. 233 Local Segment: the related instruction is supported only by the node 234 originating it. In the MPLS architecture, this is a local label 235 outside the SRGB. In the IPv6 architecture, this is a link-local 236 address. 238 IGP Segment: the generic name for a segment attached to a piece of 239 information advertised by a link-state IGP, e.g. an IGP prefix or an 240 IGP adjacency. 242 IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP 243 segment attached to an IGP prefix. An IGP-Prefix Segment is always 244 global within the SR/IGP domain and identifies an instruction to 245 forward the packet over the ECMP-aware shortest-path computed by the 246 IGP to the related prefix. The Prefix-SID is the SID of the IGP- 247 Prefix Segment. 249 IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which 250 does not identify a specific router, but a set of routers. The terms 251 "Anycast Segment" or "Anycast-SID" are often used as an abbreviation. 253 IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to 254 an unidirectional adjacency or a set of unidirectional adjacencies. 255 By default, an IGP-Adjacency Segment is local (unless explicitly 256 advertised otherwise) to the node that advertises it. 258 IGP-Node: an IGP-Node Segment is an IGP-Prefix Segment which 259 identifies a specific router (e.g. a loopback). The terms "Node 260 Segment" or Node-SID" are often used as an abbreviation. 262 SR Tunnel: a list of segments to be pushed on the packets directed on 263 the tunnel. The list of segments can be specified explicitly or 264 implicitly via a set of abstract constraints (latency, affinity, 265 SRLG, ...). In the latter case, a constraint-based path computation 266 is used to determine the list of segments associated with the tunnel. 267 The computation can be local or delegated to a PCE server. An SR 268 tunnel can be configured by the operator, provisioned via netconf or 269 provisioned via PCEP. An SR tunnel can be used for traffic- 270 engineering, OAM or FRR reasons. 272 Segment List Depth: the number of segments of an SR tunnel. The 273 entity instantiating an SR Tunnel at a node N should be able to 274 discover the depth insertion capability of the node N. The PCEP 275 discovery capability is described in [I-D.ietf-pce-segment-routing]. 277 3. Link-State IGP Segments 279 Within a link-state IGP domain, an SR-capable IGP node advertises 280 segments for its attached prefixes and adjacencies. These segments 281 are called IGP segments or IGP SIDs. They play a key role in Segment 282 Routing and use-cases 283 ([I-D.filsfils-spring-segment-routing-use-cases]) as they enable the 284 expression of any topological path throughout the IGP domain. Such a 285 topological path is either expressed as a single IGP segment or a 286 list of multiple IGP segments. 288 3.1. IGP Segment, IGP SID 290 The terms "IGP Segment" and "IGP SID" are the generic names for a 291 segment attached to a piece of information advertised by a link-state 292 IGP, e.g. an IGP prefix or an IGP adjacency. 294 3.2. IGP-Prefix Segment, Prefix-SID 296 An IGP-Prefix Segment is an IGP segment attached to an IGP prefix. 297 An IGP-Prefix Segment is always global within the SR/IGP domain and 298 identifies the ECMP-aware shortest-path computed by the IGP to the 299 related prefix. The Prefix-SID is the SID of the IGP-Prefix Segment. 301 A packet injected anywhere within the SR/IGP domain with an active 302 Prefix-SID will be forwarded along the shortest-path to that prefix. 304 The IGP signaling extension for IGP-Prefix segment includes a set of 305 flags. The encoding details of the Prefix-SID and its flags are 306 described in IGP SR extensions documents. 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 IGP SR extensions 328 documents). However, each prefix-SID MUST be associated with only 329 one topology. In other words: a prefix, within a topology, MUST have 330 only a single Prefix-SID. 332 A Prefix-SID is allocated from the SRGB according to a process 333 similar to IP address allocation. Typically the Prefix-SID is 334 allocated by policy by the operator (or NMS) and the SID very rarely 335 changes. 337 The allocation process MUST NOT allocate the same Prefix-SID to 338 different IP prefixes. 340 If a node learns a Prefix-SID having a value that falls outside the 341 locally configured SRGB range, then the node MUST NOT use the Prefix- 342 SID and SHOULD issue an error log warning for misconfiguration. 344 The required IGP protocol extensions are defined in IGP SR extensions 345 documents. 347 A node N attaching a Prefix-SID SID-R to its attached prefix R MUST 348 maintain the following FIB entry: 350 Incoming Active Segment: SID-R 351 Ingress Operation: NEXT 352 Egress interface: NULL 354 A remote node M MUST maintain the following FIB entry for any learned 355 Prefix-SID SID-R attached to IP prefix R: 357 Incoming Active Segment: SID-R 358 Ingress Operation: 359 If the next-hop of R is the originator of R 360 and instructed to remove the active segment: NEXT 361 Else: CONTINUE 362 Egress interface: the interface towards the next-hop along 363 the shortest-path to prefix R. 365 3.3. IGP-Node Segment, Node-SID 367 An IGP-Node Segment is a an IGP-Prefix Segment which identifies a 368 specific router (e.g. a loopback). The N flag is set. The terms 369 "Node Segment" or "Node-SID" are often used as an abbreviation. 371 A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere 372 in the network, it enforces the ECMP-aware shortest- path forwarding 373 of the packet towards the related node as explained in 374 [I-D.filsfils-spring-segment-routing-use-cases]. 376 An IGP-Node-SID MUST NOT be associated with a prefix that is owned or 377 advertised by more than one router within the same routing domain. 379 3.4. IGP-Anycast Segment, Anycast SID 381 An IGP-Anycast Segment is an IGP-prefix segment which does not 382 identify a specific router, but a set of routers. The terms "Anycast 383 Segment" or "Anycast-SID" are often used as an abbreviation. 385 An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware 386 shortest-path forwarding towards the closest node of the anycast set. 387 This is useful to express macro-engineering policies or protection 388 mechanisms as described in 389 [I-D.filsfils-spring-segment-routing-use-cases]. 391 The Anycast SID MUST be advertised with the N-flag unset. 393 3.5. IGP-Adjacency Segment, Adj-SID 395 An IGP-Adjacency Segment is an IGP segment attached to a 396 unidirectional adjacency or a set of unidirectional adjacencies. By 397 default, an IGP-Adjacency Segment is local to the node which 398 advertises it. However, an Adjacency Segment can be global if 399 advertised by the IGP as such. The SID of the IGP-Adjacency Segment 400 is called the Adj-SID. 402 The adjacency is formed by the local node (i.e., the node advertising 403 the adjacency in the IGP) and the remote node (i.e., the other end of 404 the adjacency). The local node MUST be an IGP node. The remote node 405 MAY be an adjacent IGP neighbor) or a non-adjacent neighbor (e.g.: a 406 Forwarding Adjacency, [RFC4206]). 408 A packet injected anywhere within the SR domain with a segment list 409 {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID 410 attached by node N to its adjacency over link L, will be forwarded 411 along the shortest-path to N and then be switched by N, without any 412 IP shortest-path consideration, towards link L. If the Adj-SID 413 identifies a set of adjacencies, then the node N load- balances the 414 traffic among the various members of the set. 416 Similarly, when using a global Adj-SID, a packet injected anywhere 417 within the SR domain with a segment list {SNL}, where SNL is a global 418 Adj-SID attached by node N to its adjacency over link L, will be 419 forwarded along the shortest-path to N and then be switched by N, 420 without any IP shortest-path consideration, towards link L. If the 421 Adj-SID identifies a set of adjacencies, then the node N load- 422 balances the traffic among the various members of the set. The use 423 of global Adj-SID allows to reduce the size of the segment list when 424 expressing a path at the cost of additional state (i.e.: the global 425 Adj-SID will be inserted by all routers within the area in their 426 forwarding table). 428 An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the 429 packet from a node towards a defined interface or set of interfaces. 430 This is key to theoretically prove that any path can be expressed as 431 a list of segments as explained in 432 [I-D.filsfils-spring-segment-routing-use-cases]. 434 The encodings of the Adj-SID include the B-flag. When set, the Adj- 435 SID benefits from a local protection. 437 The encodings of the Adj-SID include the L-flag. When set, the Adj- 438 SID has local significance. By default the L-flag is set. 440 A node SHOULD allocate one Adj-SIDs for each of its adjacencies. 442 A node MAY allocate multiple Adj-SIDs to the same adjacency. An 443 example is where the adjacency is established over a bundle 444 interface. Each bundle member MAY have its own Adj-SID. 446 A node MAY allocate the same Adj-SID to multiple adjacencies. 448 Adjacency suppression MUST NOT be performed by the IGP. 450 A node MUST install a FIB entry for any Adj-SID of value V attached 451 to data-link L: 453 Incoming Active Segment: V 454 Operation: NEXT 455 Egress Interface: L 457 The Adj-SID implies, from the router advertising it, the forwarding 458 of the packet through the adjacency identified by the Adj-SID, 459 regardless its IGP/SPF cost. In other words, the use of Adjacency 460 Segments overrides the routing decision made by SPF algorithm. 462 3.5.1. Parallel Adjacencies 464 Adj-SIDs can be used in order to represent a set of parallel 465 interfaces between two adjacent routers. 467 A node MUST install a FIB entry for any locally originated Adjacency 468 Segment (Adj-SID) of value W attached to a set of link B with: 470 Incoming Active Segment: W 471 Ingress Operation: NEXT 472 Egress interface: loadbalance between any data-link within set B 474 When parallel adjacencies are used and associated to the same Adj- 475 SID, and in order to optimize the load balancing function, a "weight" 476 factor can be associated to the Adj-SID advertised with each 477 adjacency. The weight tells the ingress (or a SDN/orchestration 478 system) about the loadbalancing factor over the parallel adjacencies. 479 As shown in Figure 1, A and B are connected through two parallel 480 adjacencies 482 link-1 483 +--------+ 484 | | 485 S---A B---C 486 | | 487 +--------+ 488 link-2 490 Figure 1: Parallel Links and Adj-SIDs 492 Node A advertises following Adj-SIDs and weights: 494 o Link-1: Adj-SID 1000, weight: 1 496 o Link-2: Adj-SID 1000, weight: 2 498 Node S receives the advertisements of the parallel adjacencies and 499 understands that by using Adj-SID 1000 node A will loadbalance the 500 traffic across the parallel links (link-1 and link-2) according to a 501 1:2 ratio. 503 The weight value is advertised with the Adj-SID as defined in IGP SR 504 extensions documents. 506 3.5.2. LAN Adjacency Segments 508 In LAN subnetworks, link-state protocols define the concept of 509 Designated Router (DR, in OSPF) or Designated Intermediate System 510 (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and 511 that describe the LAN topology in a special routing update (OSPF 512 Type2 LSA or IS-IS Pseudonode LSP). 514 The difficulty with LANs is that each router only advertises its 515 connectivity to the DR/DIS and not to each other individual nodes in 516 the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) 517 are necessary in order for each router in the LAN to advertise an 518 Adj-SID associated to each neighbor in the LAN. These extensions are 519 defined in IGP SR extensions documents. 521 3.6. Binding Segment 523 3.6.1. Mapping Server 525 A Remote-Binding SID S advertised by the mapping server M for remote 526 prefix R attached to non-SR-capable node N signals the same 527 information as if N had advertised S as a Prefix-SID. Further 528 details are described in the SR/LDP interworking procedures 529 ([I-D.filsfils-spring-segment-routing-ldp-interop]. 531 The segment allocation and SRDB Maintenance rules are the same as 532 those defined for Prefix-SID. 534 3.6.2. Tunnel Headend 536 The segment allocation and SRDB Maintenance rules are the same as 537 those defined for Adj-SID. A tunnel attached to a head-end H acts as 538 an adjacency attached to H. 540 Note: an alternative would consist in representing tunnels as 541 forwarding-adjacencies ( [RFC4206]). In such case, the tunnel is 542 presented to the routing area as a routing adjacency and will be 543 considered as such by all area routers. The Remote-Binding SID is 544 preferred as it allows to advertise the presence of a tunnel without 545 influencing the LSDB and the SPF computation. 547 3.7. Inter-Area Considerations 549 In the following example diagram we assume an IGP deployed using 550 areas and where SR has been deployed. 552 ! ! 553 ! ! 554 B------C-----F----G-----K 555 / | | | 556 S---A/ | | | 557 \ | | | 558 \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) 559 ! ! 560 Area-1 ! Backbone ! Area 2 561 ! area ! 563 Figure 2: Inter-Area Topology Example 565 In area 2, node Z allocates Node-SID 150 to his local prefix 566 192.0.2.1/32. ABRs G and J will propagate the prefix into the 567 backbone area by creating a new instance of the prefix according to 568 normal inter-area/level IGP propagation rules. 570 Nodes C and I will apply the same behavior when leaking prefixes from 571 the backbone area down to area 1. Therefore, node S will see prefix 572 192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. 574 It therefore results that a Prefix-SID remains attached to its 575 related IGP Prefix through the inter-area process. 577 When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as 578 active segment and forward it to A. 580 When packet arrives at ABR I (or C), the ABR forwards the packet 581 according to the active segment (Node-SID(150)). Forwarding 582 continues across area borders, using the same Node-SID(150), until 583 the packet reaches its destination. 585 When an ABR propagates a prefix from one area to another it MUST set 586 the R-Flag. 588 4. BGP Peering Segments 590 In the context of BGP Egress Peer Engineering (EPE), as described in 591 [I-D.filsfils-spring-segment-routing-central-epe], an EPE enabled 592 Egress PE node MAY advertise segments corresponding to its attached 593 peers. These segments are called BGP peering segments or BGP Peering 594 SIDs. They enable the expression of source-routed inter-domain 595 paths. 597 An ingress border router of an AS may compose a list of segments to 598 steer a flow along a selected path within the AS, towards a selected 599 egress border router C of the AS and through a specific peer. At 600 minimum, a BGP Peering Engineering policy applied at an ingress PE 601 involves two segments: the Node SID of the chosen egress PE and then 602 the BGP Peering Segment for the chosen egress PE peer or peering 603 interface. 605 Hereafter, we will define three types of BGP peering segments/SID's: 606 PeerNodeSID, PeerAdjSID and PeerSetSID. 608 o PeerNode SID. A BGP PeerNode segment/SID is a local segment. At 609 the BGP node advertising it, its semantics is: 611 * SR header operation: NEXT. 613 * Next-Hop: the connected peering node to which the segment is 614 related. 616 o PeerAdj SID: A BGP PeerAdj segment/SID is a local segment. At the 617 BGP node advertising it, its semantics is: 619 * SR header operation: NEXT. 621 * Next-Hop: the peer connected through the interface to which the 622 segment is related. 624 o PeerSet SID. A BGP PeerSet segment/SID is a local segment. At 625 the BGP node advertising it, its semantics is: 627 * SR header operation: NEXT. 629 * Next-Hop: loadbalance across any connected interface to any 630 peer in the related group. 632 A peer set could be all the connected peers from the same AS or a 633 subset of these. A group could also span across AS. The group 634 definition is a policy set by the operator. 636 The BGP extensions necessary in order to signal these BGP peering 637 segments will be defined in a separate document. 639 5. Multicast 641 Segment Routing is defined for unicast. The application of the 642 source-route concept to Multicast is not in the scope of this 643 document. 645 6. IANA Considerations 647 This document does not require any action from IANA. 649 7. Security Considerations 651 This document doesn't introduce new security considerations when 652 applied to the MPLS dataplane. 654 There are a number of security concerns with source routing at the 655 IPv6 dataplane [RFC5095]. The new IPv6-based segment routing header 656 defined in [I-D.previdi-6man-segment-routing-header] and its 657 associated security measures described in 658 [I-D.vyncke-6man-segment-routing-security] address these concerns. 659 The IPv6 Segment Routing Header is defined in a way that blind 660 attacks are never possible, i.e., attackers will be unable to send 661 source routed packets that get successfully processed, without being 662 part of the negations for setting up the source routes or being able 663 to eavesdrop legitimate source routed packets. In some networks this 664 base level security may be complemented with other mechanisms, such 665 as packet filtering, cryptographic security, etc. 667 8. Contributors 669 The following contributors have substantially helped the definition 670 and editing of the content of this document: 672 Wim Henderickx 673 Email: wim.henderickx@alcatel-lucent.com 675 Igor Milojevic 676 Email: milojevicigor@gmail.com 678 Saku Ytti 679 Email: saku@ytti.fi 681 9. Acknowledgements 683 We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre 684 Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes 685 Gredler for their comments and review of this document. 687 10. References 689 10.1. Normative References 691 [I-D.ietf-isis-segment-routing-extensions] 692 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 693 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 694 Extensions for Segment Routing", draft-ietf-isis-segment- 695 routing-extensions-03 (work in progress), October 2014. 697 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 698 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 699 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 700 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 701 segment-routing-extensions-00 (work in progress), August 702 2014. 704 [I-D.ietf-ospf-segment-routing-extensions] 705 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 706 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 707 Extensions for Segment Routing", draft-ietf-ospf-segment- 708 routing-extensions-04 (work in progress), February 2015. 710 [I-D.previdi-6man-segment-routing-header] 711 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 712 Segment Routing Header (SRH)", draft-previdi-6man-segment- 713 routing-header-05 (work in progress), January 2015. 715 [I-D.vyncke-6man-segment-routing-security] 716 Vyncke, E. and S. Previdi, "IPv6 Segment Routing Header 717 (SRH) Security Considerations", draft-vyncke-6man-segment- 718 routing-security-01 (work in progress), October 2014. 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, March 1997. 723 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 724 Hierarchy with Generalized Multi-Protocol Label Switching 725 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 727 10.2. Informative References 729 [I-D.filsfils-spring-segment-routing-central-epe] 730 Filsfils, C., Previdi, S., Patel, K., Aries, E., 731 shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment 732 Routing Centralized Egress Peer Engineering", draft- 733 filsfils-spring-segment-routing-central-epe-03 (work in 734 progress), January 2015. 736 [I-D.filsfils-spring-segment-routing-ldp-interop] 737 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 738 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 739 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 740 "Segment Routing interoperability with LDP", draft- 741 filsfils-spring-segment-routing-ldp-interop-02 (work in 742 progress), September 2014. 744 [I-D.filsfils-spring-segment-routing-use-cases] 745 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 746 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 747 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 748 Crabbe, "Segment Routing Use Cases", draft-filsfils- 749 spring-segment-routing-use-cases-01 (work in progress), 750 October 2014. 752 [I-D.francois-spring-segment-routing-ti-lfa] 753 Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, 754 "Topology Independent Fast Reroute using Segment Routing", 755 draft-francois-spring-segment-routing-ti-lfa-01 (work in 756 progress), October 2014. 758 [I-D.geib-spring-oam-usecase] 759 Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use 760 case for a scalable and topology aware MPLS data plane 761 monitoring system", draft-geib-spring-oam-usecase-03 (work 762 in progress), October 2014. 764 [I-D.ietf-pce-segment-routing] 765 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 766 Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions 767 for Segment Routing", draft-ietf-pce-segment-routing-00 768 (work in progress), October 2014. 770 [I-D.ietf-spring-ipv6-use-cases] 771 Brzozowski, J., Leddy, J., Leung, I., Previdi, S., 772 Townsley, W., Martin, C., Filsfils, C., and R. Maglione, 773 "IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- 774 cases-03 (work in progress), November 2014. 776 [I-D.ietf-spring-resiliency-use-cases] 777 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 778 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 779 resiliency-use-cases-00 (work in progress), May 2014. 781 [I-D.ietf-spring-segment-routing-mpls] 782 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 783 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 784 and E. Crabbe, "Segment Routing with MPLS data plane", 785 draft-ietf-spring-segment-routing-mpls-00 (work in 786 progress), December 2014. 788 [I-D.kumar-spring-sr-oam-requirement] 789 Kumar, N., Pignataro, C., Akiya, N., Geib, R., and G. 790 Mirsky, "OAM Requirements for Segment Routing Network", 791 draft-kumar-spring-sr-oam-requirement-02 (work in 792 progress), December 2014. 794 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 795 of Type 0 Routing Headers in IPv6", RFC 5095, December 796 2007. 798 Authors' Addresses 800 Clarence Filsfils (editor) 801 Cisco Systems, Inc. 802 Brussels 803 BE 805 Email: cfilsfil@cisco.com 806 Stefano Previdi (editor) 807 Cisco Systems, Inc. 808 Via Del Serafico, 200 809 Rome 00142 810 Italy 812 Email: sprevidi@cisco.com 814 Ahmed Bashandy 815 Cisco Systems, Inc. 816 170, West Tasman Drive 817 San Jose, CA 95134 818 US 820 Email: bashandy@cisco.com 822 Bruno Decraene 823 Orange 824 FR 826 Email: bruno.decraene@orange.com 828 Stephane Litkowski 829 Orange 830 FR 832 Email: stephane.litkowski@orange.com 834 Martin Horneffer 835 Deutsche Telekom 836 Hammer Str. 216-226 837 Muenster 48153 838 DE 840 Email: Martin.Horneffer@telekom.de 842 Rob Shakir 843 British Telecom 844 London 845 UK 847 Email: rob.shakir@bt.com 848 Jeff Tantsura 849 Ericsson 850 300 Holger Way 851 San Jose, CA 95134 852 US 854 Email: Jeff.Tantsura@ericsson.com 856 Edward Crabbe 857 Individual 859 Email: edward.crabbe@gmail.com