idnits 2.17.1 draft-xiong-bier-resilience-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 : ---------------------------------------------------------------------------- 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 (October 12, 2018) is 2022 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-hu-bier-bfd-02 == Outdated reference: A later version (-19) exists of draft-ietf-bfd-multipoint-18 == Outdated reference: A later version (-10) exists of draft-ietf-bfd-multipoint-active-tail-09 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER WG Quan Xiong 3 Internet-Draft Fangwei Hu 4 Intended status: Standards Track Greg Mirsky 5 Expires: April 15, 2019 ZTE Corporation 6 October 12, 2018 8 The Resilience for BIER 9 draft-xiong-bier-resilience-01.txt 11 Abstract 13 Bit Index Explicit Replication (BIER) is an architecture that 14 specifies a solution for the forwarding of multicast data packets. 15 In some scenarios, the resilience should be provided to guarantee the 16 multicast data is protected by a given backup resource and forwarded 17 successfully to the receivers in BIER-specific network. 19 This document discusses the resilience use cases, requirements and 20 proposes solutions for BIER, including the protection mechanisms and 21 detection methods. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 15, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. BIER Resilience Use Cases . . . . . . . . . . . . . . . . . . 3 62 3.1. End-to-End 1+1 Protection . . . . . . . . . . . . . . . . 3 63 3.2. End-to-End 1:1 Protection . . . . . . . . . . . . . . . . 4 64 3.3. BIER Link Protection . . . . . . . . . . . . . . . . . . 5 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 7.2. Informational References . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 [RFC8279] introduces Bit Index Explicit Replication (BIER) 76 architecture and specifies a solution for the forwarding of multicast 77 data packets. The routers which support BIER are known as Bit- 78 Forwarding Router (BFR) and the multicast data packet enters a BIER 79 domain at a Bit-Forwarding Ingress Router (BFIR) and leave at one or 80 more Bit-Forwarding Egress Routers (BFERs). 82 [I-D.eckert-bier-te-frr] provides some protection mechanisms for 83 traffic engineering of BIER. However, there is no mechanism to 84 protect multicast traffic against BIER-specific network failures. In 85 some scenarios, the resilience should be provided to guarantee the 86 multicast data is protected by a given backup resource and forwarded 87 successfully to the receivers in BIER-specific network. 89 This document describes the resilience use cases and requirements for 90 BIER-specific network and discusses the protection mechanisms and 91 detection methods. 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 1.2. Terminology 101 The terminology is defined as [RFC8279]. 103 2. Requirements 105 The following lists the resilience requirements for BIER-specific 106 multicast domain including the protection mechanisms and detection 107 methods. 109 (1) The listed requirements MUST be supported by any transport layer 110 over which the BIER layer can be realized. 112 (2) BIER protection type MAY be defined and configured from a 113 centralized controller or management network including BIER end- 114 to-end protection and link/node protection and related 115 information. 117 (3) It is required to support the failure detection and notification 118 mechanisms. 120 (4) It is required to support the fast protection switching for the 121 BIER packets within the limited time. 123 3. BIER Resilience Use Cases 125 The resilience use cases for a BIER-specific network should be 126 considered including end-to-end and link protection scenarios. The 127 protection and related detection mechanisms MAY be provided for BIER 128 resilience against failures such as link or nodes. 130 3.1. End-to-End 1+1 Protection 132 The end-to-end protection mechanisms for a BIER-specific network 133 should be considered in some scenarios like shown in Figure 1. It 134 includes end-to-end 1+1 and 1:1 protection use cases. Two disjoint 135 end-to-end paths that are available for 1+1 or 1:1 protection from 136 BFIR to BFERs should be provided, and one of them may be configured 137 to be the protection path for the working path. In this example the 138 working path could be BFIR->BFR1->BFR2->BFR3->BFER1 and 139 BFIR->BFR1->BFR2->BFR3->BFER2; and then the protection path is 140 BFIR->BFR6->BFR5->BFR4->BFER1 and BFIR->BFR6->BFR5->BFR4->BFER2. 142 +----+ +----+ +----+ +-----+ 143 |BFR1|----|BFR2|-----|BFR3|--------|BFER1| 144 +----+ +----+ +----+ +-----+ 145 / \ / 146 / \ / 147 +----+ \ / 148 |BFIR| \/ 149 +----+ /\ 150 \ / \ 151 \ / \ 152 +----+ +----+ +----+ +-----+ 153 |BFR6|----|BFR5|------|BFR4|------|BFER2| 154 +----+ +----+ +----+ +-----+ 156 Figure 1: BIER End-to-End Protection 158 For 1+1 protection scenario, the multicast traffic MUST be sent 159 across the network through both the working and backup paths. When 160 the link or node failure occurs inf the working path, the BFERs need 161 to switch to receiving the data flow from the protection path. 163 The failure detection mechanism for end-to-end 1+1 protection 164 scenario MUST be able to monitor and detect multicast failures in 165 working and protection paths. P2MP BFD [I-D.ietf-bfd-multipoint] MAY 166 be used to verify multipoint connectivity between a BFIR and a set of 167 BFERs. [I-D.hu-bier-bfd] describes the use of p2mp BFD in a BIER 168 domain. 170 End-to-End 1+1 protection provides fast switch but low resource 171 utilization. All BFERs MAY receive two copies from two paths in the 172 no-failure scenario, and the receivers MUST be able to choose one of 173 them and eliminate the duplication. 175 3.2. End-to-End 1:1 Protection 177 This section discusses the end-to-end 1:1 protection for BIER. If 178 duplicate transmission is not desirable for some networks, end-to-end 179 1:1 protection mechanism may be taken into consideration where only 180 one copy is sent to each receiver. The BFIR will send multicast 181 flows onto the working path and switch to the backup path when a 182 failure occurs. 184 The failure detection mechanism for end-to-end 1:1 protection 185 scenario MUST be able to monitor and detect multicast failures in the 186 receivers (tails) and notify the head node. BIER-specific extensions 187 MAY be proposed based on [I-D.ietf-bfd-multipoint-active-tail]. The 188 P2MP active tail detection method extends the mechanism defined in 190 [I-D.ietf-bfd-multipoint]. It allows tails to notify the head of the 191 failure of the multicast path and can be used in multipoint and 192 multicast networks, e.g., in BIER domain. 194 If P2MP BFD uses the active tail mode, then when one of the BFERs 195 detects the failure of the working path, it will send a message to 196 the BFIR. The BFIR will notify BFERs of switchover and start 197 forwarding the multicast flows over the protection path. 199 3.3. BIER Link Protection 201 Local protection, i.e., link or node protection, MAY be considered 202 for BIER domain as an alternative to end-to-end protection. The 203 nodes which are the BFRs in BIER network and they exchange the 204 information needed for them to forward packets to each other using 205 BIER. The node protection MAY be provided by using mechanisms 206 already existing in the underlay network, for example, described in 207 [I-D.eckert-bier-te-frr]. 209 A BFR MAY send BIER packets to directly connected BIER neighbors 210 through a BIER link without requiring a routing underlay. Link 211 protection SHOULD be considered in BIER domain. The detection of 212 link failure MAY use the Point-to-Point BFD detection defined in 213 [RFC5880]. A set of extension for BIER-specific P2P BFD SHOULD be 214 proposed in further discussion. 216 As shown in Figure 2, the BIER path from BFIR to BFERs is 217 BFIR->BFR4->BFR3 ->BFR2->BFER1 and BFIR->BFR4->BFR3->BFER2. If the 218 BIER link from BFR4 to BFR3 fails, the failure can be protected by 219 the backup paths over BFR4->BFR1->BFR2 ->BFR3. 221 +-----+ +-----+ +--+--+ 222 |BFR1 +--------+BFR2 +-------+BFER1| 223 +--+--+ +--+--+ +--+--+ 224 | | 225 | | 226 +--+--+ +--+--+ +--+--+ +--+--+ 227 |BFIR +--------+BFR4 +--------+BFR3 +-------+BFER2| 228 +--+--+ +-----+ +-----+ +-----+ 230 Figure 2: BIER Link Protection 232 As discussed in [I-D.eckert-bier-te-frr], the BIER link protection 233 MAY use the existing RSVP-TE/P2MP or SR tunnel bypass. When a node 234 detects a failure on a link, it MAY be assumed that the link has 235 failed and the traffic is switched onto the pre-established backup 236 path to get packets to the downstream node. 238 Also, as discussed in [RFC7490], the Topology Independent Loop-free 239 Alternate Fast Re-route (TI-LFA) Fast Reroute (FRR) approach that 240 achieves guaranteed coverage against link or node failure in the 241 Interior Gateway Protocol (IGP) network MAY be applied in BIER 242 network. 244 4. Security Considerations 246 Security aspects of protection in BIER domain may be considered in 247 relation to the data plane, and handling the dedicated OAM packets 248 used to detect, signal a failure, coordinate the state in the BIER 249 protection domain. 251 5. IANA Considerations 253 TBD 255 6. Acknowledgements 257 TBD 259 7. References 261 7.1. Normative References 263 [I-D.hu-bier-bfd] 264 hu, f., Mirsky, G., Xiong, Q., and C. Liu, "BIER BFD", 265 draft-hu-bier-bfd-02 (work in progress), October 2018. 267 [I-D.ietf-bfd-multipoint] 268 Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for 269 Multipoint Networks", draft-ietf-bfd-multipoint-18 (work 270 in progress), June 2018. 272 [I-D.ietf-bfd-multipoint-active-tail] 273 Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD 274 Multipoint Active Tails.", draft-ietf-bfd-multipoint- 275 active-tail-09 (work in progress), June 2018. 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 283 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 284 . 286 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 287 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 288 RFC 7490, DOI 10.17487/RFC7490, April 2015, 289 . 291 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 292 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 293 Explicit Replication (BIER)", RFC 8279, 294 DOI 10.17487/RFC8279, November 2017, 295 . 297 7.2. Informational References 299 [I-D.eckert-bier-te-frr] 300 Eckert, T., Cauchie, G., Braun, W., and M. Menth, 301 "Protection Methods for BIER-TE", draft-eckert-bier-te- 302 frr-03 (work in progress), March 2018. 304 Authors' Addresses 306 Quan Xiong 307 ZTE Corporation 308 No.6 Huashi Park Rd 309 Wuhan, Hubei 430223 310 China 312 Phone: +86 27 83531060 313 Email: xiong.quan@zte.com.cn 315 Fangwei Hu 316 ZTE Corporation 317 No.889 Bibo Rd 318 Shanghai 201203 319 China 321 Phone: +86 21 68896273 322 Email: hu.fangwei@zte.com.cn 323 Greg Mirsky 324 ZTE Corporation 325 USA 327 Email: gregimirsky@gmail.com