idnits 2.17.00 (12 Aug 2021) /tmp/idnits52779/draft-mankamana-pim-graceful-dr-shutdown-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 4. The current PIM DR (R1 here) MUST not stop forwarding traffic to intended receivers unless it starts getting duplicate flows from newly elected PIM DR. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 2. The newly elected DR MUST start building the multicast tree towards the source/RP. It MUST start fail safe timer (default value 2 PIMHello interval) and MUST not generate a data driven assert. Once the timer expires, it can move back to the default assert mechanism. The reason to avoid an assert is to allow the old PIM DR on LAN to forward multicast traffic until such time the new DR is completely ready to forward multicast traffic. -- The document date (July 2, 2018) is 1412 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) == Unused Reference: 'RFC6395' is defined on line 263, but no explicit reference was found in the text == Unused Reference: 'HELLO-OPT' is defined on line 275, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Mankamana. Mishra 3 Internet-Draft Stig. Venaas 4 Intended status: Standards Track Cisco Systems 5 Expires: January 3, 2019 Mahesh. Sivakumar 6 juniper networks 7 Zheng(Sandy). Zhang 8 ZTE Corporation 9 Mikael. Abrahamsson 10 July 2, 2018 12 PIM Designated Router graceful shutdown 13 draft-mankamana-pim-graceful-dr-shutdown-00 15 Abstract 17 On a multi-access network, one of the PIM routers is elected as a 18 Designated Router (DR). On the last hop LAN, the PIM DR is 19 responsible for tracking local multicast listeners and forwarding 20 traffic to these listeners if the group is operating in PIM-SM. In 21 case of a network maintenance, where we want to bring down the 22 current DR, there is currently no way to gracefully handover the PIM 23 DR role to a new DR on the shared LAN. In this document, we propose 24 a modification to the PIM-SM protocol that allows PIM DR to 25 gracefully shutdown or go down for maintenance. We also provide a 26 procedure for PIM DR to gracefully handover its role to a new PIM DR 27 in the network. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 3, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 66 3.1. Proposed Mechanism . . . . . . . . . . . . . . . . . . . 4 67 3.2. Impact on the network . . . . . . . . . . . . . . . . . . 4 68 3.2.1. Every PIM router supports the new specification on 69 the shared LAN . . . . . . . . . . . . . . . . . . . 4 70 3.2.2. Hybrid shared LAN, some of PIM router does not 71 support specification . . . . . . . . . . . . . . . . 5 72 4. PIM Hello option . . . . . . . . . . . . . . . . . . . . . . 5 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 9.2. Informative References . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 On a multi-access LAN such as an Ethernet, one of the PIM routers is 85 elected as a DR. The PIM DR represents the LAN segment/broadcast 86 domain in the PIM topology tree and has two roles to play in the PIM- 87 SM protocol. For sources connected to the segment, the PIM DR is 88 responsible for registering one or more active sources with the 89 Rendezvous Point (RP) if the group is operating in PIM-SM. In 90 addition, on the last hop LAN, the PIM DR is responsible for tracking 91 local multicast listeners and forwarding data traffic to these 92 listeners if the group is operating in PIM-SM. 94 Consider the following last hop LAN in Figure 1: 96 ( core networks ) 97 | | | 98 | | | 99 R1 R2 R3 100 | | | 101 --(last hop LAN)-- 102 | 103 | 104 (many receivers) 106 Figure 1: Last Hop LAN 108 Assume R1 is elected as the Designated Router. According to 109 [RFC4601], R1 will be responsible for forwarding traffic to that LAN 110 on behalf of any local members. In addition to keeping track of IGMP 111 and MLD membership reports, R1 is also responsible for initiating the 112 creation of source and/or shared trees towards the sources or the 113 RPs. 115 If R1 needs to go on planned maintenance, the current approach is to 116 lower the DR priority which would make sure that another PIM router 117 on the LAN gets elected as the new DR and starts forwarding multicast 118 traffic. 120 With this approach, R1 gives away DR role as soon as new priority is 121 configured and a new PIM DR (lets assume R3) starts building a 122 multicast tree and starts forwarding multicast traffic on the LAN. 123 However, this could cause traffic disruption for the duration it 124 takes for R3 to build the upstream multicast tree. 126 This draft defines a mechanism in the PIM protocol to handover DR 127 role gracefully and as a result minimize traffic disruption. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119] . 135 With respect to PIM, this document follows the terminology that has 136 been defined in [RFC4601] and [RFC7761] . Many places this draft 137 would refer to PIM RFC [RFC4601] but it MUST be considered [RFC7761] 138 as well. 140 3. Protocol Specification 142 In this draft, we define a new hello option to enable the graceful 143 handover of a DR during planned maintenance.In Section 3.1, we 144 describe the proposed mechanism. In Section 3.2, we evaluate the 145 impact of the mechanism on the network under different conditions. 146 Section 4 describes the proposed hello option. 148 3.1. Proposed Mechanism 150 1. In Figure-1, assume that R1 is current PIM DR that needs to go on 151 planned maintenance. R1 MUST sends out a PIM Hello with option 152 described in Section 4. The DR Priority MUST be set to 0. R1 153 MUST also set its assert metric to (PIM_ASSERT_INFINITY - 1) 155 2. The PIM assert metric modification would make sure that R1 does 156 not become an assert winner 158 3. Sending DR priority as 0 would make sure to have default 159 transition in case new DR does not support the new specification 161 4. The current PIM DR (R1 here) MUST not stop forwarding traffic to 162 intended receivers unless it starts getting duplicate flows from 163 newly elected PIM DR. 165 5. A failsafe timer SHOULD be used to stop forwarding multicast 166 traffic towards receiver. It SHOULD be set to at least two PIM 167 Hello intervals. But it SHOULD also be a configurable value. 169 3.2. Impact on the network 171 This section covers impact of PIM hello with Section 4 option 173 3.2.1. Every PIM router supports the new specification on the shared 174 LAN 176 1. In Figure-1, if each of the PIM routers on shared LAN supported 177 this specification, new DR election would be done as per 178 [RFC4601] 180 2. The newly elected DR MUST start building the multicast tree 181 towards the source/RP. It MUST start fail safe timer (default 182 value 2 PIMHello interval) and MUST not generate a data driven 183 assert. Once the timer expires, it can move back to the default 184 assert mechanism. The reason to avoid an assert is to allow the 185 old PIM DR on LAN to forward multicast traffic until such time 186 the new DR is completely ready to forward multicast traffic. 188 3. It MUST forward multicast flow to receivers as soon as it gets 189 the multicast flow from the source/RP 191 3.2.2. Hybrid shared LAN, some of PIM router does not support 192 specification 194 There are two cases to consider, 196 1. If the new DR supports this specification, it would follow 197 Section 3.1 199 2. If the new DR does not support this specification, there is no 200 need for any special handling as the new DR would take over as it 201 does today. It would assert as soon as it gets elected as DR and 202 the old DR would become the assert loser as it had already 203 adjusted its assert metric to PIM_ASSERT_INFINITY - 1 205 4. PIM Hello option 207 0 1 2 3 208 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Type = TBD | Length | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 2: Graceful DR handoff Hello Option 214 where 216 Type : DR Graceful handoff 218 Length: 2 220 5. IANA Considerations 222 A new PIM Hello option is TBD.. 224 6. Security Considerations 226 Security of the new PIM Hello Options is only guaranteed by the 227 security of PIM Hello message, so the security considerations for PIM 228 Hello messages as described in PIM-SM [RFC4601] apply here. 230 7. Acknowledgement 231 8. Contributors 233 In addition to the authors listed on the front page, the following 234 co-authors have also contributed to original idea. 236 Krishna Muddenahally Ananthamurthy 238 Cisco Systems 240 Sameer Gulrajani 242 Cisco systems 244 Rishabh Parekh 246 Cisco systems 248 9. References 250 9.1. Normative References 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, 254 DOI 10.17487/RFC2119, March 1997, 255 . 257 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 258 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 259 Protocol Specification (Revised)", RFC 4601, 260 DOI 10.17487/RFC4601, August 2006, 261 . 263 [RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) 264 Hello Option for PIM", RFC 6395, DOI 10.17487/RFC6395, 265 October 2011, . 267 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 268 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 269 Multicast - Sparse Mode (PIM-SM): Protocol Specification 270 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 271 2016, . 273 9.2. Informative References 275 [HELLO-OPT] 276 IANA, "PIM Hello Options", IANA PIM-HELLO-OPTIONS, March 277 2007. 279 Authors' Addresses 281 Mankamana Mishra 282 Cisco Systems 283 821 Alder Drive, 284 MILPITAS, CALIFORNIA 95035 285 UNITED STATES 287 Email: mankamis@cisco.com 289 Stig Venaas 290 Cisco Systems 291 821 Alder Drive, 292 MILPITAS, CALIFORNIA 95035 293 UNITED STATES 295 Email: svenaas@cisco.com 297 Mahesh Sivakumar 298 juniper networks 299 1133 Innovation Way 300 Sunnyvale, CALIFORNIA 94089 301 UNITED STATES 303 Email: sivakumar.mahesh@gmail.com 305 Zheng(Sandy) Zhang 306 ZTE Corporation 307 No. 50 Software Ave, Yuhuatai Distinct 308 Nanjing 309 China 311 Email: zhang.zheng@zte.com.cn 313 Mikael Abrahamsson 315 Email: swmike@swm.pp.se