idnits 2.17.1 draft-ietf-spring-mpls-anycast-segments-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 : ---------------------------------------------------------------------------- == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 11, 2017) is 2565 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-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 (-15) exists of draft-ietf-spring-segment-routing-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-01 == Outdated reference: A later version (-30) exists of draft-ietf-spring-sr-yang-00 == Outdated reference: A later version (-08) exists of draft-previdi-6man-segment-routing-header-06 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group P. Sarkar, Ed. 3 Internet-Draft Arrcus, Inc. 4 Intended status: Standards Track H. Gredler 5 Expires: October 13, 2017 RtBrick Inc. 6 C. Filsfils 7 S. Previdi 8 Cisco Systems, Inc. 9 B. Decraene 10 Orange 11 M. Horneffer 12 Deutsche Telekom 13 April 11, 2017 15 Anycast Segments in MPLS based Segment Routing 16 draft-ietf-spring-mpls-anycast-segments-01 18 Abstract 20 Instead of forwarding to a specific device or to all devices in a 21 group, anycast addresses, let network devices forward a packet to (or 22 steer it through) one or more topologically nearest devices in a 23 specific group of network devices. The use of anycast addresses has 24 been extended to the Segment Routing (SR) network, wherein a group of 25 SR-capable devices can represent a anycast address, by having the 26 same Segment Routing Global Block (SRGB) provisioned on all the 27 devices and each one of them advertising the same anycast prefix 28 segment (or Anycast SID). 30 This document describes a proposal for implementing anycast prefix 31 segments in a MPLS-based SR network, without the need to have the 32 same SRGB block (label ranges) provisioned across all the member 33 devices in the group. Each node can be provisioned with a separate 34 SRGB from the label range supported by the specfic hardware platform. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on October 13, 2017. 59 Copyright Notice 61 Copyright (c) 2017 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.1.1. Common Anycast SRGB (CA-SRGB) . . . . . . . . . . . . 7 81 3.1.2. Common Anycast Prefix Segment Label (CAPSL) . . . . . 8 82 3.1.3. Anycast Prefix Segment Label (APSL) . . . . . . . . . 8 83 3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.2.1. Label Stack Computation . . . . . . . . . . . . . . . 9 85 3.2.2. Virtual SID Label Lookup Table . . . . . . . . . . . 10 86 3.2.3. Advertising Anycast Prefix Segments . . . . . . . . . 13 87 3.2.4. Programming Anycast Prefix Segments . . . . . . . . . 14 88 3.3. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 16 89 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 94 7.2. Informative References . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 Anycast is a network addressing scheme and routing methodology in 100 which packets from a single source device are forwarded to the 101 topologically nearest node in a group of potential receiving devices, 102 all identified by the same anycast address. There are various useful 103 usecases of anycast addresses, and discussion of the same are outside 104 the scope of this document. 106 [I-D.ietf-spring-segment-routing] extended the use of anycast 107 addresses to SR networks. An operator may combine a group of SR- 108 enabled nodes to form a anycast group, by picking a anycast address 109 and a segment identifier (hereon referred to as SID) to represent the 110 group, and then provisioning all the nodes with the same address and 111 SID. Once provisioned, each device in the group advertises the 112 corresponding anycast address in its IGP link-state advertisements 113 along with the SID provisioned. Source devices on receiving such 114 anycast prefix segment advertisements, finds out the topologically 115 nearest device that originated the anycast segment and forwards 116 packets destined to the same on the shortest-path to the nearest 117 device. 119 [I-D.ietf-spring-segment-routing] requires all devices in a given 120 anycast group to implement the exact same SRGB block(s). This 121 requirement will always be met in SR network deployed over IPV6 122 forwarding plane [I-D.previdi-6man-segment-routing-header]. For SR 123 over MPLS dataplane [I-D.ietf-spring-segment-routing-mpls], while 124 this is a simple (and hence more desirable) solution, the same may 125 not be possible in a multi-vendor networks deploying devices with 126 varying hardware capabilities. 128 In MPLS-based SR deployments, the segments on a given source router 129 are actually mapped to a MPLS labels allocated from the local label 130 pool carved out by the device for accomodating the SRGB. In multi- 131 vendor deployments with various types of devices deployed in the same 132 network topology, such a anycast group may contain a good combination 133 of devices from different vendors and have different internal 134 hardware capabilities. In such environments it is not sufficient to 135 assume that all the devices in a anycast group will be able to 136 allocate exactly the same range of labels for implementing the SRGB. 137 In reality, getting a common range of labels among all the various 138 vendors may not be feasible. 140 This documents provides mechanisms to implement anycast segments with 141 any kind of device in a multi-vendor network deployment without 142 requiring to provision the same exact range of labels for SRGB on all 143 the devices. 145 2. Problem Statement 147 To better illustrate the problem let us consider an example topology 148 using anycast segments as shown in Figure 1 below. 150 +--------------+ 151 | Group A | 152 | 192.1.1.1/32 | 153 | SID:100 | 154 | | 155 +-----------A1---A3----------+ 156 | | | \ / | | | 157 SID:10 | | | / | | | SID:30 158 1.1.1.1/32 | | | / \ | | | 1.1.1.3/32 159 PE1------R1----------A2---A4---------R3------PE3 160 \ /| | | |\ / 161 \ / | +--------------+ | \ / 162 \ / | | \ / 163 / | | / 164 / \ | | / \ 165 / \ | +--------------+ | / \ 166 / \| | | |/ \ 167 PE2------R2----------B1---B3----+----R4------PE4 168 1.1.1.2/32 | | | \ / | | | 1.1.1.4/32 169 SID:20 | | | / | | | SID:40 170 | | | / \ | | | 171 +-----+-----B2---B4----+-----+ 172 | | 173 | Group B | 174 | 192.1.1.2/32 | 175 | SID:200 | 176 +--------------+ 178 Figure 1: Topology 1 180 In Figure 1 above, there are two groups of transit devices. Group A 181 consists of devices {A1, A2, A3 and A4}. They are all provisioned 182 with the anycast address 192.1.1.1/32 and the anycast SID 100. 183 Similarly, group B consists of devices {B1, B2, B3 and B4} and are 184 all provisioned with the anycast address 192.1.1.2/32, anycast SID 185 200. In the above network topology, each PE device is connected to 186 two routers in each of the groups A and B. 188 Following are all the possible ECMP paths between the various pairs 189 of PE devices. 191 o P1: via {R1, A1, A3, R3} 193 o P2: via {R1, A1, A4, R3} 195 o P3: via {R1, A2, A3, R3} 197 o P4: via {R1, A2, A4, R3} 199 o P5: via {R2, B1, B3, R4} 201 o P6: via {R2, B1, B4, R4} 203 o P7: via {R2, B2, B3, R4} 205 o P8: via {R2, B2, B4, R4} 207 As seen above, there is always eight ECMP paths between each of pair 208 of PE devices. The network operator may not wish to utilize all 209 possible ECMP paths for all possible types of traffic flowing between 210 a given pair of PE devices. It may be more useful for use paths P1, 211 P2, P3 and P4 for certain types of traffic and use paths P5, P6, P7 212 and P8 for all other types of traffic between the same PE devices. 213 If so desired, operators may use these anycast groups A and B and the 214 corresponding anycast segment to impose a segment-list (refer to 215 [I-D.ietf-spring-segment-routing]) to forward the respective traffic 216 flows over the desired specific paths as shown below. Figure 2 below 217 depicts a expanded view of the paths via group A. The range labels 218 allocated for SRGB on each of the devices in group A are also 219 mentioned in this diagram. 221 +-------------------------+ 222 | Group A | 223 | 192.1.1.1/32 | 224 | SID:100 | 225 |-------------------------| 226 | | 227 | SRGB: SRGB: | 228 SID:10 |(1000-2000) (3000-4000)| SID:30 229 PE1---+ +-------A1-------------A3-------+ +---PE3 230 \ / | | \ / | | \ / 231 \ / | | +-----+ / | | \ / 232 SRGB: \ / | | \ / | | \ / SRGB: 233 (7000-8000) R1 | | \ | | R3 (6000-7000) 234 / \ | | / \ | | / \ 235 / \ | | +-----+ \ | | / \ 236 / \ | | / \ | | / \ 237 PE2---+ +-------A2-------------A4-------+ +---PE4 238 SID:20 | SRGB: SRGB: | SID:40 239 |(2000-3000) (4000-5000)| 240 | | 241 +-------------------------+ 243 Figure 2: Transit paths via anycast group A 245 In the above topology, if device PE1 (or PE2) requires to send a 246 packet to the device PE3 (or PE4) it needs to encapsulate the packet 247 in a MPLS payload with the following stack of labels. 249 o Label allocated R1 for anycast SID 100 (outer label) 251 o Label allocated by the nearest router in group A for SID 30 (for 252 destination PE3) 254 While the first label is easy to compute, in this case since there 255 are more than one topologically nearest devices (A1 and A2), unless 256 A1 and A2 implement same exact SRGB, determining the second label is 257 impossible. In all likeness, devices A1 and A2 may be devices from 258 different hardware vendors and it may not implement the same exact 259 SRGB label ranges. In such cases, separate labels are allocated by 260 A1 and A2 (1030 and 2030 respectively, in the above example). Hence, 261 PE1 (or PE2) cannot compute an appropriate label stack to steer the 262 packet exclusively through the group A devices. Same holds true for 263 devices PE3 and PE4 when trying to send a packet to PE1 or PE2. 265 3. Solution 267 3.1. Definitions 269 3.1.1. Common Anycast SRGB (CA-SRGB) 271 This document introduces the term 'Common-Anycast SRGB' (hereafter 272 referred to as the CA-SRGB) to define the SRGB implemented by the 273 majority of the devices in the network, that are participating in one 274 or more anycast segments. Each device MUST implement provisions to 275 let the operators assign the CA-SRGB on the device. Each vendor 276 implementation MUST implement provisions to configure the CA-SRGB at 277 all configuration levels (per-routing-instance/per-protocol/per- 278 topology etc) wherein provisions to configure the local SRGB label 279 ranges has also been implemented. Essentially, for each SRGB 280 configured on the device, vendor implementations MUST allow 281 configuring a corresponding CA-SRGB value. 283 For each configuration level (per-routing-instance/per-protocol/per- 284 topology etc)supported, the operator MUST set the same exact CA-SRGB 285 on all devices across the entire IGP domain (including different IS- 286 IS levels and OSPF areas). This ensures the proposal specified in 287 Section 3.2.1 works flawlessly across all devices in any multi-vendor 288 network deployment. 290 However assigning the CA-SRGB (for a given routing-instance/protocol/ 291 topology etc.) on the device, does not mean the label ranges 292 allocated by the device for the corresponding SRGB has to belong to 293 the CA-SRGB defined. The device may dynamically allocate the 294 corresponding SRGB label ranges, or allocate the range provisioned by 295 the operator, through an appropriate separate configuration (please 296 refer to [I-D.ietf-spring-sr-yang] for more details). 298 For devices that has the local SRGB to be exact same as the 'CA-SRGB' 299 applicable for the entire network, operators need not explictly set 300 the corresponding CA-SRGB values. In such case, the vendor 301 implementations MUST assume the local SRGB values to be the 302 corresponding CA-SRGB values defined on the specific device. 304 If the CA-SRGB defined on a device does not absolutely match the 305 corresponding SRGB label ranges allocated (or provisioned) on the 306 same device (i.e. the CA-SRGB is not an exact copy of the 307 corresponding SRGB label ranges), and the device is provisoned with 308 one or more anycast prefix segments, the device MUST implement all 309 the additional functionalities specified in Section 3.2.2, 310 Section 3.2.3 and Section 3.2.4. On devices, where the SRGB label 311 ranges is an exact copy of the corresponding CA-SRGB defined, the 312 device need not implement these additional functionalities ( 313 Section 3.2.2, Section 3.2.3 and Section 3.2.4). 315 3.1.2. Common Anycast Prefix Segment Label (CAPSL) 317 For each anycast prefix segment, this document also defines a 'Common 318 Anycast Prefix Segment Label' (hereafter referred to CAPSL). The 319 value of this label is derived by applying the SID index associated 320 with the prefix segment as an offset to the CA-SRGB configured on the 321 specific device. Since the operator MUST configure the same CA-SRGB 322 values on all devices in the IGP domain, all devices shall associate 323 the same CAPSL label value for a given anycast prefix segment. 324 Table 1 below shows the CAPSL labels allocated by any device for the 325 various prefix segments found in Figure 2, with CA-SRGB set to 326 3000-4000 on all devices. 328 +-----+---------------+-------------+ 329 | SID | CA-SRGB Range | CAPSL Value | 330 +-----+---------------+-------------+ 331 | 10 | 2000-3000 | 2010 | 332 | 20 | 2000-3000 | 2020 | 333 | 30 | 2000-3000 | 2030 | 334 | 40 | 2000-3000 | 2040 | 335 | 100 | 2000-3000 | 2100 | 336 +-----+---------------+-------------+ 338 Table 1: Common Anycast Prefix Segment Label Allocation 340 3.1.3. Anycast Prefix Segment Label (APSL) 342 This document also introduces the term 'Anycast Prefix Segment Label' 343 (hereafter referred to as APSL) to define the label allocated by a 344 device to advertise reachability for the specific anycast prefix 345 segment. The value of this label is derived by applying the SID 346 index associated with the anycast prefix segment as an offset to the 347 SRGB of the specific device. Table 2 below shows the labels 348 allocated by the various devices in Figure 2 for the anycast prefix 349 segment with SID 100. 351 +-------------+--------+-----------+------------+ 352 | Anycast-SID | Device | SRGB | APSL-Label | 353 +-------------+--------+-----------+------------+ 354 | 100 | R1 | 7000-8000 | 7100 | 355 | 100 | A1 | 1000-2000 | 1100 | 356 | 100 | A2 | 2000-3000 | 2100 | 357 | 100 | A3 | 3000-4000 | 3100 | 358 | 100 | A4 | 4000-5000 | 4100 | 359 | 100 | R3 | 6000-7000 | 6100 | 360 +-------------+--------+-----------+------------+ 362 Table 2: Anycast Prefix Segment Label Allocation 364 3.2. Procedures 366 3.2.1. Label Stack Computation 368 A MPLS device that tries to encapsulate any kind of traffic into a 369 SR-based MPLS payload (hereafter referred to as the ingress device) 370 and steer it through a series of SR adjacency and/or unicast/anycast 371 prefix segments, needs to compute an appropriate stack of MPLS labels 372 and put it in the outgoing packet. Alternatively, in a SDN 373 environment, the SDN controller may need to compute the label stack 374 and install it on the ingress device. 376 However in both cases, as illustrated in Section 2, for a given 377 ingress device (e.g. PE1 or PE2), there maybe multiple topologically 378 nearest devices in a specific anycast group (e.g. A1 and A2), even 379 through there is only out-going link from the source device(e.g. 380 PE1->R1 or PE2-R1). In such case, when the ingress device (or the 381 SDN controller) wants to steer a packet through the anycast group A, 382 it can use the anycast segment label advertised by the downstream 383 neighbor of the ingress device for the specific anycast prefix 384 segment. Since the packet may reach any one of the multiple devices 385 in the group and each of them may have a separate SRGB label range, 386 choosing the MPLS label for the next segment providing reachability 387 to the final destination. Also, since the packet steered through a 388 anycast segment can reach of any of the member device in the anycast 389 group, it is sufficient to assume that the ingress (or the 390 controller) cannot place an adjacency segment immediately after a 391 anycast segment in the outgoing packet. 393 This document proposes the ingress device (or the SDN controller) to 394 derive the label for a prefix segment that immediately follows a 395 given anycast segment, to be the CAPSL label associated with the 396 corresponding SID index (refer to Section 3.1.2). Note the prefix 397 segment immediately following the given anycast segment may itself be 398 another anycast segment. 400 The ingress (or the SDN controller) MUST follow the algorithm below 401 to compute the label-stack, that it must use to steer a packet 402 through a list of SR segments. 404 o Set previous_segment ==> NONE. 406 o Set label_stack ==> {EMPTY}. 408 o For [all segment in Segment_List] 410 * If {segment.type == Adjacency_Segment} 412 + Set label ==> segment.Adjacency_Segment_Label. 414 * Else 416 + If {previous_segment.type == Anycast_Prefix_Segment} 418 - Set label ==> CAPSL_Label(segment.SID_index). 420 + Else 422 - Set label ==> segment.Prefix_Segment_Label. 424 * Add label to label_stack. 426 * Set previous_segment ==> segment. 428 3.2.2. Virtual SID Label Lookup Table 430 When a MPLS packet on the wire first hits a device, the forwarding 431 hardware reads the topmost label in the MPSL header and looks up the 432 default label lookup table associated with the interface on which the 433 label has been received. This table is generally called LFIB. The 434 range of labels found in the LFIB constitutes the default label 435 space. 437 This document introduces a separate virtual label lookup table 438 (hereafter referred to as Virtual LFIB or V-LFIB), that represents a 439 label space which is also separate from the actual label space 440 represented by the default LFIB. The label value may be present in 441 both the default and Virtual LFIB. However the forwarding semantics 442 associated with the label under the default and Virtual LFIB may not 443 be same. Following are the fields of a typical entry of this table. 445 o CAPSL-Label: The CAPSL label value derived from the SID index 446 associated with a given prefix segment originated by another 447 device in the same network. Refer to Section 3.1.2 for more 448 details. This is also the key field for this table. 450 o Forwarding Semantics: This is once again one or more tuples of 451 following items. 453 * Outgoing-Label: The label(s) allocated by the neighbor 454 device(s) on the shortest-path to the topologically nearest 455 originator(s) of the prefix segment. 457 * Outgoing-link: The link(s) connecting the device to the 458 neighbor device(s) on the shortest path to the topologically 459 nearest originator(s) of the prefix segment. 461 This document proposes that, any device, when provisioned with one or 462 more anycast prefix segment (address and SID), and the CA-SRGB 463 defined by the operator is not an exact copy of the corresponding 464 SRGB label ranges allocated by the device, it MUST create a Virtual 465 LFIB table. 467 Such a device MUST add an entry in the Virtual LFIB for each unicast 468 and anycast prefix segments learnt from a remote device, if and only 469 if the same prefix has not been provisioned on the device. The 470 device SHOULD NOT add an entry for any of the Anycast or Node prefix 471 segments that it has advertised itself. However if the device has 472 learnt any anycast prefix segment from a remote device, and the same 473 is not provisioned on this device, the device MUST include the same 474 in the Virtual LFIB table. 476 In cases where a prefix segment is reachable via multiple shortest 477 paths on a given device, the corresponding entry for the prefix SID 478 MUST have as many forwarding entries in the Virtual LFIB table as the 479 number of shortest-paths found for the corresponding prefix on the 480 device. 482 Figure 3 below shows how the Virtual LFIB table on each of devices in 483 group A should look like. Please note that some of the prefix 484 segments has multiple forwarding semantics associated with them. For 485 example, on device A1, the prefix SID 10 (originated by PE3) is 486 reachable through its neighbors A3 and A4. And as per the SRGB 487 advertised by A3 and A4, the labels allocated by A3 and A4 are 3030 488 and 4030 respectively. Hence A1 has added two forwarding entries for 489 the prefix SID 30 in its Virtual LFIB table. 491 CA-SRGB configured on all devices: {2000-3000} 492 +========+=============+=======+========================+ 493 | | | Forwarding Semantics | 494 | Device | CAPSL-Label |--------------------------------| 495 | | | Outgoing-Label | Outgoing-Link | 496 +========+=============+================+===============+ 497 | A1 | 2010 | 7010 | A1->R1 | 498 | +-------------+----------------+---------------+ 499 | | 2020 | 7020 | A1->R1 | 500 | +-------------+----------------+---------------+ 501 | | 2030 | 3030 | A1->A3 | 502 | | | 4030 | A1->A4 | 503 | +-------------+----------------+---------------+ 504 | | 2040 | 3040 | A1->A3 | 505 | | | 4040 | A1->A4 | 506 +========+=============+================+===============+ 507 | A2 | No V-LFIB Table created since CA-SRGB is | 508 | | identical to SRGB allocated locally | 509 +========+=============+================+===============+ 510 | A3 | 2010 | 1010 | A3->A1 | 511 | | | 2010 | A3->A2 | 512 | +-------------+----------------+---------------+ 513 | | 2020 | 1020 | A3->A1 | 514 | | | 2020 | A3->A2 | 515 | +-------------+----------------+---------------+ 516 | | 2030 | 6030 | A3->R3 | 517 | +-------------+----------------+---------------+ 518 | | 2040 | 6040 | A3->R3 | 519 +========+=============+================+===============+ 520 | A4 | 2010 | 1010 | A4->A1 | 521 | | | 2010 | A4->A2 | 522 | +-------------+----------------+---------------+ 523 | | 2020 | 1020 | A4->A1 | 524 | | | 2020 | A4->A2 | 525 | +-------------+----------------+---------------+ 526 | | 2030 | 6030 | A4->R3 | 527 | +-------------+----------------+---------------+ 528 | | 2040 | 6040 | A4->R3 | 529 +========+=============+================+===============+ 531 Figure 3: Virtual LFIB Table Setup 533 Please note that node A2 has not created a Virtual LFIB table since 534 the CA-SRGB (2000-3000) is identical to the SRGB provisioned on it. 536 Also please note that none of the devices in the anycast group have 537 included the anycast SID 100 in the Virtual LFIB table, since the 538 same has already been provisioned on these devices. 540 When a device receives a MPLS packet with the anycast segment label 541 associated with one of the anycast prefix segments provisioned on the 542 same device, and the CA-SRGB defined by the operator is not an exact 543 copy of the corresponding SRGB label ranges allocated by it, it MUST 544 use the Virtual LFIB table to lookup the next label that follows the 545 anycast segment label in the stack of labels found in the MPLS 546 header. Refer to Section 3.2.4 for more details. 548 Following forwarding instructions MUST be installed in the MPLS data- 549 plane for each entry in the Virtual LFIB entry. 551 o If the label at the top of the stack matches any of the prefix 552 SIDs in the Virtual LFIB table, 554 * If there are multiple forwarding tuples associated with 555 matching table entry, 557 + Select one forwarding tuple. (Criteria to select one is 558 outside the scope of this document.) 560 * Else, 562 + Select the single forwarding tuple available. 564 * Replace the next label (should be a CAPSL label) found at top 565 of the MPLS label stack in the incoming packet, with the 566 'Outgoing-label' from the selected forwarding tuple. 568 * Forward the modified packet onto the 'Outgoing-link' as 569 specified in the selected forwarding tuple. 571 * If the prefix SID is another anycast segment, 573 + Ensure the next label lookup is launched again on the 574 Virtual LFIB table. 576 * Else, 578 + Ensure the next label lookup is launched on the default LFIB 579 table. 581 3.2.3. Advertising Anycast Prefix Segments 583 Like unicast prefix segments, anycast prefix segments SHOULD be 584 advertised in IGP Link-state advertsements using IGP protocol 585 extension for SR specified in 586 [I-D.ietf-isis-segment-routing-extensions], 587 [I-D.ietf-ospf-segment-routing-extensions] and 589 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. This document 590 does not propose any protocol extension for advertising anycast 591 prefix segments. 593 However when advertising the anycast segments, and the CA-SRGB 594 defined by the operator is not an exact copy of the corresponding 595 SRGB label ranges allocated by the originating device, it MUST set 596 the corresponding P-Flag(No-PHP) in ISIS Prefix-SID SubTLV and/or the 597 NP-Flag (No-PHP) in OSPFv2 and OSPFv3 Prefix-SID SubTLV to 1 and the 598 E-Flag in the same SubTLVs to 0. Please refer to following for more 599 details on usage of these flags. 601 o ISIS Prefix-SID SubTLV [I-D.ietf-isis-segment-routing-extensions] 603 o OSPFv2 Prefix-SID SubTLV 604 [I-D.ietf-ospf-segment-routing-extensions] 606 o OSPFv3 Prefix-SID SubTLV 607 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 609 The proposal above, ensures that a MPLS packet sent to (or taking 610 transit through) a given anycast group, when reaching at a 611 topologically nearest device in the group where CA-SRGB does not 612 match SRGB provisioned on it, always arrives with the APSL-label that 613 is derived from the device's SRGB, and the SID associated with the 614 corresponding anycast prefix segment. Note in the above topology, 615 assuming domain-wide CA-SRGB is set to (2000-3000) on all nodes, 616 while nodes A1, A3 and A4 will advertise the SID 100 with P-Flag(No- 617 PHP) set to 1, node A2 will advertise the same anycast prefix SID 618 with P-Flag unset. This is because on node A1 the domain-wide CA- 619 SRGB is identical to the local SRGB provisioned on A2. 621 In Figure 2, when PE1 or PE2 intends to steer a packet destined for 622 PE3 or PE4, through the anycast group A (SID 100), it needs to 623 forward the packet to R1 (SRGB:7000-8000), after putting the label 624 7100 (derived from R1's SRGB), at top of the label stack in the MPLS 625 header. However when the same packet is forwarded to A1 (one of the 626 topologicaly nearest devices in group A), R1 shall not POP (or 627 remove) the label 7100. Instead R1 shall replace it with the label 628 1100 while forwarding to A1. While forwarding to A2, since A2 would 629 have advertised the anycast SID 100 with P-Flag (No-PHP) unset, R1 630 shall POP the incoming label 7100 before forwarding it to R1. 632 3.2.4. Programming Anycast Prefix Segments 634 The proposal specified in Section 3.2.3, ensures that a MPLS packet 635 destined to (or steered via) a anycast prefix segment always arrives 636 at the nearest device in the anycast group with a label derived from 637 the device's SRGB and the SID associated with the corresponding 638 anycast prefix segment, as the top-most label label stack in its MPLS 639 header. If this label is also the bottom-most label (S=1), it means 640 packet has been destined to the anycast segment, and should be 641 consumed by the local device. If the label is not the bottom-most 642 label (S=0), the packet must be forwarded to the next segment, for 643 which the next label in the stack should be consulted. However 644 Section 3.2.1 specifies that the next label in such case, shall be a 645 label belonging to the CA-SRGB defined by the operator, derived from 646 the SID associated with the next segment. Since the CAPSL label for 647 the SID index associated with a prefix segment may directly collide 648 with another label in the default LFIB table, Section 3.2.2 also 649 proposed to have a Virtual LFIB table to provide a separate label- 650 space for looking up the next label. 652 This document specifies that a device provisioned with a given prefix 653 segment index MUST implement following forwarding semantics for the 654 anycast segment label (refer to Section 3.1.3) associated with the 655 anycast prefix segment, if the CA-SRGB label ranges defined is not an 656 exact copy of the corresponding SRGB label range(s) locally 657 allocated/provisioned on the device. 659 o If the label at the top the stack is a anycast segment label, and 660 the CA-SRGB defined is not an exact copy of the corresponding SRGB 661 label range(s), 663 * Pop the label. 665 * If bottom-most label in the stack (S=1), 667 + Send it to host stack for local consumption, as usual. 669 * Else if not the bottom-most label in the stack (S=0), 671 + Set the Virtual LFIB table as the lookup table for the next 672 label lookup. 674 + Launch a lookup for the next label in the stack (should be a 675 CAPSL label). 677 o Else 679 * Lookup the label in the default LFIB table as usual. 681 3.3. Packet Flow 683 Figure 4 below ilustrate how SR-based MPLS packets destined for PE3 684 and sourced by PE1 are expected to flow through when PE1 encapsulates 685 the packet with an appropriate label stack to steer it through group 686 A devices only 688 +-------------------------+ 689 | Group A | 690 | 192.1.1.1/32 | 691 CA-SRGB: {2000-3000} | SID:100 | 692 |-------------------------| 693 | | 694 | | 695 ---> ---> ---> ---> ---> ---> 696 +----+----+--+ +----+----+--+ +----+--+ +----+--+ +--+ +--+ 697 |7100|2030|..| |1100|2030|..| |3030|..| |6030|..| |..| |..| 698 +----+----+--+ +----+----+--+ +----+--+ +----+--+ +--+ +--+ 699 | | 700 | SRGB: SRGB: | 701 SID:10 |(1000-2000) (3000-4000)| SID:30 702 ---PE1---+ +-------A1-------------A3-------+ +---PE3--- 703 \ / | | \ / | | \ / 704 \ / | | +-----+ / | | \ / 705 SRGB: \ / | | \ / | | \ / SRGB: 706 (7000-8000) R1 | | \ | | R3 (6000-7000) 707 / \ | | / \ | | / \ 708 / \ | | +-----+ \ | | / \ 709 / \ | | / \ | | / \ 710 ---PE2---+ +-------A2-------------A4-------+ +---PE4--- 711 SID:20 | SRGB: SRGB: | SID:40 712 |(2000-3000) (4000-5000)| 713 | | 714 ---> ---> ---> 715 +----+--+ +----+--+ +----+--+ 716 |2030|..| |4030|..| |6030|..| 717 +----+--+ +----+--+ +----+--+ 718 | | 719 | | 720 +-------------------------+ 722 Figure 4: Packet Flow through MPLS-based SR Anycast Segments 724 4. Acknowledgements 726 Many many thanks to Shraddha Hegde, Eric Rosen, Chris Bowers and 727 Stephane Litkowski for their valuable inputs. 729 5. IANA Considerations 731 N/A. - No protocol changes are proposed in this document. 733 6. Security Considerations 735 This document does not introduce any change in any of the protocol 736 specifications. 738 7. References 740 7.1. Normative References 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, 744 DOI 10.17487/RFC2119, March 1997, 745 . 747 7.2. Informative References 749 [I-D.ietf-isis-segment-routing-extensions] 750 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 751 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 752 Extensions for Segment Routing", draft-ietf-isis-segment- 753 routing-extensions-04 (work in progress), May 2015. 755 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 756 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 757 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 758 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 759 segment-routing-extensions-02 (work in progress), February 760 2015. 762 [I-D.ietf-ospf-segment-routing-extensions] 763 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 764 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 765 Extensions for Segment Routing", draft-ietf-ospf-segment- 766 routing-extensions-04 (work in progress), February 2015. 768 [I-D.ietf-spring-segment-routing] 769 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 770 and R. Shakir, "Segment Routing Architecture", draft-ietf- 771 spring-segment-routing-03 (work in progress), May 2015. 773 [I-D.ietf-spring-segment-routing-mpls] 774 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 775 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 776 and E. Crabbe, "Segment Routing with MPLS data plane", 777 draft-ietf-spring-segment-routing-mpls-01 (work in 778 progress), May 2015. 780 [I-D.ietf-spring-sr-yang] 781 Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG 782 Data Model for Segment Routing", draft-ietf-spring-sr- 783 yang-00 (work in progress), July 2015. 785 [I-D.previdi-6man-segment-routing-header] 786 Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 787 Segment Routing Header (SRH)", draft-previdi-6man-segment- 788 routing-header-06 (work in progress), May 2015. 790 Authors' Addresses 792 Pushpasis Sarkar (editor) 793 Arrcus, Inc. 794 Bangalore, KA 560103 795 India 797 Email: pushpasis.ietf@gmail.com 799 Hannes Gredler 800 RtBrick Inc. 802 Email: hannes@rtbrick.com 804 Clarence Filsfils 805 Cisco Systems, Inc. 806 Brussels 807 BE 809 Email: cfilsfil@cisco.com 811 Stefano Previdi 812 Cisco Systems, Inc. 813 Via Del Serafico, 200 814 Rome 00142 815 Italy 817 Email: sprevidi@cisco.com 818 Bruno Decraene 819 Orange 821 Email: bruno.decraene@orange.com 823 Martin Horneffer 824 Deutsche Telekom 825 Hammer Str. 216-226 826 Muenster 48153 827 DE 829 Email: Martin.Horneffer@telekom.de