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