idnits 2.17.1 draft-szcl-mboned-redundant-ingress-failover-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 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 342: '... | 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 (October 25, 2020) is 1269 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-bess-mvpn-fast-failover-11 == Outdated reference: A later version (-08) exists of draft-ietf-pim-sr-p2mp-policy-00 Summary: 2 errors (**), 0 flaws (~~), 3 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: April 28, 2021 ZTE Corporation 6 Y. Liu 7 China Mobile 8 Y. Cheng 9 China Unicom 10 October 25, 2020 12 Multicast Redundant Ingress Router Failover 13 draft-szcl-mboned-redundant-ingress-failover-00 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 April 28, 2021. 37 Copyright Notice 39 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 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. This domain may or may 77 not 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. [I-D.ietf-bess-mvpn-fast-failover] has some description 247 on it. This document 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 4.3. Hot 305 In Hot standby mode, the ER signals to both IRs. 307 Both IRs are sending the flow to the ER. The ER must discard the 308 duplicate flow from one of the IRs. 310 In this situation, there are no SIR or BIR. Only ER knows which IR 311 is the SIR. 313 o For IR, the IR need not to know the roles of SIR or BIR, IR just 314 forwarding the flow according to the request received from ER. 316 o For ER, the ER signal to both of the IRs to get the flow. And the 317 ER must discard the duplicated flow from the backup BIR. When the 318 SIR fails or the path between SIR and ER fails, the ER must switch 319 the forwarding plane to forward the flow packet comes from the 320 BIR. To be noted, the ERs may choose different SIR or BIR. 322 o For the intermediate routers, they know nothing about the role of 323 IR, they just do the packet forwarding. There are duplicate 324 packets forwarded in the domain. 326 In case of the IR switchover, the ER detects the failure of the SIR. 327 Because there are duplicate flow packets arrive on the ER, the ER 328 just switch to forward the flow comes from the BIR. There may be 329 packet loss during the switching. 331 4.4. Summary 333 The table is a brief comparison among the three modes. The 'SIR 334 failover' means the SIR fails or the path between SIR and ER fails. 336 +--------------+------------------+--------------+------------------+ 337 | role | Cold Mode | Warm Mode | Hot Mode | 338 +--------------+------------------+--------------+------------------+ 339 | IR | Forwarding flow | Takes the | Need not to know | 340 | | according to the | role of SIR | the roles of SIR | 341 | | request from ER. | or BIR, BIR | or BIR, just | 342 | | | MUST NOT | forwarding flow | 343 | | | forward flow | according to the | 344 | | | to ER until | request from ER. | 345 | | | SIR | | 346 | | | failovers. | | 347 | | | | | 348 | ER | Must select an | Does not | Signal to both | 349 | | IR as SIR to | select the | of SIR and BIR. | 350 | | signal the | SIR or BIR, | Discards the | 351 | | request, signal | just signal | duplicate flow | 352 | | to the BIR to | to both of | from BIR until | 353 | | request the flow | them. | SIR failover. | 354 | | when SIR | | | 355 | | failovers. | | | 356 | | | | | 357 | Intermediate | Knows nothing | Knows | Knows nothing | 358 | Router | about SIR or | nothing | about SIR or | 359 | | BIR. No | about SIR or | BIR. Duplicated | 360 | | duplicated flow | BIR. No | flow is | 361 | | is forwarded. | duplicated | forwarded. | 362 | | | flow is | | 363 | | | forwarded. | | 364 +--------------+------------------+--------------+------------------+ 366 Table 1 368 The Cold stand-by mode is the easiest way to implementated, but it 369 takes the longest converge time. 371 The Hot stand-by mode takes the most less packet loss, but there is 372 duplicated packet forwarding in the domain, more bandwidth is 373 occupied. 375 The Warm stand-by mode takes the middle packet loss and converge 376 time, but it's hard for BIR to know the failure between SIR and ERs. 378 So it's hard to say which mode is the best way for multicast 379 redundant ingress router failover, the network administrator should 380 select the most suitable mode according to the network deployment. 382 5. Security Considerations 384 This document adds no new security considerations. 386 6. References 388 6.1. Normative References 390 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 391 Yasukawa, Ed., "Extensions to Resource Reservation 392 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 393 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 394 DOI 10.17487/RFC4875, May 2007, 395 . 397 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 398 Thomas, "Label Distribution Protocol Extensions for Point- 399 to-Multipoint and Multipoint-to-Multipoint Label Switched 400 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 401 . 403 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 404 DOI 10.17487/RFC7450, February 2015, 405 . 407 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 408 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 409 Multicast - Sparse Mode (PIM-SM): Protocol Specification 410 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 411 2016, . 413 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 414 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 415 Explicit Replication (BIER)", RFC 8279, 416 DOI 10.17487/RFC8279, November 2017, 417 . 419 6.2. Informative References 421 [I-D.ietf-bess-mvpn-fast-failover] 422 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN Fast 423 Upstream Failover", draft-ietf-bess-mvpn-fast-failover-11 424 (work in progress), October 2020. 426 [I-D.ietf-pim-sr-p2mp-policy] 427 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 428 Zhang, "Segment Routing Point-to-Multipoint Policy", 429 draft-ietf-pim-sr-p2mp-policy-00 (work in progress), July 430 2020. 432 Authors' Addresses 434 Greg Shepherd 435 Cisco Systems, Inc. 436 170 W. Tasman Dr. 437 San Jose 438 US 440 Email: gjshep@gmail.com 442 Zheng Zhang (editor) 443 ZTE Corporation 444 Nanjing 445 China 447 Email: zhang.zheng@zte.com.cn 449 Yisong Liu 450 China Mobile 452 Email: liuyisong@chinamobile.com 454 Ying Cheng 455 China Unicom 456 Beijing 457 China 459 Email: chengying10@chinaunicom.cn