Internet DRAFT - draft-bhattacharya-pim-fast-recovery

draft-bhattacharya-pim-fast-recovery



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