idnits 2.17.1 draft-szcl-mboned-redundant-ingress-failover-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 353: '... | MUST NOT | forwar...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2021) is 1020 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED WG G. Shepherd 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational Z. Zhang, Ed. 5 Expires: January 9, 2022 ZTE Corporation 6 Y. Liu 7 China Mobile 8 Y. Cheng 9 China Unicom 10 July 8, 2021 12 Multicast Redundant Ingress Router Failover 13 draft-szcl-mboned-redundant-ingress-failover-01 15 Abstract 17 This document discusses the redundant ingress router failover in 18 multicast domain. 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 https://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 January 9, 2022. 37 Copyright Notice 39 Copyright (c) 2021 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Multicast Redundant Ingress Router Failover . . . . . . . . . 3 57 3.1. Swichover . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Stand-by Modes . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Cold . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Warm . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3. Hot . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 6.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 The multicast redundant ingress router failover is an important issue 72 in multicast deployment. This document tries to do a research on it 73 in the multicast domain. The Multicast Domain is a domain which is 74 used to forward multicast flow according to specific multicast 75 technologies, such as PIM ([RFC7761]), BIER ([RFC8279]), P2MP TE 76 tunnel ([RFC4875]), MLDP ([RFC6388]), etc. The domain may or may not 77 connect the multicast source and receiver directly. 79 The ingress router is close to the multicast source. The ingress 80 router may connect the multicast source directly, or there may be 81 multiple hops between the ingress router and the multicast source. 82 In the multicast domain, the ingress router is the most adjacent 83 router to the multicast source. It's also called the first-hop 84 router in PIM, or BFIR in BIER, or Ingress LSR in P2MP TE tunnel or 85 MLDP. 87 The failover function between the multicast source and the ingress 88 router can be achieved by many ways, and it is not included in this 89 document. 91 The egress router is close to the multicast receiver. The egress 92 router may connect the multicast receiver directly, or there may be 93 multiple hops between the egress router and the multicast receiver. 94 In the multicast domain, the egress router is the most adjacent 95 router to the multicast receiver. It's also called the last-hop 96 router in PIM, or BFER in BIER, or Egress LSR in P2MP TE tunnel or 97 MLDP. 99 There may be some other function deployed in the multicast domain, 100 such as static configuration, or AMT ([RFC7450]), or SR P2MP Policy 101 ([I-D.ietf-pim-sr-p2mp-policy]). 103 This document doesn't discuss the details of these technologies. 104 This document discusses the general redundant ingress router failover 105 ways in the multicast domain. 107 2. Terminology 109 The following abbreviations are used in this document: 111 IR: the ingress router which is the most close to the multicast 112 source in the multicast domain. 114 ER: the egress router which is the most close to the multicast 115 receiver in the multicast domain. 117 SIR: The IR that is in charge of sending the multicast flow, or the 118 flow from the IR is accepted by the ERs, the IR is called as the 119 Selected-IR, that is SIR in abbreviation. 121 BIR: The IR that is not in charge of sending the multicast flow, or 122 the flow from the IR is not accepted by the ERs, but the IR replaces 123 the role of SIR once SIR fails. The IR is called as the Backup-IR, 124 that is BIR in abbreviation. 126 3. Multicast Redundant Ingress Router Failover 127 source 128 ... 129 +-----+ +-----+ 130 +----------+ IR1 +------+ IR2 +---------+ 131 |multicast +-----+ +-----+ | 132 |domain ... | 133 | | 134 | +-----+ +-----+ | 135 | | Rm | | Rn | | 136 | ++---++ +--+--+ | 137 | | | | | 138 | +-----+ +---+ +-----+ | 139 | | | | | 140 | +-v---+ +--v--+ +--v--+ | 141 +---+ ER1 +------+ ER2 +------+ ER3 +---+ 142 +-----+ +-----+ +-----+ 143 ... ... ... 144 receiver receiver receiver 145 Figure 1 147 Usually, a multicast source connects directly, or across multiple 148 hops to two IRs to avoid single node failure. As shown in figure 1, 149 there are two IRs close to a multicast source. The two IRs are UMH 150 (Upstream Multicast Hop) candidates for the ERs. 152 The two IRs gets multicast flow from the mutlcast source, how to 153 forward the multicast flow to ERs is different according to the 154 technologies deployed in the multicast domain. For example, for PIM 155 which is used in this domain, two PIM Trees that rooted on the two 156 IRs may be built separately. 158 The IRs works with the other router, such as the ER, in the multicast 159 domain to minimize the multicast flow packet loss during the IR 160 swichover. 162 3.1. Swichover 164 There may be some failures occurs in the domain, such as link 165 failure, node failure, if the failed link or node is on the multicast 166 flow forwarding path, there may be multicast flow packet loss. 168 If there are multiple paths from the IR to the ERs, there is no need 169 to switch IR when some nodes or links fail. 171 o When PIM is used in the domain as multicast forwarding protocol, 172 the forwarding tree for (S, G) or (*, G) is built in advance. 173 When a node or link in the forwarding tree fails, the tree is 174 rebuilt partially. 176 o When BIER is used in the domain as multicast forwarding protocol, 177 there is no need to rebuilt forwarding tree in case of node or 178 link failure, the BIER forwarding recovers along with the IGP 179 routing convergence. 181 o When P2MP TE tunnel or MLDP is used in the domain as multicast 182 forwarding protocol, the forwarding LSP is built in advance. When 183 a node or link in the LSP fails, the LSP may be rebuilt partially. 185 o When static multicast tree or SR P2MP policy is used in the 186 domain, the controller needs to re-compute a new forwarding path 187 to bypass the failed node or link. 189 In some situations, there are some key nodes or links in the network. 190 The multicast path can not be recovered due to the key node or link 191 failure. The IR needs swichover. 193 source 194 ... 195 +-----+ +-----+ 196 +----------+ IR1 +------+ IR2 +---------+ 197 | +--+--+ +--+--+ | 198 | | | | 199 | +--+--+ +--+--+ | 200 | | Rx | | Ry | | 201 | +-+-+-+ ++---++ | 202 | | | | | | 203 | | +-----------+ | | 204 | | | | | | 205 | | +---------+ | | | 206 | | | | | | 207 | +-v-v-+ +--v-v+ | 208 | | Rm | | Rn | | 209 | ++---++ +--+--+ | 210 | | | | | 211 | +-----+ +---+ +-----+ | 212 | | | | | 213 | +-v---+ +--v--+ +--v--+ | 214 +---+ ER1 +------+ ER2 +------+ ER3 +---+ 215 +-----+ +-----+ +-----+ 216 ... ... ... 217 receiver receiver receiver 218 Figure 2 220 For example in figure 2, there is only one path in the network 221 partially. The IR1, Rx are key nodes in the domain, when IR1 or Rx 222 fails, there is no any other path between the IR1 and the ERs. 224 o When PIM is used in the domain, Rm and Rn may choose Ry as the 225 upstream node to send Join message to build a new tree which 226 rooted with IR2. 228 o When BIER is used in the domain, IR2 should in charge of the 229 forwarding role to forward the flow to the ERs. 231 o When P2MP TE tunnel or MLDP is used in the domain, the LSP may be 232 rebuilt partially, or another LSP can be built in advance, and 233 replace the used LSP when the used LSP does not work. 235 o When static multicast tree or SR P2MP policy is used in the 236 domain, the controller should let the IR2 to forward multicast 237 flow to the ERs. 239 4. Stand-by Modes 241 In case there are more than one IRs can be the UMH, and there is no 242 other path from an IR to ERs in case of the IR fails, the IR needs to 243 be switched. 245 Usually there are three types of stand-by modes in multicast IR 246 protection. [RFC9026] has some description on it. This document 247 discusses the detail of the three modes here. 249 The ER may send request to upstream router or IR when it finds the 250 node or path failure. The request from the ER may be the PIM tree 251 building, or BIER overlay protocol signaling, or LSP building, or 252 some other ways to let IR knows whether forwards the multicast flow. 254 4.1. Cold 256 In cold standby mode, the ER selects an SIR, for example IR1 in 257 figure 1, as the SIR and signals to it to get the multicast flow. 259 When the ER finds that the SIR is down, or the ER finds that it 260 cannot receive flow from IR1, the ER signals to IR2 to get the 261 multicast flow. 263 o For IR, the IRs, include SIR and BIR, just do the regular 264 operation of forwarding flow according to the request from the ER. 266 o For ER, the ER must select an IR as the SIR and signal to it. 267 When the SIR fails or the path between the SIR and ER fails, the 268 ER must signal to the BIR to get the flow. 270 o For the intermediate routers, they know nothing about the role of 271 IR, they just do the packet forwarding. There is no duplicate 272 packets in the domain. 274 In case of the IR switchover, the ER detects the failure of SIR, and 275 signals to the BIR. There is packet loss during the signaling until 276 the ER receives the flow from the BIR. 278 4.2. Warm 280 In Warm standby mode, the ER signals to both IR1 and IR2. 282 In case IR1 is the SIR, IR1 forwards the flow to the ER. The BIR, 283 for example the IR2, must not forward the flow to the ER until the 284 SIR is down. 286 o For IR, the IR should take the role of SIR or BIR. The BIR must 287 not forward flow to the ER. When the SIR fails or the path 288 between SIR and ER fails, the BIR must start forwarding the flow 289 to ER. But it's hard to know the failure for BIR itself, some 290 methods should be taken to let the BIR to get the failure 291 notification. 293 o For ER, the ER does not select the SIR or BIR. The ER just signal 294 to both of them. 296 o For the intermediate routers, they know nothing about the role of 297 IR, they just do the packet forwarding. There is no duplicate 298 packets in the domain. 300 In case of the IR switchover, the BIR detects the failure of the SIR 301 and switch to SIR. There is packet loss during the IR switchover. 303 In some deployments, the SIR and BIR may in charge of different 304 multicast flow. For a specific multicast flow, the SIR may be IR1, 305 for another multicast flow, the SIR may be IR2. So the two IRs can 306 share the multicast forwarding load. And another possible deployment 307 is, the two IRs can in charge of different ERs for one multicast 308 flow. For example, IR1 sends the multicast flow to some of the ERs, 309 and IR2 send the multicast flow to the other ERs. In case IR1 310 detects there is something wrong between IR1 and the ERs, IR1 may 311 notify IR2 to take over the responsibility of forwarding the 312 multicast flow to these ERs that receive flow from IR1 before. 314 4.3. Hot 316 In Hot standby mode, the ER signals to both IRs. 318 Both IRs are sending the flow to the ER. The ER must discard the 319 duplicate flow from one of the IRs. 321 In this situation, there are no SIR or BIR. Only ER knows which IR 322 is the SIR. 324 o For IR, the IR need not to know the roles of SIR or BIR, IR just 325 forwarding the flow according to the request received from ER. 327 o For ER, the ER signal to both of the IRs to get the flow. And the 328 ER must discard the duplicated flow from the backup BIR. When the 329 SIR fails or the path between SIR and ER fails, the ER must switch 330 the forwarding plane to forward the flow packet comes from the 331 BIR. To be noted, the ERs may choose different SIR or BIR. 333 o For the intermediate routers, they know nothing about the role of 334 IR, they just do the packet forwarding. There are duplicate 335 packets forwarded in the domain. 337 In case of the IR switchover, the ER detects the failure of the SIR. 338 Because there are duplicate flow packets arrive on the ER, the ER 339 just switch to forward the flow comes from the BIR. There may be 340 packet loss during the switching. 342 4.4. Summary 344 The table is a brief comparison among the three modes. The 'SIR 345 failover' means the SIR fails or the path between SIR and ER fails. 347 +--------------+------------------+--------------+------------------+ 348 | role | Cold Mode | Warm Mode | Hot Mode | 349 +--------------+------------------+--------------+------------------+ 350 | IR | Forwarding flow | Takes the | Need not to know | 351 | | according to the | role of SIR | the roles of SIR | 352 | | request from ER. | or BIR, BIR | or BIR, just | 353 | | | MUST NOT | forwarding flow | 354 | | | forward flow | according to the | 355 | | | to ER until | request from ER. | 356 | | | SIR | | 357 | | | failovers. | | 358 | | | | | 359 | ER | Must select an | Does not | Signal to both | 360 | | IR as SIR to | select the | of SIR and BIR. | 361 | | signal the | SIR or BIR, | Discards the | 362 | | request, signal | just signal | duplicate flow | 363 | | to the BIR to | to both of | from BIR until | 364 | | request the flow | them. | SIR failover. | 365 | | when SIR | | | 366 | | failovers. | | | 367 | | | | | 368 | Intermediate | Knows nothing | Knows | Knows nothing | 369 | Router | about SIR or | nothing | about SIR or | 370 | | BIR. No | about SIR or | BIR. Duplicated | 371 | | duplicated flow | BIR. No | flow is | 372 | | is forwarded. | duplicated | forwarded. | 373 | | | flow is | | 374 | | | forwarded. | | 375 +--------------+------------------+--------------+------------------+ 377 Table 1 379 The Cold stand-by mode is the easiest way to implementated, but it 380 takes the longest converge time. 382 The Hot stand-by mode takes the most less packet loss, but there is 383 duplicated packet forwarding in the domain, more bandwidth is 384 occupied. 386 The Warm stand-by mode takes the middle packet loss and converge 387 time, but it's hard for BIR to know the failure between SIR and ERs. 389 So it's hard to say which mode is the best way for multicast 390 redundant ingress router failover, the network administrator should 391 select the most suitable mode according to the network deployment. 393 5. Security Considerations 395 This document adds no new security considerations. 397 6. References 399 6.1. Normative References 401 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 402 Yasukawa, Ed., "Extensions to Resource Reservation 403 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 404 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 405 DOI 10.17487/RFC4875, May 2007, 406 . 408 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 409 Thomas, "Label Distribution Protocol Extensions for Point- 410 to-Multipoint and Multipoint-to-Multipoint Label Switched 411 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 412 . 414 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 415 DOI 10.17487/RFC7450, February 2015, 416 . 418 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 419 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 420 Multicast - Sparse Mode (PIM-SM): Protocol Specification 421 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 422 2016, . 424 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 425 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 426 Explicit Replication (BIER)", RFC 8279, 427 DOI 10.17487/RFC8279, November 2017, 428 . 430 6.2. Informative References 432 [I-D.ietf-pim-sr-p2mp-policy] 433 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 434 Zhang, "Segment Routing Point-to-Multipoint Policy", 435 draft-ietf-pim-sr-p2mp-policy-02 (work in progress), 436 February 2021. 438 [RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., 439 "Multicast VPN Fast Upstream Failover", RFC 9026, 440 DOI 10.17487/RFC9026, April 2021, 441 . 443 Authors' Addresses 445 Greg Shepherd 446 Cisco Systems, Inc. 447 170 W. Tasman Dr. 448 San Jose 449 US 451 Email: gjshep@gmail.com 453 Zheng Zhang (editor) 454 ZTE Corporation 455 Nanjing 456 China 458 Email: zhang.zheng@zte.com.cn 460 Yisong Liu 461 China Mobile 462 Beijing 464 Email: liuyisong@chinamobile.com 466 Ying Cheng 467 China Unicom 468 Beijing 469 China 471 Email: chengying10@chinaunicom.cn