Network Working Group Indranil Bhattacharya Internet-Draft Brocade Communication Intended status: Experimental January 12, 2015 Expires: July 12, 2015 PIM fast recovery mechanism draft-bhattacharya-pim-fast-recovery-00 Abstract When a PIM router reboots, either because of uncontrolled failover or because of ISSU, it needs to reconcile the PIM entries. For this, rebooting router sends PIM hello with new GenId. In reponse, neighbors send a new hello and replay PIM J/P message. Regardless an application maintaing full mroute states, the rebooting route must wait for this replay to complete only after which it can mark the oif reconciliation complete. This process is undeterministic today. This draft proposes a new mechanism to achieve a faster reconcilaition time. For this a new Hello option and a new message type has been introduced. Status of This Memo 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 http://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 July 12, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Copyright (c) 2014 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 (http://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. Table of Contents 1. Introduction 2. Mechanism in detail 3. PIM GR COMPLETE message format 4. PIM GR RUNNING timer details 5. References 1. Introduction It is often required for a rebooted PIM router to completely rebuild its mroute database before reconciling with forwarding modules without which applications often experience temporary data loss during ISSU. Reconciling RPF interface is often very internal to the switch and dependent on unicast/RIB. Another reconciliation is recreating the mroute entries(in case the router does not sync its mroute database) and rebuilding the oif state. This involves all neighbors in the LAN. This draft talks about faster oif reconciliation. 2. Mechanism in detail After a rebooted PIM router has sent Hello with new GenId, neighbors replay Join-prune message. However, the recovering router does not know for how long it has to wait for all neighbors to complete this replay. This introduces a longer and undeterministic reconciliation time. For example, a (*,G) or (S,G) entry wihtout any immediate oif does not need to wait for any neighbor to send J/P message. Whereas, an intermediate hop router may receive J/P messages splitted across multiple messages from a single neighbor for which it needs to wait for longer duration. For this, a new option, GR_Capability, is included in PIM hello message. A GR capable PIM router can optionally sync its neighbor database. After a failover, router starts PIM GR RUNNING timer per GR capable neighbor. After this, Hello with new GenId is sent out. In case, the rebooting router does not opt to sync its neighbor database then after receiving Hello with GR capable option from neighbors, it can start the timer. When a GR capable PIM router receives PIM Hello with new GenId from another GR capable PIM router, it as usually replays PIM J/P message and follows it with a PIM GR COMPLETE message. The rebooting router cancels the PIM GR RUNNING timer after receiving PIM GR COMPLETE message from the neighbor. In case of GR COMPLETE message getting lost in transit, GR RUNNING timer expires. After this, applications can take measure accordingly. 3. PIM GR COMPLETE message format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For this message, Type will be a new type called PIM_GR_COMPLETE with Value 9. 4. PIM GR RUNNING timer details This is a per neighbor timer. Timer value is 10 sec. 5. References [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. Authors' Addresses Indranil Bhattacharya Brocade Communication India Email: myselfindranil@gmail.com