idnits 2.17.1 draft-zhang-bier-source-protection-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 129: '...e timeout period MAY be set to a diffe...' RFC 2119 keyword, line 160: '...iod on each BFER MAY be set to differe...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-hu-bier-bfd-04 == Outdated reference: A later version (-13) exists of draft-ietf-bier-ping-05 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER WG Zheng. Zhang 3 Internet-Draft Greg. Mirsky 4 Intended status: Informational Quan. Xiong 5 Expires: January 8, 2020 ZTE Corporation 6 July 7, 2019 8 BIER Source Protection 9 draft-zhang-bier-source-protection-00 11 Abstract 13 This document describes the multicast source protection functions in 14 Bit Index Explicit Replication BIER domain. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 8, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Multicast Source Protection . . . . . . . . . . . . . . . . . 2 52 2.1. BIER Ping . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. BIER BFD . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 4. Normative References . . . . . . . . . . . . . . . . . . . . 4 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 58 1. Introduction 60 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 61 that provides multicast forwarding through a "BIER domain" without 62 requiring intermediate routers to maintain any multicast related per- 63 flow state. BIER also does not require any explicit tree-building 64 protocol for its operation. A multicast data packet enters a BIER 65 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 66 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 68 To protect the source node it may be transmitting to two or more 69 BFIRs. Based on local policies, BFERs may elect to use the same BFIR 70 or different BFIRs as the source of the multicast flow. The BFIR and 71 the path in use are referred to as working while all alternative 72 available BFIRs and paths that can be used to receive the same 73 multicast flow are referred to as protection. For a BFER, when 74 either the working BFIR or the working path fail, the BFER can select 75 one of protection BFIRs to get the multicast flow. The shorter the 76 detection time is, the faster the flow recovers. 78 This document discusses the functions that can be used in failure 79 detection for multicast source protection. 81 2. Multicast Source Protection 83 Two BFIRs independently advertise the source of the multicast flow to 84 BFERs. The precise type of advertisement depends on the overlay 85 protocol being used, e.g., MLD, MVPN, EVPN. BFER selects one BFIR as 86 the UMH (Upstream Multicast Hop). Different BFERs may select the 87 same BFIR or different BFIRs according to the local policy. 89 +--------+S1+-------+ 90 | | 91 +--v----+ +---v---+ 92 +------+ BFIR1 | | BFIR2 +-------+ 93 | +-------+ +-------+ | 94 | | 95 | | 96 | | 97 | +-------+ +-------+ +-------+ | 98 +--|BFER1|--------|BFER2|---- ---|BFER3|--+ 99 +--+----+ +---+---+ +--+----+ 100 | | | 101 v v v 102 R1 R2 R3 103 Figure 1 105 For example, a multicast source S1 is connected to BFIR1 and BFIR2. 106 BFIR1 and BFIR2 advertise the source information to BFERs. It is 107 assumed that BFER1, BFER2, and BFER3 all choose BFIR1 as the UMH. 108 BFERs signal to BFIR1 to get the multicast flow from S1. 110 In case BFIR1 fails, or the path from BFIR1 to BFER1 is broken, BFER1 111 should select BFIR2 as the UMH. But if the timeout period is too 112 long, the multicast flow will be significantly affected. 114 2.1. BIER Ping 116 [I-D.ietf-bier-ping] describes the mechanism and basic BIER OAM 117 packet format that can be used to perform failure detection and 118 isolation on BIER data plane without any dependency on other layers 119 like the IP layer. 121 In the example of Figure 1, BFER can monitor the status of BFIR and 122 the path status between BFER and BFIR. BFER1 sends the BIER Ping 123 packet to BFIR1. If BFER1 does not receive responses from BFIR1 in a 124 period of time, BFER1 will treat BFIR1 as a failed UMH, and BFER1 125 will select BFIR2 as the UMH and signal to BFIR2 to get multicast 126 flow. 128 In this example, BFER1, BFER2, and BFER3 send BIER ping packet to 129 BFIR1 separately. The timeout period MAY be set to a different 130 values depending on the local performance requirement on each BFER. 132 In general case of more complex BIER topology, it cannot be 133 guaranteed that the path used from BFIR1 to BFER1 is the same as in 134 the reverse direction, i.e., from BFER1 to BFIR1. If that is not 135 guaranteed and the paths are not co-routed, then this method may 136 produce false results, both false negative and false positive. The 137 former is when ping fails while the multicast path and flow are OK. 138 The latter is when the multicast path has defect but ping works. 139 Thus, to improve consistency of this method of detecting a failure in 140 multicast flow transport, the path that the echo request from BFER1 141 traverses to BFIR1 must be co-routed with the path that the monitored 142 multicast flow traverses through the BIER domain from BFIR1 to BFER1. 144 2.2. BIER BFD 146 [I-D.hu-bier-bfd] describes the application of P2MP BFD in BIER 147 network. And it describes the procedures for using such mode of BFD 148 protocol to verify multipoint or multicast connectivity between a 149 sender (BFIR) and one or more receivers (BFERs). 151 In the same example, BFIR1 sends the BIER Echo request packet to 152 BFERs to bootstrap a p2mp BFD session. After BFER1, BFER2 and BFER3 153 receive the Echo request packet with BFD Discriminator and the Target 154 SI-Bitstring TLVs, BFERs creates the BFD session of type 155 MultipointTail [RFC8562] to monitor the status of BFIR1 and the 156 working path. If BFERs have not received BFD packet from BFER1 for 157 the Detection Time [RFC8562], BFER1 will treat BFIR1 as a failed UMH, 158 and signal to BFIR2 to get the multicast flow. 160 The timeout period on each BFER MAY be set to different value 161 depending on the local performance requirement on each BFER. BFER 162 monitors BFIR separately and selects its UMH independently from 163 selections reached by other BFERs. 165 3. Security Considerations 167 Security considerations discussed in [RFC8279], [RFC8562], 168 [I-D.ietf-bier-ping] and [I-D.hu-bier-bfd] apply to this document. 170 4. Normative References 172 [I-D.hu-bier-bfd] 173 Xiong, Q., Mirsky, G., hu, f., and C. Liu, "BIER BFD", 174 draft-hu-bier-bfd-04 (work in progress), July 2019. 176 [I-D.ietf-bier-ping] 177 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 178 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 179 ping-05 (work in progress), April 2019. 181 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 182 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 183 Explicit Replication (BIER)", RFC 8279, 184 DOI 10.17487/RFC8279, November 2017, 185 . 187 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 188 Ed., "Bidirectional Forwarding Detection (BFD) for 189 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 190 April 2019, . 192 Authors' Addresses 194 Zheng Zhang 195 ZTE Corporation 197 Email: zzhang_ietf@hotmail.com 199 Greg Mirsky 200 ZTE Corporation 202 Email: gregimirsky@gmail.com 204 Quan Xiong 205 ZTE Corporation 207 Email: xiong.quan@zte.com.cn