idnits 2.17.1 draft-raunak-pim-gir-support-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 -- The document date (June 28, 2018) is 2129 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) ** Downref: Normative reference to an Experimental RFC: RFC 8364 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Chokkanathapuram 3 Internet-Draft R. Banthia 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: December 30, 2018 June 28, 2018 7 PIM Router Graceful Insertion and Removal 8 draft-raunak-pim-gir-support-00 10 Abstract 12 Graceful Insertion and Removal (GIR) of routers is often adopted by 13 many network administrators as an alternative to ISSU. This document 14 discusses various scenarios, requirements and possible solutions to 15 make PIM gracefully shut down and isolate the multicast router with 16 minimal network disruption when a router goes through maintenance 17 procedures. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 30, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 2 56 4. Graceful RPF change . . . . . . . . . . . . . . . . . . . . . 2 57 5. GIR removal procedure for a PIM router . . . . . . . . . . . 3 58 6. GIR insertion procedure for a PIM router . . . . . . . . . . 4 59 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 5 60 8. PIM GIR TLV . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 11. Normative References . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 When a network administrator wishes to perform maintenance activity 69 on a router, a system maintenance mode command need to be configured. 70 This isolates the router from the network by gracefully shutting down 71 various protocols running on the router. Multicast protocols will 72 also require graceful migration in order to achieve minimal traffic 73 disruption when a maintenance activity is performed on a router. 74 This document proposes a possible solution to perform GIR with PIM 75 routers gracefully. 77 2. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119] . 83 With respect to PIM, this document follows the terminology that has 84 been defined in [RFC7761] 86 3. Applicability 88 The proposed change described in this specification applies to PIM 89 routers only. 91 4. Graceful RPF change 93 Multicast routing protocol uses Unicast reachability information to 94 find unique Reverse Path Forwarding Neighbor (RPF). Any change in 95 unicast routing triggers multicast RPF changes. Multicast flows need 96 to change the RPF in a graceful manner to have minimal or no 97 disruption in traffic flow. To achieve graceful RPF change, PIM 98 should not change RPF immediately following unicast routing change. 99 PIM should join the new path and wait for the traffic to arrive on 100 the new path before pruning the old path. Until the packets arrive 101 on the new path, the packets are accepted and forwarded on the old 102 path. Since we have not changed the RPF to new one, we would see RPF 103 failures. The RPF failures on the new path will indicate that the 104 flow is available on the new path, upon which the RPF for the flows 105 will be changed from old to new. Using this method, we will be able 106 to achieve non-stop forwarding of multicast traffic thereby 107 minimizing traffic disruption. The graceful RPF change, however, is 108 not advisable in a normal RPF change scenario. This is because old 109 path could be down due to link failures and the RPF change may take 110 more time which could increase convergence time. Multicast flows can 111 do a graceful RPF change in a GIR scenario since the flow will be 112 available via the old path. 114 5. GIR removal procedure for a PIM router 116 A multicast router undergoing a graceful insertion/removal must 117 indicate the same to all the routers in PIM domain. This will ensure 118 that all routers will gracefully change RPF for the multicast flows 119 within the GIR window. This information needs to be propagated 120 before the unicast metrics are altered by the GIR router. To achieve 121 this, a PIM Flooding Mechanism message (PFM) [RFC8364] TLV is 122 originated from the router undergoing GIR. The GIR details will be 123 carried in the PFM TLV. This message is flooded periodically in the 124 PIM domain and the RECOMMENDED interval to send this message is 60 125 secs. The propagation of this message will ensure that all the 126 routers (in the PIM domain) knows the router undergoing GIR and can 127 gracefully migrate flows from old path to new path when the unicast 128 infinite metrics are advertised from the router undergoing GIR in the 129 GIR window. 131 Procedure for PIM routers (GIR mode)- 133 1. The router undergoing GIR (GIR router) will send a PFM message 134 with a new TLV option (GIR TLV) to all its PIM neighbors 135 indicating that the router wishes to go to maintenance mode. The 136 router could send more than one PFM message so that the loss of 137 the PFM messages are minimized. The value fields in the TLV will 138 be populated with the following hold-time values - 140 1. graceful-rpf-start - This value indicates the seconds until 141 the PIM router will start doing graceful RPF change 143 2. graceful-rpf-stop - This value indicates the seconds after 144 which the PIM router will stop doing graceful RPF change. 145 The time period between the graceful-rpf-start and graceful- 146 rpf-stop indicates the duration during which the routers in 147 the network will do graceful RPF changes for multicast flow. 149 2. Upon receipt of the PFM message with GIR TLV option from GIR 150 router, PIM neighbors will compute the RPF towards the originator 151 ip address in the incoming PFM message. If the RPF matches with 152 the interface where this message is received, the router will 153 perform the following, else pim will just drop the message. 155 1. Start a timer for graceful-rpf-start, if not already started. 156 Once the graceful-rpf-start timer expires, the routers will 157 be in graceful RPF change mode until the hold-time period 158 stop. During this time period, router will do Graceful RPF 159 change (as described in section above) as soon as it receives 160 unicast metric change. The unicast infinite metric change 161 from the router undergoing GIR has to be sequenced between 162 the advertised graceful-rpf-start and graceful-rpf-stop. 164 2. Forward PFM message with the GIR TLV to its immediate PIM 165 neighbors. This is to propagate PFM message with the GIR TLV 166 to all the routers in the PIM domain. 168 The above method could be further optimized if PFM messages could 169 carry the source prefixes of the multicast states present on the GIR 170 router. The routers receiving the PFM GIR message can examine the 171 source prefixes and move to Graceful RPF change mode only if the 172 routers have the multicast state for the source prefixes. With this, 173 not all routers needs to do Graceful RPF change. This will ensure 174 Graceful RPF change occurs only on the routers that are impacted by 175 the router undergoing GIR. 177 6. GIR insertion procedure for a PIM router 179 The same method as described above will be used to gracefully insert 180 a router with no traffic disruption after system maintenance mode. 181 When a router is inserted into network, it will send the PFM GIR 182 message with the graceful-rpf-start timer value set to 0, and 183 graceful-rpf-stop timer set to seconds until Graceful RPF stop. 184 During this window, the inserted router will start bringing up the 185 unicast protocols. Every router in the PIM domain will examine the 186 PFM message and do a Graceful RPF change for the window specified in 187 the message. Once the GIR router is inserted and fully operational, 188 it should send at least one message with both timers (graceful-rpf- 189 start and graceful-rpf-stop) set to 0 191 7. Compatibility 193 The router undergoing GIR must set the Transitive bit to 1 in the PFM 194 message so that when a router that doesn't support GIR, receives a 195 PFM GIR TLV, it will forward the message to the PIM neighbors. 197 8. PIM GIR TLV 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 |1| Type = TBD | Length = 8 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Graceful RPF Start | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Graceful RPF Stop | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 1: PIM GIR TLV 210 where 212 Type : TBD 214 Length : The length of the value in octets 216 Graceful RPF Start : Timer value in seconds until PIM router start 217 doing graceful RPF change 219 Graceful RPF Stop : Timer value in seconds after which the PIM 220 router will stop doing graceful RPF change 222 9. IANA Considerations 224 A new PIM PFM option is TBD for GIR. 226 10. Security Considerations 228 Security of the new PFM TLV is only guaranteed by the security of PFM 229 message, so the security considerations for PFM message as described 230 in [RFC8364] apply here. 232 11. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, 236 DOI 10.17487/RFC2119, March 1997, 237 . 239 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 240 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 241 Multicast - Sparse Mode (PIM-SM): Protocol Specification 242 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 243 2016, . 245 [RFC8364] Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM 246 Flooding Mechanism (PFM) and Source Discovery (SD)", 247 RFC 8364, DOI 10.17487/RFC8364, March 2018, 248 . 250 Authors' Addresses 252 Ramakrishnan Chokkanathapuram 253 Cisco Systems, Inc. 254 Tasman Drive 255 San Jose CA 95134 256 United States of America 258 Email: ramaksun@cisco.com 260 Raunak Banthia 261 Cisco Systems, Inc. 262 Tasman Drives 263 San Jose CA 95134 264 United States of America 266 Email: rbanthia@cisco.com