Re: New Version Notification for draft-nitish-vrrp-bfd-00.txt

Jeffrey Haas <jhaas@pfrc.org> Mon, 22 June 2015 17:43 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48541ACE13 for <rtgwg@ietfa.amsl.com>; Mon, 22 Jun 2015 10:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.122
X-Spam-Level: *
X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WawAPETABugM for <rtgwg@ietfa.amsl.com>; Mon, 22 Jun 2015 10:43:54 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DEDD91ACD6D for <rtgwg@ietf.org>; Mon, 22 Jun 2015 10:43:54 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id D7B751E3A6; Mon, 22 Jun 2015 13:45:11 -0400 (EDT)
Date: Mon, 22 Jun 2015 13:45:11 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-00.txt
Message-ID: <20150622174511.GB30137@pfrc.org>
References: <D1A87D0B.516C6%nitisgup@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D1A87D0B.516C6%nitisgup@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/hCcyZG0WqUCghIQaEp1nMQYhWF8>
Cc: "colin@doch.org.uk" <colin@doch.org.uk>, "Aditya Dogra \(addogra\)" <addogra@cisco.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jun 2015 17:43:55 -0000

Nitish,

On Thu, Jun 18, 2015 at 08:40:42AM +0000, Nitish Gupta (nitisgup) wrote:
> Since VRRP might run in the control-plane like other routing protocols.
> It would be required that a faster failure mechanism (than its Protocol
> Hello messages) be used, and BFD serves the purpose very well.

Depending on a router's implementation, BFD may also run in the control
plane.  While not trying to be pedantic, I'd suggest that you need to
include in your use case that BFD in this proposal should NOT be implemented
in the control plane.  If both BFD and VRRP are implemented in software,
VRRP in a standalone fashion is likely more appropriate.

> To automate this operation, this draft proposes a mechanism where the VRRP
> devices can learn about its peers.
> Once learnt the peers can form the BFD session automatically (point to
> point or Multipoint).

It is a great tradition that BFD sessions can be bootstrapped through other
protocols.  This part is fine, whether it is single-hop or multipoint.

Since BFD is capable of being dynamically boostrapped, it may be also worth
pointing out that you can make this scale better by both provisioning fewer
BFD sessions and also being less aggressive about your timers.

For example, you could only bring up BFD sessions for the master and the
first likely backup for a given virtual router.  The additional backups need
not even be provisioned immediately.  You could also provision the backup to
use less aggressive timers until it becomes the master, after which you may
have BFD adjust its interval to the more aggressive timestamp.  Both of
these changes accommodates the common scaling considerations of BFD:
aggressiveness of the timers, and total number of sessions.

> We will incorporate your points about multipoint BFD in next version of
> our draft.

I'll look forward to it.  I'd also suggest copying rtg-bfd@ietf.org for
further comment.

-- Jeff