idnits 2.17.1 draft-zhang-bier-source-protection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2021) is 1173 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-bier-bfd-00 == Outdated reference: A later version (-08) exists of draft-ietf-bier-mld-04 == Outdated reference: A later version (-12) exists of draft-ietf-bier-pim-signaling-11 == Outdated reference: A later version (-13) exists of draft-ietf-bier-ping-07 == Outdated reference: A later version (-02) exists of draft-szcl-mboned-redundant-ingress-failover-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER WG Z. Zhang 3 Internet-Draft G. Mirsky 4 Intended status: Informational Q. Xiong 5 Expires: August 11, 2021 ZTE Corporation 6 Y. Liu 7 China Mobile 8 February 7, 2021 10 BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover 11 draft-zhang-bier-source-protection-02 13 Abstract 15 This document describes a failover in the Bit Index Explicit 16 Replication domain with a redundant ingress router. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 11, 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. The Redundant BFIR Failover Analysis . . . . . . . . . . . . 3 55 3.1. Node Failure Monitoring . . . . . . . . . . . . . . . . . 4 56 3.2. Monitoring of the Working Path for a Failure . . . . . . 5 57 4. BFD and Ping . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1. BIER Ping . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4.2. BIER BFD . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 64 7.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 70 that provides multicast forwarding through a BIER domain without 71 requiring intermediate routers to maintain any multicast related per- 72 flow state. BIER also does not require any explicit tree-building 73 protocol for its operation. A multicast data packet enters a BIER 74 domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER 75 domain at one or more Bit-Forwarding Egress Routers (BFERs). 77 Redundant Ingress Router Failover is not specific to the BIER 78 environment. Redundant Ingress Router Failover means that to avoid 79 single node failure, two or more ingress routers, BFIRs in a BIER 80 environment, can be connected to the same multicast flow's source 81 node. One of BFIRs is selected to forward the flow from a multicast 82 source node to egress routers, i.e., BFER in a BIER environment. The 83 BFERs may choose the primary BFIR for the given multicast flow based 84 on local policies. BFERs in the same multicast group may select the 85 same or different BFIR. The BFIR and the path in use are referred to 86 as working, while all alternative available BFIRs and paths that can 87 be used to receive the same multicast flow are referred to as 88 protection. 90 When either the working BFIR or the working path fails, a BFER can 91 select one of the protecting BFIRs to recover the multicast flow. 92 The shorter the detection time, the faster the flow recovers. 94 This document discusses the functions that can be used to detect the 95 failure to trigger redundant ingress router failover in the BIER 96 environment. 98 2. Keywords 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 3. The Redundant BFIR Failover Analysis 108 According to the BIER architecture [RFC8279], BIER overlay protocols, 109 which among others include MVPN [RFC8556], MLD [I-D.ietf-bier-mld], 110 PIM [I-D.ietf-bier-pim-signaling], are used to exchange the multicast 111 flow information. Based on that, a BFER selects the UMH (Upstream 112 Multicast Hop) BFIR as the ingress router. The BFIR selected as the 113 UMH through a BIER overlay protocol learns of BFERs which have chosen 114 it to receive the particular multicast flow. BIER transport is used 115 to deliver the multicast packet to the destination BFERs. The 116 detection of a defect in the BIER transport layer ensures that the 117 source flow protection is uninterrupted. The switchover is performed 118 at the BIER overlay layer. Upon detecting the failure, an update in 119 the BIER overlay can trigger BFIR re-selection by BFERs. 121 As described in [I-D.szcl-mboned-redundant-ingress-failover], the 122 root standby modes, i.e., Cold Standby, Warm Standby, and Hot 123 Standby, can be used in the BIER environment. In Warm and Hot 124 Standby modes, the protection BFIR needs to learn through BIER 125 overlay protocols the identities of BFERs in the particular multicast 126 group. In the Hot Standby mode, BFER receives duplicate flows from 127 the selected active BFIR and protection BFIR, BFER accepts the flow 128 packet from the selected active BFIR, identified, for example, by 129 BFIR-id in the BIER header, discards the multicast packet from the 130 protection BFIR. 132 The most important elements in the redundant BFIR failover mechanism 133 are failure detection and switchover. Note that the scope of the 134 failure detection includes node and working path. Similarly, BFIR 135 switching and BFER switching are considered in the switchover 136 scenario. 138 The selected BFIR is referred to as Selected BFIR (S-BFIR), and the 139 backup BFIR is referred to as Backup BFIR (B-BFIR). For simplicity, 140 only one B-BFIR is considered in the following use case. 142 +--------+S1+-------+ 143 | | 144 +--v----+ +---v---+ 145 +------+ BFIR1 |..........| BFIR2 +-------+ 146 . +-------+ +-------+ . 147 . . 148 . ...... . 149 . . 150 . +-------+ +-------+ +-------+ . 151 +--|BFER1|-......-|BFER2|-......-|BFER3|--+ 152 +--+----+ +---+---+ +--+----+ 153 | | | 154 v v v 155 R1 R2 R3 157 Figure 1: An Example of the Redundant BFIR Failover 159 In Figure 1, a multicast source S1 is connected to BFIR1 and BFIR2. 160 In some deployments, only BFIR1 advertises S1 flow information to 161 BFERs using a BIER overlay protocol, such as, among others, 162 BGP(MVPN), MLD, or PIM. For this example, all BFERs that are 163 directed to receive the S1 flow will select BFIR1 as the S-BFIR, and 164 BFIR2 is considered as the B-BFIR. In some other deployments, BFIR1 165 and BFIR2 both advertise S1 flows to BFERs using a BIER overlay 166 protocol. As a result, some BFERs may select BFIR1 as their S-BFIR, 167 other BFERs may select BFIR2 as S-BFIR, BFIR1 and BFIR2 are 168 responsible for different sub-groups of BFERs, and they, 169 respectively, are the B-BFIR for the second sub-set of BFERs. We do 170 not distinguish these two cases strictly. 172 There are two types of failure monitoring: 174 o Node failure monitoring: It is used for BFIR failure detection. 175 The BFER failure detection is out of the scope of this document. 177 o Working path failure monitoring: It is used for BIER transport 178 path failure detection. It is used for the monitoring among BIER 179 domain edge routers, which include BFIR and BFER, through BIER 180 forwarding. 182 3.1. Node Failure Monitoring 184 For example, consider when S1 is connected to BFIR1 and BFIR2 on a 185 shared media segment. BFIR1 is acting as S-BFIR for the multicast 186 flow transmitted by S1. BFIR2 can monitor BFIR1 node failure using a 187 BFD session [RFC5880] built over the shared media segment. Also, can 188 use ping methods, including, for example, IPv4 ping [RFC0792], IPv6 189 ping [RFC4443], and LSP-Ping [RFC8029] in a network with either IPv4, 190 IPv6, or MPLS data plane, respectively. 192 In case there is no shared media segment interconnecting S1, BFIR1, 193 and BFIR2, BFIR2 may monitor the state of BFIR1 using a BIER BFD 194 session [I-D.ietf-bier-bfd] or a ping protocol across the BIER 195 domain. A ping protocol listed above or BIER ping 196 [I-D.ietf-bier-ping] can be used. In case there is no direct 197 connection between BFIR1 and BFIR2, multiple hops will be traversed. 198 Similarly, any of the listed above path continuity checking methods 199 can be used by a BFER to monitor the path to and state of S-BFIR. 200 The case when the S-BFIR monitors the working path to a BFER is 201 considered further in the document in more details. 203 The monitoring case between S-BFIR and B-BFIR, referred to as the 204 Warm Standby mode, is described in section 4.2 205 [I-D.szcl-mboned-redundant-ingress-failover]. For code and Hot 206 Standby modes described in Sections 4.1 and 4.3 207 [I-D.szcl-mboned-redundant-ingress-failover], the monitoring between 208 S-BFIR and B-BFIR may not be necessary. 210 For the monitoring between BFIR and BFERs, the BFIR node failure 211 detection is also be combined with working path failure detection. 213 3.2. Monitoring of the Working Path for a Failure 214 +--------+S1+-------+ 215 | | 216 +--v----+ +---v---+ 217 +------+ BFIR1 |..........| BFIR2 +-------+ 218 | +-----+-+ <------> +-------+ | 219 | | bfd | 220 | +--v---+ +------+ | 221 | | BFR1 | | BFR2 | | 222 | +-+---+--+- +------+ | 223 | | | ...... | 224 | | +-----+ | 225 | | | | 226 | +--v---+ +-v----+ +------+ | 227 | | BFRx | | BFRy | | BFRz | | 228 | ++-----+ ++--+--+ +------+ | 229 | | | | | 230 | | | +------------+ | 231 | | | | | 232 | +---v---+ +-v-----+ +--v----+ | 233 +--|BFER1||......||BFER2||......||BFER3|--+ 234 +--+----+ +---+---+ +--+----+ 235 | | | 236 v v v 237 R1 R2 R3 239 Figure 2: An Example of the Monitoring of the Working Path 241 In the case of a node failure detection, the path between B-BFIR and 242 S-BFIR may not be the same as the path traversed by the data flow. 243 For example, in Figure 2, the path from BFIR1 (S-BFIR) to all the 244 BFERs is different from the path between BFIR1 and BFIR2 (B-BFIR). 245 In Warm Standby mode, if the path between BFIR2 and BFIR1 is broken, 246 BFIR2 will detect the failure and interpret that as if BFIR1 is down. 247 As a result, BFIR2 will take on the role of S-BFIR. But the path 248 from BFIR1 to all or some of the BFERs may be working well and is not 249 affected by the defect between BFIR1 and BFIR2. In this situation, 250 the B-BFIR switches to S-BFIR unnecessarily, and that causes packet 251 duplication in the network and at BFERs. 253 For the failure detection between BIER edge routers, which include 254 BFIR and BFER, the path of a test packet is steered from BFIR to BFER 255 is the same as the path traversed by the monitored flow. In this 256 way, the BFER simultaneously monitors S-BFIR for node and working 257 path failure. 259 There are two options to monitor the working multicast distribution 260 tree in BIER: 262 o S-BFIR monitors all the BFERs; 264 o BFER monitors the S-BFIR. 266 In the BIER transport environment, the defect detection is based on a 267 BIER-specific mechanism, e.g., BIER Ping [I-D.ietf-bier-ping], BIER 268 BFD [I-D.ietf-bier-bfd]. BIER BFD [I-D.ietf-bier-bfd] reduces the 269 number of BFD sessions between S-BFIR and each of BFERs. Only one 270 multipoint BFD session will be built among S-BFIR and all the BFERs 271 and B-BFIR. When MVPN is used as the BIER overlay protocol, BFD 272 Discriminator attribute, defined in Section 3.1.6 in 273 [I-D.ietf-bess-mvpn-fast-failover], can be used to bootstrap the 274 multipoint BFD session between a BFIR and BFERs. In this situation, 275 only S-BFIR sends the BFD Discriminator attribute and transmits 276 periodic BFD Control messages, BFER and B-BFIR can monitor S-BFIR, 277 S-BFIR doesn't monitor BFER and B-BFIR. 279 Consider when S-BFIR monitors paths to and state of all BFERs in the 280 particular multicast group. Once S-BFIR detects that a BFER is 281 unreachable, S-BFIR notifies B-BFIR and the latter may start 282 frowarding that multicast packets to that BFER. The monitoring can 283 be achieved by a P2P BFD session between S-BFIR and each of BFERs. 284 Alternatively, a P2MP BFD session with active tails between S-BFIR 285 and BFERs can be used. This behavior can be used for the Warm 286 Standby mode. 288 When BFER monitors S-BFIR, a B-BFIR can also monitor S-BFIR. 289 Consider that a BFER or B-BFIR detects the failure of the S-BFIR. In 290 the Cold Standby mode, the BFER MUST select B-BFIR as the new S-BFIR 291 and signal to B-BFIR using a BIER overlay protocol as soon as 292 possible. In the Hot Standby mode, the BFER MUST switch to accept 293 and forward the multicast flow received from B-BFIR. In the Warm 294 Standby mode, B-BFIR becomes the S-BFIR and begins to forward the 295 flow to BFERs. 297 4. BFD and Ping 299 BFD and Ping can be used in failure detection, but there are 300 differences between them. A network administrator can select the 301 appropriate mechanism according to the actual network. 303 4.1. BIER Ping 305 [I-D.ietf-bier-ping] describes the mechanism and basic BIER 306 Operation, Administration, and Maintenance packet format that can be 307 used to perform failure detection and isolation on the BIER data 308 plane without any dependency on other layers like the IP layer. 310 In the example of Figure 1, BFER can monitor the status of BFIR and 311 the path status between BFER and BFIR. BFER1 sends the BIER Ping 312 packet to BFIR1. Suppose BFER1 does not receive several consecutive 313 responses from BFIR1 in an expected period (may be multiple of the 314 average round-trip time). In that case, the BFER1 concludes the 315 BFIR1 as a failed UMH, and BFER1 selects BFIR2 as the UMH. In the 316 Cold Standby mode, BFER1 signals to BFIR2 to start receiving the 317 multicast flow. In the Hot Standby mode, BFER begins to accept the 318 flow from BFIR2. If B-BFIR monitors S-BFIR in the Warm Standby mode 319 and detects the failure, B-BFIR takes the role of S-BFIR and begins 320 to forward the flow. 322 In this example, BFER1, BFER2, BFER3, and B-BFIR send the BIER ping 323 packets to BFIR1 separately. The timeout period MAY be set to 324 different values depending on the local performance requirement on 325 each BFER. In the Warm Standby mode, if the timeout period is 326 different on BFER and B-BFIR, and the period on B-BFIR is longer than 327 BFER, and multicast packets could be lost. 329 In the general case of a more complex BIER topology, it cannot be 330 guaranteed that the path used from BFIR1 to BFER1 is the same as in 331 the reverse direction, i.e., from BFER1 to BFIR1. If that is not 332 guaranteed and the paths are not co-routed, then this method may 333 produce false results, both false negative and false positive. The 334 former is when ping fails while the multicast path and flow are OK. 335 The latter is when the multicast path has a defect, but ping works. 336 Thus, to improve the consistency of this method of detecting a 337 failure in multicast flow transport, the path that the echo request 338 from BFER1 traverses to BFIR1 must be co-routed with the path that 339 the monitored multicast flow traverses through the BIER domain from 340 BFIR1 to BFER1. 342 4.2. BIER BFD 344 [I-D.ietf-bier-bfd] describes the application of P2MP BFD in a BIER 345 network. And it describes the procedures for using such a mode of 346 BFD protocol to verify multipoint or multicast connectivity between a 347 sender (BFIR) and one or more receivers (BFER and a redundant BFIR). 349 In the same example, BFIR1 sends the BIER Echo request packet to 350 BFERs to bootstrap a p2mp BFD session. After BFER1, BFER2 and BFER3 351 receive the Echo request packet with BFD Discriminator and the Target 352 SI-Bitstring TLVs, BFERs creates the BFD session of type 353 MultipointTail [RFC8562] to monitor the status of BFIR1 and the 354 working path. If BFERs have not received a BFD packet from BFER1 for 355 the Detection Time [RFC8562], BFER1 will treat BFIR1 as a failed UMH. 356 In the Cold Standby mode, BFER1 re-selects UMH and then signals to 357 BFIR2. As a result, BFIR2 begins to forward the multicast flow. In 358 the Hot Standby mode, BFER1 switches to accept the flow from BFIR2. 359 B-BFIR (BFIR2) monitors S-BFIR (BFIR1) in the Warm Standby mode, 360 using the same p2mp BFD session. After B-BFIR detects the failure, 361 it takes on the role of S-BFIR and begins to forward the multicast 362 flow to BFERs. 364 5. IANA Considerations 366 This document does not have any requests for IANA allocation. This 367 section can be deleted before the publication of the draft. 369 6. Security Considerations 371 Security considerations discussed in [RFC8279], [RFC8562], 372 [I-D.ietf-bier-ping], [I-D.ietf-bess-mvpn-fast-failover] and 373 [I-D.ietf-bier-bfd] apply to this document. 375 7. References 377 7.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 385 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 386 May 2017, . 388 7.2. Informative References 390 [I-D.ietf-bess-mvpn-fast-failover] 391 Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN Fast 392 Upstream Failover", draft-ietf-bess-mvpn-fast-failover-15 393 (work in progress), January 2021. 395 [I-D.ietf-bier-bfd] 396 Xiong, Q., Mirsky, G., hu, f., and C. Liu, "BIER BFD", 397 draft-ietf-bier-bfd-00 (work in progress), November 2020. 399 [I-D.ietf-bier-mld] 400 Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang, 401 Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay 402 using Multicast Listener Discovery Protocols", draft-ietf- 403 bier-mld-04 (work in progress), March 2020. 405 [I-D.ietf-bier-pim-signaling] 406 Bidgoli, H., Xu, F., Kotalwar, J., Wijnands, I., Mishra, 407 M., and Z. Zhang, "PIM Signaling Through BIER Core", 408 draft-ietf-bier-pim-signaling-11 (work in progress), 409 November 2020. 411 [I-D.ietf-bier-ping] 412 Nainar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 413 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 414 ping-07 (work in progress), May 2020. 416 [I-D.szcl-mboned-redundant-ingress-failover] 417 Shepherd, G., Zhang, Z., Liu, Y., and Y. Cheng, "Multicast 418 Redundant Ingress Router Failover", draft-szcl-mboned- 419 redundant-ingress-failover-00 (work in progress), October 420 2020. 422 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 423 RFC 792, DOI 10.17487/RFC0792, September 1981, 424 . 426 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 427 Control Message Protocol (ICMPv6) for the Internet 428 Protocol Version 6 (IPv6) Specification", STD 89, 429 RFC 4443, DOI 10.17487/RFC4443, March 2006, 430 . 432 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 433 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 434 . 436 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 437 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 438 Switched (MPLS) Data-Plane Failures", RFC 8029, 439 DOI 10.17487/RFC8029, March 2017, 440 . 442 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 443 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 444 Explicit Replication (BIER)", RFC 8279, 445 DOI 10.17487/RFC8279, November 2017, 446 . 448 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 449 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 450 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 451 2019, . 453 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 454 Ed., "Bidirectional Forwarding Detection (BFD) for 455 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 456 April 2019, . 458 Authors' Addresses 460 Zheng Zhang 461 ZTE Corporation 463 Email: zhang.zheng@zte.com.cn 465 Greg Mirsky 466 ZTE Corporation 468 Email: gregimirsky@gmail.com 470 Quan Xiong 471 ZTE Corporation 473 Email: xiong.quan@zte.com.cn 475 Yisong Liu 476 China Mobile 478 Email: liuyisong@chinamobile.com