idnits 2.17.1 draft-peng-rtgwg-mrt-frr-sr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 159: '...n implementation MUST pick the router ...' RFC 2119 keyword, line 166: '...culation of MRTs SHOULD occur. This a...' RFC 2119 keyword, line 169: '...avior: ABRs/LBRs SHOULD ensure that tr...' RFC 2119 keyword, line 317: '...and. The MRT specific prefix-sid MUST...' RFC 2119 keyword, line 484: '... document. The MRT specific SRGB MUST...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 29, 2016) is 2796 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) == Missing Reference: 'F' is mentioned on line 846, but not defined == Missing Reference: 'D' is mentioned on line 846, but not defined == Missing Reference: 'N1-sid' is mentioned on line 287, but not defined == Missing Reference: 'N2-sid' is mentioned on line 288, but not defined == Missing Reference: 'N3-sid' is mentioned on line 589, but not defined == Missing Reference: 'S' is mentioned on line 846, but not defined == Missing Reference: 'X' is mentioned on line 903, but not defined == Missing Reference: 'B' is mentioned on line 906, but not defined == Missing Reference: 'C' is mentioned on line 906, but not defined == Missing Reference: 'Q' is mentioned on line 906, but not defined == Missing Reference: 'R' is mentioned on line 906, but not defined == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 1180, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-mpls' is defined on line 1191, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-07 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-09 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-05 Summary: 1 error (**), 0 flaws (~~), 19 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG WG Shaofu. Peng 3 Internet-Draft Ran. Chen 4 Intended status: Standards Track ZTE Corporation 5 Expires: March 2, 2017 August 29, 2016 7 Maximally Redundant Trees Fast Reroute using Segment Routing 8 draft-peng-rtgwg-mrt-frr-sr-00.txt 10 Abstract 12 This document presents a mechanism aimed at providing segment routing 13 forwarding option for MRT-FRR. It defines five new MRT Profiles, 14 each using SR-LSP, SR-tunnel, etc., forwarding option respectively. 15 These MRT Profiles will be very useful in the case of segment routing 16 network without LDP deployed. On the other hand, MRT-FRR is also a 17 competitive solution comparing with others for segment routing 18 network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 2, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Five New MRT Forwarding Options . . . . . . . . . . . . . . . 3 56 2.1. Option 1: MRT SR-tunnel Option . . . . . . . . . . . . . 4 57 2.1.1. Forwarding SR Label Unicast Traffic over MRT Paths . 5 58 2.1.2. Forwarding IP Unicast Traffic over MRT Paths . . . . 6 59 2.1.3. Inter-area Forwarding Behavior . . . . . . . . . . . 6 60 2.1.4. Prefixes Multiply Attached to the MRT Island . . . . 6 61 2.1.5. FIB examples . . . . . . . . . . . . . . . . . . . . 6 62 2.2. Option 2: MRT SR-LSP Tunneling with multi-prefix-sid 63 Option . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.2.1. Forwarding SR Label Unicast Traffic over MRT Paths . 8 65 2.2.2. Forwarding IP Unicast Traffic over MRT Paths . . . . 8 66 2.2.3. Inter-area Forwarding Behavior . . . . . . . . . . . 9 67 2.2.4. Prefixes Multiply Attached to the MRT Island . . . . 9 68 2.2.5. FIB examples . . . . . . . . . . . . . . . . . . . . 9 69 2.3. Option 3: MRT SR-LSP Tunneling with multi-SRGB Option . . 10 70 2.3.1. Forwarding SR Label Unicast Traffic over MRT Paths . 11 71 2.3.2. Forwarding IP Unicast Traffic over MRT Paths . . . . 12 72 2.3.3. Inter-area Forwarding Behavior . . . . . . . . . . . 12 73 2.3.4. Prefixes Multiply Attached to the MRT Island . . . . 12 74 2.3.5. FIB examples . . . . . . . . . . . . . . . . . . . . 12 75 2.4. Option 4: MRT SR-LSP Non-tunneling with multi-SRGB Option 13 76 2.4.1. Forwarding SR Label Unicast Traffic over MRT Paths . 14 77 2.4.2. Forwarding IP Unicast Traffic over MRT Paths . . . . 15 78 2.4.3. Inter-area Forwarding Behavior . . . . . . . . . . . 15 79 2.4.4. Prefixes Multiply Attached to the MRT Island . . . . 15 80 2.4.5. FIB examples . . . . . . . . . . . . . . . . . . . . 16 81 2.5. Option 5: MRT SR-LSP Non-tunneling with multi-prefix-sid 82 Option . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 3. Interoperation . . . . . . . . . . . . . . . . . . . . . . . 18 84 3.1. Multiple Profiles Coexistence . . . . . . . . . . . . . . 19 85 3.2. Multiple Profiles Interworking . . . . . . . . . . . . . 20 86 4. Support protecting segment list . . . . . . . . . . . . . . . 21 87 4.1. Received segment list is {segment F or S->F, vpn label} 88 or {segment F or S->F} . . . . . . . . . . . . . . . . . 22 89 4.2. Received segment list is {segment F or S->F, segment D1 90 or F->D1, segment D2, ..., segment Dn, vpn label} . . . . 23 91 4.3. Received segment list is {segment D1, segment D2, ..., 92 segment Dn, vpn label} . . . . . . . . . . . . . . . . . 24 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 7.1. Normative References . . . . . . . . . . . . . . . . . . 26 97 7.2. Informative References . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 100 1. Introduction 102 MRT-FRR [RFC7812] creates two alternate forwarding trees that are 103 distinct from the primary next-hop forwarding used during stable 104 operation. These two trees are maximally diverse from each other, 105 providing link and node protection for 100% of paths and failures as 106 long as the failure does not cut the network into multiple pieces. 107 MRT-FRR has defined some forwarding mechanism options, including LDP 108 Label Option 1A and 1B, IP Tunnel Option 2A and 2B. Among these 109 options, LDP Label Option 1A is a more appropriate choice, which is 110 selected as the forwarding mechanism in MRT default profile. 112 Segment Routing [I-D.ietf-spring-segment-routing] allows to enforce a 113 flow through any path and service chain while maintaining per-flow 114 state only at the ingress node of the SR domain. Segment Routing can 115 be directly applied to the MPLS architecture [RFC3031] with no change 116 on the forwarding plane. A segment is encoded as an MPLS label. An 117 ordered list of segments is encoded as a stack of labels. For each 118 IGP-prefix segment in the segment list, it will forward packet 119 according to shortest path to destination corresponding to the 120 prefix, that has similar characteristics as an LDP LSP, so we can 121 term it as an SR LSP. For the whole segment list, it will specify a 122 forwarding path, other than the normal shortest path, so we can term 123 it as an SR tunnel. 125 It is necessary to introduce MRT-FRR function as a new choice to 126 segment routing network for reliability. First, MRT-FRR will bring a 127 more competitive FRR solution to SR. Second, SR forwarding mechanism 128 will greatly simplify MRT-FRR function. 130 2. Five New MRT Forwarding Options 132 The following five new options for MRT forwarding mechanisms are 133 introduced. 135 1. MRT SR-tunnel Option 137 2. MRT SR-LSP Tunneling with multi-prefix-sid Option 139 3. MRT SR-LSP Tunneling with multi-SRGB Option 141 4. MRT SR-LSP Non-tunneling with multi-SRGB Option 143 5. MRT SR-LSP Non-tunneling with multi-prefix-sid Option 144 Respectively, we can define 5 new MRT profiles. Each profile is 145 almost same as the default MRT profile, except the forwarding 146 mechanisms would be set to the above value respectively, and allocate 147 different MRT MT-IDs. For example, the MRT profile which support 148 "MRT SR-tunnel Option" forwarding mechanism would be as the 149 following: 151 MRT Algorithm: MRT Lowpoint algorithm defined in [RFC7811]. 153 MRT-Red MT-ID: To be allocated. 155 MRT-Blue MT-ID: To be allocated. 157 GADAG Root Selection Policy: Among the routers in the MRT Island with 158 the lowest numerical value advertised for GADAG Root Selection 159 Priority, an implementation MUST pick the router with the highest 160 Router ID to be the GADAG root. Note that a lower numerical value 161 for GADAG Root Selection Priority indicates a higher preference for 162 selection. 164 Forwarding Mechanisms: MRT SR-tunnel Option 166 Recalculation: Recalculation of MRTs SHOULD occur. This allows the 167 MRT forwarding topologies to support IP/LDP fast-reroute traffic. 169 Area/Level Border Behavior: ABRs/LBRs SHOULD ensure that traffic 170 leaving the area also exits the MRT-Red or MRT-Blue forwarding 171 topology. 173 2.1. Option 1: MRT SR-tunnel Option 175 MRT SR-tunnel Option will treat the whole MRT-red or MRT-blue path as 176 a segment list. Only FEC-label binding for the default topology- 177 scoped FEC is needed. The specified segment list will direct the 178 packet along the expected MRT path, but totally in the default 179 topology. In order to forward packet along the expected MRT path 180 strictly, the specified segment list suggests to be an adjacency 181 segment list. 183 ____ 184 [F]---{____}................[D] 185 | . 186 | . 187 | . 188 [S]---[N1]---[N2]---[N3]....... 189 =======================> 190 MRT-Red path 192 Figure 1: MRT SR-tunnel Forwarding Mechanism 194 In Figure 1 above, supposed that the MRT-Red path is S-N1-N2-N3, 195 which is used to protect the default primary nexthop F. Packets 196 could be pushed to the SR-tunnel with segment list {N1,N2,N3} when 197 the primary nexthop F is failed. 199 We can optimize a long adjacency segment list to a short node segment 200 list. However, packets forwarding along a node segment list will not 201 ensure to be strictly forwarded along the expected MRT path, as each 202 node segment will always forward packets along the shortest path 203 according to the newest topology that maybe different with the 204 topology when doing optimazition, also as each transit node can do 205 local repair again for further failures, that could cause packet- 206 forwarding micro-loop among two or more routers. Note that node 207 segment list allows to try best to protect traffic for multiple 208 simultaneous failures. Using adjacency segment list or node segment 209 list is an implementation choice. Optimazition from a adjacency 210 segment list to a node segment list is out of the scope of this 211 document. 213 Note that we can support tunneling traffic along an MRT to a tunnel 214 endpoint that is not the destination of the traffic. 216 2.1.1. Forwarding SR Label Unicast Traffic over MRT Paths 218 When a PLR receives an SR label packet that needs to be forwarded on 219 the MRT-Red (for example), it first does a label swap operation, 220 replacing the incoming SR label assigned by the PLR for the FEC with 221 the SR label assigned by the tunnel endpoint for that FEC, then push 222 the whole label stack corresponding to the segment list of the MRT- 223 Red path. The packet will forward to the tunnel endpoint (also MRT 224 egress), then leave the MRT path to the shortest path to the 225 destination. 227 2.1.2. Forwarding IP Unicast Traffic over MRT Paths 229 When a PLR receives an IP packet that needs to be forwarded on the 230 MRT-Red to a particular tunnel endpoint, it does a label stack push 231 operation. The label stack pushed is the segment list of the MRT-Red 232 path. The packet will forward to the tunnel endpoint (also MRT 233 egress), then leave the MRT path to the shortest path to the 234 destination. 236 2.1.3. Inter-area Forwarding Behavior 238 As [RFC7812] described, it is desirable for traffic leaving the area 239 to also exit MRT-Red or MRT-Blue and return to shortest path 240 forwarding. However, this option always terminates the SR-tunnel 241 corresponding to an MRT path at the MRT egress, the packets will 242 leave the MRT path and continue to be forwarded according to the 243 default topology-scoped SR label or IP header. There is no MRT 244 specific perfix-sid in this option to create MRT specific SR LIB 245 entry. Other considerations see "section 3. interoperation". 247 2.1.4. Prefixes Multiply Attached to the MRT Island 249 This option will use tunnel endpoint selection approach to protection 250 for both multihomed prefix (outside the area) and destinations 251 outside the MRT Island (but inside the area). The forwarding 252 behavior for these prefixes and ones that inside the MRT Island are 253 totally same. 255 2.1.5. FIB examples 257 A node S in the MRT Island will maintain the following FTN entry for 258 a destination prefix: (suppose that the primary nexthop is F, and the 259 MRT-red path is N1-N2-N3 that is used to protect the primary 260 nexthop.) 262 example 1 264 KEY: MT-ID 0, prefix 265 Primary NHLFE: F, SRGB_F[prefix-sid] 266 According to adjacency segment list, the backup NHLFE would be: 267 Backup NHLFE: N1, adj-sid-N1toN2 ;outermost label 268 adj-sid-N2toN3 269 SRGB_N3[prefix-sid] 270 According to node segment list, the backup NHLFE would be: 271 Backup NHLFE: N1, SRGB_N1[N1-sid] ;outermost label 272 SRGB_N1[N2-sid] 273 SRGB_N2[N3-sid] 274 SRGB_N3[prefix-sid] 276 Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following: 278 example 2 280 KEY: SRGB_S[prefix-sid] 281 Primary NHLFE: F, SRGB_F[prefix-sid] 282 According to adjacency segment list, the backup NHLFE would be: 283 Backup NHLFE: N1, adj-sid-N1toN2 ;outermost label 284 adj-sid-N2toN3 285 SRGB_N3[prefix-sid] 286 According to node segment list, the backup NHLFE would be: 287 Backup NHLFE: N1, SRGB_N1[N1-sid] ;outermost label 288 SRGB_N1[N2-sid] 289 SRGB_N2[N3-sid] 290 SRGB_N3[prefix-sid] 292 2.2. Option 2: MRT SR-LSP Tunneling with multi-prefix-sid Option 294 This Option will allocate a different FEC-label binding for each of 295 the three topology-scoped FECs, i.e. default-FEC, red-FEC, blue-FEC, 296 originated by routers inside the MRT Island. For example, When a 297 packet is received with an SR label corresponding to red-FEC, an MRT 298 transit router will determine the next hop for the MRT-Red forwarding 299 topology for that FEC, swap the incoming SR label with the outgoing 300 SR label corresponding to the MRT-Red next-hop router, and forward 301 the packet. 303 The above FEC-label binding is caculated by prefix-sid for each of 304 the three topology-scoped prefixes depending on default topology- 305 scoped SRGB. Each router inside the MRT Island supporting this 306 option will allocate three node-sids, i.e. default-node-sid, red- 307 node-sid, blue-node-sid. In fact, We only need allocate node-sid for 308 each of the three topology-scoped Node-flag prefixes for each router 309 inside the MRT Island. Other prefixes inside the MRT Island could 310 also be allocated the corresponding MRT topology-scoped prefix-sids 311 besides the default topology-scoped prefix-sid, but it is not 312 necessary for this option. And, prefixes outside the MRT Island, 313 especially outside the area/level, need never allocate MRT topology- 314 scoped prefix-sids, as a simple reason is that routers outsid the MRT 315 Island have no idea about the MRT Island. Packets to the later two 316 class prefixes could be tunneled in the SR-LSP to the tunnel endpoint 317 which is inside the MRT Island. The MRT specific prefix-sid MUST 318 only be advertised intra the area which the MRT Island belongs to. 320 Note that we can support tunneling traffic along an MRT to a tunnel 321 endpoint that is not the destination of the traffic. 323 ____ 324 [F]---{____}................[D] 325 | . 326 | . 327 | . for node N3: 328 [S]---[N1]---[N2]---[N3]...... MT-default node-sid: 30 329 =======================> MT-red node-sid:31 330 MRT-Red path MT-blue node-sid:32 332 Figure 2: MRT SR-LSP Tunneling with multi-prefix-sid 333 Forwarding Mechanism 335 In Figure 2 above, supposed that the MRT-Red path is S-N1-N2-N3, 336 which is used to protect the default primary nexthop F to destination 337 D. Packets could be pushed to the SR LSP destinated to N3 with label 338 computed by MT-red node-sid 31 when the primary nexthop F is failed. 339 In MT-red topology there is an LSP build from ingress S to egress N3. 341 2.2.1. Forwarding SR Label Unicast Traffic over MRT Paths 343 When a PLR receives an SR label packet that matches a LIB entry 344 corresponding to a Node-flag prefix inside the MRT Island, and needs 345 to be forwarded on the MRT-Red (for example), it does a label swap 346 operation, replacing the incoming SR label for the FEC with the MRT- 347 Red SR label for that FEC received from the next-hop router in the 348 MRT-Red computed by the PLR. MRT transit router will determine the 349 next hop for the MRT-Red forwarding topology for that FEC, swap the 350 incoming MRT SR label with the outgoing MRT SR label learned from the 351 MRT-Red next-hop router, and forward the packet. 353 When a PLR receives an SR label packet that matches a LIB entry 354 corresponding to a prefix without Node-flag inside the MRT Island, or 355 a prefix outside the MRT Island, and needs to be forwarded on the 356 MRT-Red (for example) path to a tunnel endpoint inside the MRT 357 Island, it first does a label swap operation, replacing the incoming 358 SR label assigned by the PLR for the FEC with the SR label assigned 359 by the tunnel endpoint for that FEC, then pushes the MRT-Red SR label 360 to the tunnel endpoint. The packet will forward to the tunnel 361 endpoint (also MRT egress), then leave the MRT path to the shortest 362 path to the destination. 364 2.2.2. Forwarding IP Unicast Traffic over MRT Paths 366 When a PLR receives an IP packet that matches an FTN entry 367 corresponding to a Node-flag prefix inside the MRT Island, and needs 368 to be forwarded on the MRT-Red (for example), it does a label push 369 operation, pushing the MRT-Red SR label for that FEC received from 370 the next-hop router in the MRT-Red computed by the PLR. MRT transit 371 router will determine the next hop for the MRT-Red forwarding 372 topology for that FEC, swap the incoming MRT SR label with the 373 outgoing MRT SR label learned from the MRT-Red next-hop router, and 374 forward the packet. 376 When a PLR receives an IP label packet that matches an FTN entry 377 corresponding to a prefix without Node-flag inside the MRT Island, or 378 a prefix outside the MRT Island, and needs to be forwarded on the 379 MRT-Red (for example) path to a tunnel endpoint inside the MRT 380 Island, it first pushes the SR label assigned by the tunnel endpoint 381 for that FEC, then pushes the MRT-Red SR label to the tunnel 382 endpoint. The packet will forward to the tunnel endpoint (also MRT 383 egress), then leave the MRT path to the shortest path to the 384 destination. 386 2.2.3. Inter-area Forwarding Behavior 388 This option always terminates the SR-LSP corresponding to an MRT path 389 at the MRT egress, the packets will leave the MRT path and continue 390 to be forwarded according to the default topology-scoped SR label or 391 IP header. Although ABR will compute the MRT specific SR LIB for an 392 MRT specific prefix-sid corresponding to a destination prefix with 393 Node-flag inside the MRT Island that the ABR belongs to, the MRT 394 specific prefix-sid will never leak to another area. It is 395 impossible for the ABR to receive packets, from one area, containing 396 an MRT specific SR label to the destination prefix which belongs to 397 another area. Other considerations see "section 3. interoperation". 399 2.2.4. Prefixes Multiply Attached to the MRT Island 401 This option will use tunnel endpoint selection approach to protection 402 for both multihomed prefix (outside the area) and destinations 403 outside the MRT Island (but inside the area). The forwarding 404 behavior for these prefixes and ones without Node-flag that inside 405 the MRT Island are totally same. 407 2.2.5. FIB examples 409 A node S in the MRT Island will maintain the following FTN entry for 410 a destination Node-flag prefix inside the MRT Island: (suppose that 411 the primary nexthop is F, and the MRT-red path is N1-N2-N3 that is 412 used to protect the primary nexthop.) 414 example 1 416 KEY: MT-ID 0, prefix 417 Primary NHLFE: F, SRGB_F[default-prefix-sid] 418 Backup NHLFE: N1, SRGB_N1[red-prefix-sid] 420 Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following: 422 example 2 424 KEY: SRGB_S[default-prefix-sid] 425 Primary NHLFE: F, SRGB_F[default-prefix-sid] 426 Backup NHLFE: N1, SRGB_N1[red-prefix-sid] 428 Nodes along the above MRT-red path will maintain the red SR LIB 429 entry. For example, a LIB entry for FEC (MT-red, prefix) in N1 node 430 is as the following: 432 example 3 434 KEY: SRGB_N1[red-prefix-sid] 435 NHLFE: N2, SRGB_N2[red-prefix-sid] 437 Node S can also maintain the following FTN entry for a destination 438 prefix without Node-flag inside the MRT Island or a destination 439 prefix outside the MRT Island: (suppose that the primary nexthop is 440 F, and the MRT-red path is N1-N2-N3 that is used to protect the 441 primary nexthop.) 443 example 4 445 KEY: MT-ID 0, prefix 446 Primary NHLFE: F, SRGB_F[default-prefix-sid] 447 Backup NHLFE: N1, SRGB_N1[red-N3-sid] ;outermost label 448 SRGB_N3[default-prefix-sid] 450 Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following: 452 example 5 454 KEY: SRGB_S[default-prefix-sid] 455 Primary NHLFE: F, SRGB_F[default-prefix-sid] 456 Backup NHLFE: N1, SRGB_N1[red-N3-sid] ;outermost label 457 SRGB_N3[default-prefix-sid] 459 2.3. Option 3: MRT SR-LSP Tunneling with multi-SRGB Option 461 This Option will allocate a different FEC-label binding for each of 462 the three topology-scoped FECs, i.e. default-FEC, red-FEC, blue-FEC, 463 originated by routers inside the MRT Island. For example, When a 464 packet is received with an SR label corresponding to red-FEC, an MRT 465 transit router will determine the next hop for the MRT-Red forwarding 466 topology for that FEC, swap the incoming SR label with the outgoing 467 SR label corresponding to the MRT-Red next-hop router, and forward 468 the packet. 470 The above FEC-label binding is caculated by prefix-sid for the 471 default topology-scoped prefix depending on each topology-scoped 472 SRGBs. Each router inside the MRT Island supporting this option will 473 assign three SRGBs, i.e. default-SRGB, red-SRGB, blue-SRGB. In fact, 474 We only need caculate MRT SR labels for Node-flag prefixes for each 475 router inside the MRT Island. Other prefixes inside the MRT Island 476 and all prefixes outside the MRT Island could also caculate the MRT 477 SR labels depending on the MRT topology-scoped SRGBs besides the 478 default SR label depending on the default topology-scoped SRGB, but 479 it is not necessary for this option. Packets to the later two class 480 prefixes could be tunneled in the SR-LSP to the tunnel endpoint which 481 is inside the MRT Island. 483 The details of advertising SRGB per multi-topology will be described 484 in the related IGP extension document. The MRT specific SRGB MUST 485 only be advertised intra the area which the MRT Island belongs to. 487 Note that we can support tunneling traffic along an MRT to a tunnel 488 endpoint that is not the destination of the traffic. 490 ____ 491 [F]---{____}................[D] 492 | . 493 | . 494 | . for node N3: 495 [S]---[N1]---[N2]---[N3]...... MT-default SRGB:[100~200] 496 =======================> MT-red SRGB:[201~300] 497 MRT-Red path MT-blue SRGB:[301~400] 499 Figure 3: MRT SR-LSP Tunneling with multi-SRGB 500 Forwarding Mechanism 502 In Figure 3 above, supposed that the MRT-Red path is S-N1-N2-N3, 503 which is used to protect the default primary nexthop F to destination 504 D. Packets could be pushed to the SR LSP destinated to N3 with label 505 computed by MT-red SRGB when the primary nexthop F is failed. In MT- 506 red topology there is an LSP build from ingress S to egress N3. 508 2.3.1. Forwarding SR Label Unicast Traffic over MRT Paths 510 Same as section 2.2.1. 512 2.3.2. Forwarding IP Unicast Traffic over MRT Paths 514 Same as section 2.2.2. 516 2.3.3. Inter-area Forwarding Behavior 518 This option always terminates the SR-LSP corresponding to an MRT path 519 at the MRT egress, the packets will leave the MRT path and continue 520 to be forwarded according to the default topology-scoped SR label or 521 IP header. Suppose that area1 connects area2 by an ABR, MRT Island 1 522 is created inside area1 and MRT Island 2 inside area2. Although the 523 ABR will compute the MRT specific SR LIB, according to specific MRT 524 SRGB, for a destination prefix with Node-flag inside the MRT Island 2 525 that the ABR belongs to, a PLR also supporting this option inside the 526 MRT Island 1 will never compute the MRT specific SR LIB for this 527 prefix. It is impossible for the ABR to receive packets, from one 528 area, containing an MRT specific SR label to the destination prefix 529 which belongs to another area, if both MRT Islands support the same 530 option. Other considerations see "section 3. interoperation". 532 2.3.4. Prefixes Multiply Attached to the MRT Island 534 This option will use tunnel endpoint selection approach to protection 535 for both multihomed prefix (outside the area) and destinations 536 outside the MRT Island (but inside the area). The forwarding 537 behavior for these prefixes and ones without Node-flag that inside 538 the MRT Island are totally same. 540 2.3.5. FIB examples 542 A node S in the MRT Island will maintain the following FTN entry for 543 a destination Node-flag prefix inside the MRT Island: (suppose that 544 the primary nexthop is F, and the MRT-red path is N1-N2-N3 that is 545 used to protect the primary nexthop.) 547 example 1 549 KEY: MT-ID 0, prefix 550 Primary NHLFE: F, default_SRGB_F[prefix-sid] 551 Backup NHLFE: N1, red_SRGB_N1[prefix-sid] 553 Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following: 555 example 2 557 KEY: default_SRGB_S[prefix-sid] 558 Primary NHLFE: F, default_SRGB_F[prefix-sid] 559 Backup NHLFE: N1, red_SRGB_N1[prefix-sid] 561 Nodes along the above MRT-red path will maintain the red SR LIB 562 entry. For example, a LIB entry for FEC (MT-red, prefix) in N1 node 563 is as the following: 565 example 3 567 KEY: red_SRGB_N1[prefix-sid] 568 NHLFE: N2, red_SRGB_N2[prefix-sid] 570 Node S can also maintain the following FTN entry for a destination 571 prefix without Node-flag inside the MRT Island or a destination 572 prefix outside the MRT Island: (suppose that the primary nexthop is 573 F, and the MRT-red path is N1-N2-N3 that is used to protect the 574 primary nexthop.) 576 example 4 578 KEY: MT-ID 0, prefix 579 Primary NHLFE: F, default_SRGB_F[prefix-sid] 580 Backup NHLFE: N1, red_SRGB_N1[N3-sid] ;outermost label 581 default_SRGB_N3[prefix-sid] 583 Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following: 585 example 5 587 KEY: default_SRGB_S[prefix-sid] 588 Primary NHLFE: F, default_SRGB_F[prefix-sid] 589 Backup NHLFE: N1, red_SRGB_N1[N3-sid] ;outermost label 590 default_SRGB_N3[prefix-sid] 592 2.4. Option 4: MRT SR-LSP Non-tunneling with multi-SRGB Option 594 This Option will allocate a different FEC-label binding for each of 595 the three topology-scoped FECs, i.e. default-FEC, red-FEC, blue-FEC, 596 originated by any routers in the SR domain. For example, When a 597 packet is received with an SR label corresponding to red-FEC, an MRT 598 transit router will determine the next hop for the MRT-Red forwarding 599 topology for that FEC, swap the incoming SR label with the outgoing 600 SR label corresponding to the MRT-Red next-hop router, and forward 601 the packet. 603 The above FEC-label binding is caculated by prefix-sid for the 604 default topology-scoped prefix depending on each topology-scoped 605 SRGBs. Each router inside the MRT Island supporting this option will 606 assign three SRGBs, i.e. default-SRGB, red-SRGB, blue-SRGB. 607 Difference between this option and the option described in section 608 2.3 is that we create MRT SR-LSP for every destination prefix, not 609 only for Node-flag prefix inside the MRT Island. 611 Note that we only need to allocate and advertise default topology- 612 scoped prefix-sid in the SR domain, there are no red and blue 613 topology-scoped prefix-sids. But we need to advertise topology- 614 scoped SRGBs, i.e. default-SRGB, red-SRGB, blue-SRGB, respectively 615 intra the area. 617 The details of advertising SRGB per multi-topology will be described 618 in the related IGP extension document. The MRT specific SRGB MUST 619 only be advertised intra the area which the MRT Island belongs to. 621 ____ 622 [F]---{____}................[D] 623 | . 624 | . 625 | . for node N3: 626 [S]---[N1]---[N2]---[N3]...... MT-default SRGB:[100~200] 627 =======================> MT-red SRGB:[201~300] 628 MRT-Red path MT-blue SRGB:[301~400] 630 Figure 4: MRT SR-LSP Tunneling with multi-SRGB 631 Forwarding Mechanism 633 In Figure 4 above, supposed that the MRT-Red path is S-N1-N2-N3, 634 which is used to protect the default primary nexthop F to destination 635 D. Packets could be pushed to the SR LSP destinated to D with label 636 computed by MT-red SRGB when the primary nexthop F is failed. In MT- 637 red topology there is an LSP build from ingress S to egress D, at 638 node N3, the incoming label is computed by its own MT-red SRGB, the 639 outgoing label is computed by next-hop's MT-default SRGB. 641 2.4.1. Forwarding SR Label Unicast Traffic over MRT Paths 643 When a PLR receives an SR label packet that needs to be forwarded on 644 the MRT-Red (for example), it does a label swap operation, replacing 645 the incoming SR label for the FEC with the MRT-Red SR label for that 646 FEC received from the next-hop router in the MRT-Red computed by the 647 PLR. MRT transit router will determine the next hop for the MRT-Red 648 forwarding topology for that FEC, swap the incoming MRT SR label with 649 the outgoing MRT SR label learned from the MRT-Red next-hop router, 650 and forward the packet. 652 2.4.2. Forwarding IP Unicast Traffic over MRT Paths 654 When a PLR receives an IP packet that needs to be forwarded on the 655 MRT-Red (for example), it does a label push operation, pushing the 656 MRT-Red SR label for the FEC received from the next-hop router in the 657 MRT-Red computed by the PLR. MRT transit router will determine the 658 next hop for the MRT-Red forwarding topology for that FEC, swap the 659 incoming MRT SR label with the outgoing MRT SR label learned from the 660 MRT-Red next-hop router, and forward the packet. 662 2.4.3. Inter-area Forwarding Behavior 664 For OSPF, the ABR is responsible for advertising the proper prefix- 665 sid to each neighbor. Assume that an ABR has allocated a default 666 topology-scoped prefix-sid for a particular destination. To those 667 routers in the same area as the best route to the destination, the 668 ABR advertises the prefix-sid as normal. However, to routers in 669 other areas, the ABR advertises the prefix-sid with Rainbow-Flag. 670 Prefix-sid with Rainbow-Flag causes the receiving routers to use 671 default-SRGB of the next-hop to caculate SR out-label for the MRT- 672 Blue MT-ID and for the MRT-Red MT-ID. The details of advertising 673 prefix-sid with Rainbow-Flag will be described in another document. 675 The ABR installs all next hops for the best area: primary next hops 676 for default-SRGB, MRT-Blue next hops for blue-SRGB, and MRT-Red next 677 hops for red-SRGB. Because the ABR advertised prefix-sid with 678 Rainbow-Flag to neighbors not in the best area, packets from those 679 neighbors will arrive at the ABR with a label caculated by default- 680 SRGB of the ABR and will be forwarded into the best area along the 681 default topology. Other considerations see "section 3. 682 interoperation". 684 The same essential behavior also applies to IS-IS if one substitutes 685 IS-IS level for OSPF area. More details see "Appendix A" of 686 [RFC7812]. 688 2.4.4. Prefixes Multiply Attached to the MRT Island 690 This option will use named proxy-node approach to protection for both 691 multihomed prefix (outside the area) and destinations outside the MRT 692 Island (but inside the area). 694 According to [RFC7812], a proxy-node attachment router has a special 695 forwarding role. A proxy-node attachment router is similar with 696 other routers in the MRT Island to compute and install three ILM 697 entries for each (MT-ID 0, perfix) outside the MRT Island based on 698 three different FEC-label bindings. In particular, it will compute 699 SR out-label, for MRT SR ILM, based on the default-SRGB of the LFIN 700 whose cost was used in the selection or the remote endpoint of the 701 interface that caused the router to advertise the prefix. However, 702 it will always compute SR out-label based on the default-SRGB of the 703 shortest path nexthop for default SR ILM. 705 Note that if the proxy-node attachment router is an ABR, and it also 706 belongs to another MRT Island supporting this option in the area 707 which the destination prefix belongs to. It will compute SR out- 708 label, for MRT SR ILM, based on the red-SRGB or blue-SRGB of the MRT- 709 red or MRT blue nexthops, in despite of whether or not advertising 710 the destination prefix to another area. In this case, we can refer 711 to section "2.4.3. Inter-area Forwarding Behavior". 713 When a packet is received destined to (MRT-Red, prefix) or (MRT-Blue, 714 prefix), if the proxy-node attachment router is an IBR, it MUST swap 715 to the shortest path forwarding topology (e.g., swap to the label 716 caculated by default-SRGB of the IN) and forward the packet to the IN 717 whose cost was used in the selection. If the proxy-node attachment 718 router is not an IBR, then the packet MUST be removed from the MRT 719 forwarding topology and sent along the interface(s) that caused the 720 router to advertise the prefix; this interface might be out of the 721 area/level/AS. 723 2.4.5. FIB examples 725 A node S in the MRT Island will maintain the following FTN entry for 726 a destination prefix: (suppose that the primary nexthop is F, and the 727 MRT-red path is N1-N2-N3 that is used to protect the primary 728 nexthop.) 730 example 1 732 KEY: MT-ID 0, prefix 733 Primary NHLFE: F, default_SRGB_F[prefix-sid] 734 Backup NHLFE: N1, red_SRGB_N1[prefix-sid] 736 Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following: 738 example 2 740 KEY: default_SRGB_S[prefix-sid] 741 Primary NHLFE: F, default_SRGB_F[prefix-sid] 742 Backup NHLFE: N1, red_SRGB_N1[prefix-sid] 744 Nodes along the above MRT-red path will maintain the red SR LIB 745 entry. For example, a LIB entry for FEC (MT-red, prefix) in N1 node 746 is as the following: 748 example 3 750 KEY: red_SRGB_N1[prefix-sid] 751 NHLFE: N2, red_SRGB_N2[prefix-sid] 753 In particular, if S is a proxy-node attachment router, and suppose 754 that the LFIN whose cost was used in the selection or the remote 755 endpoint of the interface that caused S to advertise the prefix is M, 756 the FTN entry maintained by S would be like the following: 758 example 4 760 KEY: MT-ID 0, prefix 761 Primary NHLFE: F, default_SRGB_F[prefix-sid] 762 Backup NHLFE: M, default_SRGB_M[prefix-sid] 764 Also, the LIB entry for FEC (MT-ID 0, prefix) maintained by S would 765 be like the following: 767 example 5 769 KEY: default_SRGB_S[prefix-sid] 770 Primary NHLFE: F, default_SRGB_F[prefix-sid] 771 Backup NHLFE: M, default_SRGB_M[prefix-sid] 773 Also, the LIB entry for FEC (MT-red, prefix) maintained by S would be 774 like the following: 776 example 6 778 KEY: red_SRGB_S[prefix-sid] 779 NHLFE: M, default_SRGB_M[prefix-sid] 781 As notice in section 2.4.4, when S is a proxy-node attachment router 782 and an ABR, and it also belongs to another MRT Island supporting this 783 option in the area which the destination prefix belongs to. S will 784 maintain FTN/LIB entries just like example 1,2,3, in despite of 785 whether or not advertising the destination prefix to another area. 787 When S has received the the prefix-sid advertisement corresponding to 788 (MT-ID 0, prefix) with a Rainbow-Flag from its MRT-red nexthop (an 789 ABR), it will maintain the FTN entry as the following: 791 example 7 793 KEY: MT-ID 0, prefix 794 Primary NHLFE: F, default_SRGB_F[prefix-sid] 795 Backup NHLFE: ABR, default_SRGB_ABR[prefix-sid] 797 Also, a LIB entry for FEC (MT-ID 0, prefix) is as the following: 799 example 8 801 KEY: default_SRGB_S[prefix-sid] 802 Primary NHLFE: F, default_SRGB_F[prefix-sid] 803 Backup NHLFE: ABR, default_SRGB_ABR[prefix-sid] 805 Also, a LIB entry for FEC (MT-red, prefix) is as the following: 807 example 9 809 KEY: red_SRGB_S[prefix-sid] 810 NHLFE: ABR, default_SRGB_ABR[prefix-sid] 812 2.5. Option 5: MRT SR-LSP Non-tunneling with multi-prefix-sid Option 814 This Option will allocate a different FEC-label binding for each of 815 the three topology-scoped FECs, i.e. default-FEC, red-FEC, blue-FEC, 816 originated by any routers in the SR domain. For example, When a 817 packet is received with an red SR label corresponding to red-FEC, an 818 MRT transit router will determine the next hop for the MRT-Red 819 forwarding topology for that FEC, swap the incoming red SR label with 820 the outgoing red SR label corresponding to the MRT-Red next-hop 821 router, and forward the packet. 823 Difference between this option and the option described in section 824 2.2 is that we create MRT SR-LSP for every destination prefix, not 825 only for prefix with Node-flag inside the MRT Island. However, this 826 option can not address the destination prefixes which are outside the 827 MRT Island, especially outside the area/level, because routers outsid 828 the MRT Island have no idea about the MRT Island. It is impossible 829 for these routers to allocate the red or blue topology-scoped prefix- 830 sids, besides the default topology-scoped prefix-sid. Anorhter 831 reason is that an MRT specific prefix-sid can never leak between 832 areas. 834 This option is waiting for future study. 836 3. Interoperation 838 It is possible that a set of routers inside an area support two or 839 more options at the same time. It is also possible that one set of 840 routers, supporting one option, interconnect another set of routers 841 that support another option, both sets could be in the same area or 842 not. More detailed descriptions of these sceneria are given below. 844 3.1. Multiple Profiles Coexistence 846 [S]---[F]---............[D] 847 | | 848 ....|.......................|.... 849 . [N1]---[N2]---[N3] . 850 . | | | . 851 . [N4]---[N5]---[N6] . 852 . | | | . 853 . [N7]---[N8]---[N9] . 854 . | | | . 855 . [N10]---[N11]---[N12] . 856 ................................. 858 Figure 5: Multiple Profiles Coexistence 860 In Figure 5 above, the shortest path nexthop from S to D is F. S, D, 861 N1, N2, and N3 support the above all profiles. N4, N5, and N6 862 support profile with "MRT SR-LSP Tunneling with multi-prefix-sid 863 Option" forwarding mechanism only. N7, N8, and N9 support profile 864 with "MRT SR-LSP Tunneling with multi-SRGB Option" forwarding 865 mechanism only. N10, N11, and N12 support profile with "MRT SR-LSP 866 Non-tunneling with multi-SRGB Option" forwarding mechanism only. So, 867 there would be four MRT Islands in Figure 1. For each MRT Island, 868 suppose that the MRT-red nexthop from S to D is same as the shortest 869 path nexthop, i.e., F, the MRT-blue nexthop from S to D is Ni. 870 Specifically, the MRT-blue nexthop is N1 for MRT Island with "MRT SR- 871 tunnel Option" forwarding mechanism, the MRT-blue nexthop is ECMP 872 {N1,N4} for MRT Island with "MRT SR-LSP Tunneling with multi-prefix- 873 sid Option" forwarding mechanism, the MRT-blue nexthop is ECMP 874 {N1,N7} for MRT Island with "MRT SR-LSP Tunneling with multi-SRGB 875 Option" forwarding mechanism, the MRT-blue nexthop is ECMP {N1,N10} 876 for MRT Island with "MRT SR-LSP Non-tunneling with multi-SRGB Option" 877 forwarding mechanism. 879 From the perspective of node S, the FTN entry to D corresponding to 880 each MRT Island is different with each other, e.g., some have single 881 MRT-blue nexthop, some have ECMP MRT-blue nexthops. These FTN 882 entries MUST be distinguished by different MT-IDs. 884 From the perspective of node N1 (also other transit node), the ILM 885 entry to D corresponding to each MRT Island is also different with 886 each other. These ILM entries MUST be distinguished by different SR 887 in-label. Take a look at profile with "MRT SR-LSP Tunneling with 888 multi-SRGB Option" forwarding mechanism and profile with "MRT SR-LSP 889 Non-tunneling with multi-SRGB Option" forwarding mechanism, they both 890 use MRT specific SRGB to caculate MRT specific SR label for a default 891 topology-scoped prefix-sid. The MRT specific SRGB MUST be different 892 between these two profiles. For the same reason, the MRT specific 893 prefix-sid MUST be different between the profile with "MRT SR-LSP 894 Tunneling with multi-prefix-sid Option" forwarding mechanism and the 895 profile with "MRT SR-LSP Non-tunneling with multi-prefix-sid Option" 896 forwarding mechanism. 898 3.2. Multiple Profiles Interworking 900 [S]-------------[A] [P]-------------[D] 901 | \ / | 902 | \ / | 903 | MRT Island 1 [X] MRT Island 2 | 904 | / \ | 905 | / \ | 906 [B] -------------[C] [Q] ------------[R] 908 Figure 6: Multiple Profiles Interworking 910 In Figure 6 above, MRT Island 1 contains S, A, B, C, X, MRT Island 2 911 contains X, P, Q, R, D. If MRT Island 1 is supporting the profile 912 with "MRT SR-tunnel Option" forwarding mechanism, MRT Island 2 could 913 be any other profiles. The packets to from S to destination D will 914 terminate the SR-tunnel corresponding to an MRT path at node X, then 915 return to shortest path to D. 917 If MRT Island 1 is supporting the profile with "MRT SR-LSP Tunneling 918 with multi-prefix-sid Option" or "MRT SR-LSP Tunneling with multi- 919 SRGB Option" forwarding mechanism, MRT Island 2 could also be any 920 other profiles. The packets to from S to destination D will 921 terminate the MRT specific SR-LSP corresponding to an MRT path at 922 node X, then return to shortest path to D. Note that each node in 923 MRT Island 1 never compute MRT specific SR LIB for destination D 924 which is outside MRT Island 1, although X in MRT Island 2 maybe 925 compute it. X will never receive a packet, from MRT Island 1, which 926 includes an MRT specific SR label directly to destination D. 928 If MRT Island 1 is supporting the profile with "MRT SR-LSP Non- 929 tunneling with multi-SRGB Option" forwarding mechanism, each node in 930 MRT Island 1 will compute MRT specific SR LIB for destination D 931 directly. Especially, in node X, i.e., the proxy-node attachment 932 router, the MRT specific SR LIB computed for destination D will 933 forward packets to default topology. Hence, if MRT Island 2 is also 934 supporting the profile with "MRT SR-LSP Non-tunneling with multi-SRGB 935 Option" forwarding mechanism, X will also compute MRT specific SR LIB 936 for destination D which will forward packets along MRT path, 937 overwrite the above default topology forwarding information. In this 938 case, X MUST advertise prefix-sid with Rainbow flag corresponding to 939 (MT-ID 0, prefix-D) to neighbors in MRT Island 1, in order to avoid 940 receiving packets including an MRT specific SR label for destination 941 D. If MRT Island 2 is supporting "MRT SR-LSP Tunneling with multi- 942 SRGB Option" forwarding mechanism, X will also compute MRT specific 943 SR LIB for destination D which will forward packets along MRT path, 944 but in-label is different because of different MRT specific SRGB. 946 4. Support protecting segment list 948 As RFC7811 said, in some cases the PLR S can not find MRT alternates 949 to destination D for local repair to protect the primary nexthop F. 950 For example, if F is D, only link protection is possible. And if 951 both MRT-Red and MRT-Blue use the primary next hop, then the primary 952 next hop must be a cut-link, so either MRT could be pruned to avoid 953 the failed primary next-hop interface. 955 Thus, if S received a packet which contains a segment list only 956 including node segment F, we just comply with the MRT computing 957 result for destination F, try best to forward packet along the MRT 958 path which has not use the primary next hop. But if S received a 959 packet which contains a segment list not only including node segment 960 F as the first segment, but also other subsequent segments, S can 961 temporarily change the destination to another node D' rather than F, 962 and send packet along the MRT path to destination D'. A simple 963 condition which decided to set another destination D' is that the 964 original destination is a direct neighbor of S. We can easily check 965 this condition during computing SPF routes, and set the related flag 966 in the corresponding FTN/ILM entries. In dataplane, if the top label 967 of the label stack of the packet S received matches an SR-ILM entry 968 which has set the above flag to indicate the FEC is from a direct 969 nighbor and the primary next hop of the ILM entry is failed, in 970 despite of alternate next hops (e.g, MRT alternates) existing, S MAY 971 check if the next label of the label stack is also an SR-based label, 972 if so, deduce the next node-segment and directly forward the packet 973 to the next node-segment according to the FTN/ILM entry corresponding 974 to the next node-segment after twice label POP operations on the 975 original label stack. However, S can also simply choose to forward 976 packets along the alternate next hops of ILM entry corresponding to 977 the first segment to avoid the aboved complexities. It is a local 978 choice. 980 Similarly, if the top label of the label stack of the packet S 981 received matches an SR-ILM entry corresponding to a local adjacency 982 segment, S MAY also do the above check and process if the adjacency 983 is failed, and can also simply choose to forward packets along the 984 backup adjacencies. It is also a local choice. 986 It's a bit complicated for the dataplane to deduce the next node- 987 segment based on the label stack of the received packet. First, It 988 can deduce the first node-segment (i.e., F) based on the SR-ILM entry 989 matched by the top label, the node information can get from the 990 prefix FEC (F) or from the remote node-id of the adjacency FEC 991 (S->F). Then, we can get the SRGB of the first node-segment (i.e., 992 SRGB_F), and check if the next label is in SRGB_F, if so, we know 993 that the next segment is a prefix segment and deduce the prefix-sid, 994 which is then used to compute a label based on SRGB_S to match the 995 ILM entry correspond to the next node-segment. If the next label is 996 not in SRGB_F, S can check all F's local adjacencies to see if there 997 is a label equal to the next label, if so, we know that the next 998 segment is an adjacency segment and deduce the next node-segment from 999 the remote node-id of the matched adjacency, and an FTN entry could 1000 be match by the next node-segment. Note that S can maintain ILM 1001 entries for F's all local adjacencies for the above purpose, although 1002 these ILM entries are not used to forward packets directly. The FTN 1003 or ILM entry of the next segment could be used to directly forward 1004 the packet to the next node-segment after twice label POP operations 1005 on the original label stack. If the next label is neither in SRGB_F 1006 nor matching F's any local adjacencies, it must be a non-SR label, in 1007 this case, packets must be simply forwarded along the alternate next 1008 hops of ILM entry corresponding to the first segment, if there are no 1009 alternate next hops, packets would be dropped. 1011 All possible cases are systematically described in the following 1012 sections. 1014 4.1. Received segment list is {segment F or S->F, vpn label} or 1015 {segment F or S->F} 1017 We can determine that only one SR related label existed in label 1018 stack, and the segment is a direct neighbor along the shortest path. 1019 In this case, only link protection is possible. 1021 For MRT forwarding mechanism option 1, the MRT-FRR behavior is: 1023 POP segment F or S->F 1024 set D' = F, goto FTN entry of D', it will: 1025 PUSH SRGB_E[SID_F] ;E is MRT Egress 1026 PUSH the label stack of the SR-tunnel(from S to MRT Egress) 1028 For MRT forwarding mechanism option 2, the MRT-FRR behavior is: 1030 POP segment F or S->F 1031 set D' = F, goto FTN entry of D', it will: 1032 when F is inside MRT Island: 1033 PUSH SRGB_N[mrt_SID_F] ;N is MRT Nexthop 1034 when F is outside MRT Island: 1035 no MRT FRR provided 1037 For MRT forwarding mechanism option 3, the MRT-FRR behavior is: 1039 POP segment F or S->F 1040 set D' = F, goto FTN entry of D', it will: 1041 when F is inside MRT Island: 1042 PUSH mrt_SRGB_N[SID_F] 1043 when F is outside MRT Island: 1044 no MRT FRR provided 1046 For MRT forwarding mechanism option 4, the MRT-FRR behavior is: 1048 POP segment F or S->F 1049 set D' = F, goto FTN entry of D', it will: 1050 when S is not the proxy-node attachment router: 1051 no_rainbow:PUSH mrt_SRGB_N[SID_F] 1052 rainbow:PUSH default_SRGB_N[SID_F] 1053 when S is the proxy-node attachment router: 1054 no MRT FRR provided 1056 4.2. Received segment list is {segment F or S->F, segment D1 or F->D1, 1057 segment D2, ..., segment Dn, vpn label} 1059 The first segment is a direct neighbor along the shortest path, 1060 followed by other segments. 1062 For MRT forwarding mechanism option 1, the MRT-FRR behavior is: 1064 POP segment F or S->F 1065 POP segment D1 or F->D1 1066 change D'from F to D1, goto FTN or ILM entry of D', it will: 1067 when primary next hop for destination D' is valid: 1068 PUSH SRGB_H[SID_D1] ;H is primary next hop 1069 when primary next hop for destination D' is not valid:: 1070 PUSH SRGB_E[SID_D1], ;E is MRT Egress 1071 PUSH label stack of the SR-tunnel(from S to MRT Egress) 1073 For MRT forwarding mechanism option 2, the MRT-FRR behavior is: 1075 POP segment F or S->F 1076 POP segment D1 or F->D1 1077 change D'from F to D1, goto FTN or ILM entry of D', it will: 1078 when primary next hop for destination D' is valid: 1079 PUSH SRGB_H[default_SID_D1] 1080 when primary next hop for destination D' is not valid: 1081 when D1 is inside MRT Island: 1082 PUSH SRGB_N[mrt_SID_D1] ;N is MRT Nexthop 1083 when D1 is outside MRT Island: 1084 PUSH SRGB_E[default_SID_D1] 1085 PUSH SRGB_N[mrt_SID_E] 1087 For MRT forwarding mechanism option 3, the MRT-FRR behavior is: 1089 POP segment F or S->F 1090 POP segment D1 or F->D1 1091 change D'from F to D1, goto FTN or ILM entry of D', it will: 1092 when primary next hop for destination D' is valid: 1093 PUSH default_SRGB_H[SID_D1] 1094 when primary next hop for destination D' is not valid: 1095 when D1 is inside MRT Island: 1096 PUSH mrt_SRGB_N[SID_D1] 1097 when D1 is outside MRT Island: 1098 PUSH default_SRGB_E[SID_D1] 1099 PUSH mrt_SRGB_N[SID_E] 1101 For MRT forwarding mechanism option 4, the MRT-FRR behavior is: 1103 POP segment F or S->F 1104 POP segment D1 or F->D1 1105 change D'from F to D1, goto FTN or ILM entry of D', it will: 1106 when primary next hop for destination D' is valid: 1107 PUSH default_SRGB_H[SID_D1] 1108 when primary next hop for destination D' is not valid: 1109 when S is not the proxy-node attachment router: 1110 no_rainbow:PUSH mrt_SRGB_N[SID_D1] 1111 rainbow:PUSH default_SRGB_N[SID_D1] 1112 when S is the proxy-node attachment router: 1113 PUSH default_SRGB_M[SID_D1] ;M is nexthop outside Island 1115 4.3. Received segment list is {segment D1, segment D2, ..., segment Dn, 1116 vpn label} 1118 The first segment is not a direct neighbor along the shortest path, 1119 followed by other segments. 1121 For MRT forwarding mechanism option 1, the MRT-FRR behavior is: 1123 set D' = D1, goto ILM entry of D', it will: 1124 swap segment D1, i.e., SRGB_S[SID_D1] with SRGB_E[SID_D1] 1125 ;E is MRT Egress 1126 PUSH label stack of the SR-tunnel(from S to MRT Egress) 1128 For MRT forwarding mechanism option 2, the MRT-FRR behavior is: 1130 set D' = D1, goto ILM entry of D', it will: 1131 when D1 is inside MRT Island: 1132 swap segment D1, i.e., SRGB_S[default_SID_D1] with 1133 SRGB_N[mrt_SID_D1] ;N is MRT Nexthop 1134 when D1 is outside MRT Island: 1135 swap segment D1, i.e., SRGB_S[default_SID_D1] with 1136 SRGB_E[default_SID_D1] 1137 PUSH SRGB_N[mrt_SID_E] 1139 For MRT forwarding mechanism option 3, the MRT-FRR behavior is: 1141 set D' = D1, goto ILM entry of D', it will: 1142 when D1 is inside MRT Island: 1143 swap segment D1, i.e., default_SRGB_S[SID_D1] with 1144 mrt_SRGB_N[SID_D1] 1145 when D1 is outside MRT Island: 1146 swap segment D1, i.e., default_SRGB_S[SID_D1] with 1147 default_SRGB_E[SID_D1] 1148 PUSH mrt_SRGB_N[SID_E] 1150 For MRT forwarding mechanism option 4, the MRT-FRR behavior is: 1152 set D' = D1, goto ILM entry of D', it will: 1153 when S is not the proxy-node attachment router: 1154 no_rainbow:swap segment D1, i.e., default_SRGB_S[SID_D1] 1155 with mrt_SRGB_N[SID_D1] 1156 rainbow:swap segment D1, i.e., default_SRGB_S[SID_D1] with 1157 default_SRGB_N[SID_D1] 1158 when S is the proxy-node attachment router: 1159 swap segment D1, i.e., default_SRGB_S[SID_D1] with 1160 default_SRGB_M[SID_D1] ;M is nexthop outside Island 1162 5. Security Considerations 1164 TBD. 1166 6. IANA Considerations 1168 TBD 1170 7. References 1172 7.1. Normative References 1174 [I-D.ietf-isis-segment-routing-extensions] 1175 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1176 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1177 Extensions for Segment Routing", draft-ietf-isis-segment- 1178 routing-extensions-07 (work in progress), June 2016. 1180 [I-D.ietf-ospf-segment-routing-extensions] 1181 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1182 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1183 Extensions for Segment Routing", draft-ietf-ospf-segment- 1184 routing-extensions-09 (work in progress), July 2016. 1186 [I-D.ietf-spring-segment-routing] 1187 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 1188 and R. Shakir, "Segment Routing Architecture", draft-ietf- 1189 spring-segment-routing-09 (work in progress), July 2016. 1191 [I-D.ietf-spring-segment-routing-mpls] 1192 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1193 Litkowski, S., Horneffer, M., Shakir, R., 1194 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 1195 with MPLS data plane", draft-ietf-spring-segment-routing- 1196 mpls-05 (work in progress), July 2016. 1198 [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 1199 Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute 1200 Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, 1201 DOI 10.17487/RFC7811, June 2016, 1202 . 1204 [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for 1205 IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- 1206 FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, 1207 . 1209 7.2. Informative References 1211 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1212 Label Switching Architecture", RFC 3031, 1213 DOI 10.17487/RFC3031, January 2001, 1214 . 1216 Authors' Addresses 1218 Shaofu Peng 1219 ZTE Corporation 1220 No.68 Zijinghua Road,Yuhuatai District 1221 Nanjing 210012 1222 China 1224 Email: peng.shaofu@zte.com.cn 1226 Ran Chen 1227 ZTE Corporation 1228 No.50 Software Avenue,Yuhuatai District 1229 Nanjing 210012 1230 China 1232 Email: chen.ran@zte.com.cn