Network Working Group | R. Chokkanathapuram |
Internet-Draft | R. Banthia |
Intended status: Standards Track | Cisco Systems, Inc. |
Expires: December 30, 2018 | June 28, 2018 |
PIM Router Graceful Insertion and Removal
draft-raunak-pim-gir-support-00
Graceful Insertion and Removal (GIR) of routers is often adopted by many network administrators as an alternative to ISSU. This document discusses various scenarios, requirements and possible solutions to make PIM gracefully shut down and isolate the multicast router with minimal network disruption when a router goes through maintenance procedures.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 30, 2018.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
When a network administrator wishes to perform maintenance activity on a router, a system maintenance mode command need to be configured. This isolates the router from the network by gracefully shutting down various protocols running on the router. Multicast protocols will also require graceful migration in order to achieve minimal traffic disruption when a maintenance activity is performed on a router. This document proposes a possible solution to perform GIR with PIM routers gracefully.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] .
With respect to PIM, this document follows the terminology that has been defined in [RFC7761]
The proposed change described in this specification applies to PIM routers only.
Multicast routing protocol uses Unicast reachability information to find unique Reverse Path Forwarding Neighbor (RPF). Any change in unicast routing triggers multicast RPF changes. Multicast flows need to change the RPF in a graceful manner to have minimal or no disruption in traffic flow. To achieve graceful RPF change, PIM should not change RPF immediately following unicast routing change. PIM should join the new path and wait for the traffic to arrive on the new path before pruning the old path. Until the packets arrive on the new path, the packets are accepted and forwarded on the old path. Since we have not changed the RPF to new one, we would see RPF failures. The RPF failures on the new path will indicate that the flow is available on the new path, upon which the RPF for the flows will be changed from old to new. Using this method, we will be able to achieve non-stop forwarding of multicast traffic thereby minimizing traffic disruption. The graceful RPF change, however, is not advisable in a normal RPF change scenario. This is because old path could be down due to link failures and the RPF change may take more time which could increase convergence time. Multicast flows can do a graceful RPF change in a GIR scenario since the flow will be available via the old path.
A multicast router undergoing a graceful insertion/removal must indicate the same to all the routers in PIM domain. This will ensure that all routers will gracefully change RPF for the multicast flows within the GIR window. This information needs to be propagated before the unicast metrics are altered by the GIR router. To achieve this, a PIM Flooding Mechanism message (PFM) [RFC8364] TLV is originated from the router undergoing GIR. The GIR details will be carried in the PFM TLV. This message is flooded periodically in the PIM domain and the RECOMMENDED interval to send this message is 60 secs. The propagation of this message will ensure that all the routers (in the PIM domain) knows the router undergoing GIR and can gracefully migrate flows from old path to new path when the unicast infinite metrics are advertised from the router undergoing GIR in the GIR window.
Procedure for PIM routers (GIR mode)-
The above method could be further optimized if PFM messages could carry the source prefixes of the multicast states present on the GIR router. The routers receiving the PFM GIR message can examine the source prefixes and move to Graceful RPF change mode only if the routers have the multicast state for the source prefixes. With this, not all routers needs to do Graceful RPF change. This will ensure Graceful RPF change occurs only on the routers that are impacted by the router undergoing GIR.
The same method as described above will be used to gracefully insert a router with no traffic disruption after system maintenance mode. When a router is inserted into network, it will send the PFM GIR message with the graceful-rpf-start timer value set to 0, and graceful-rpf-stop timer set to seconds until Graceful RPF stop. During this window, the inserted router will start bringing up the unicast protocols. Every router in the PIM domain will examine the PFM message and do a Graceful RPF change for the window specified in the message. Once the GIR router is inserted and fully operational, it should send at least one message with both timers (graceful-rpf-start and graceful-rpf-stop) set to 0
The router undergoing GIR must set the Transitive bit to 1 in the PFM message so that when a router that doesn't support GIR, receives a PFM GIR TLV, it will forward the message to the PIM neighbors.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Type = TBD | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Graceful RPF Start | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Graceful RPF Stop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PIM GIR TLV
where
A new PIM PFM option is TBD for GIR.
Security of the new PFM TLV is only guaranteed by the security of PFM message, so the security considerations for PFM message as described in [RFC8364] apply here.
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[RFC7761] | Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z. and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016. |
[RFC8364] | Wijnands, IJ., Venaas, S., Brig, M. and A. Jonasson, "PIM Flooding Mechanism (PFM) and Source Discovery (SD)", RFC 8364, DOI 10.17487/RFC8364, March 2018. |