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