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

Jeffrey Haas <jhaas@pfrc.org> Tue, 16 June 2015 02:17 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 5150C1ACCFF for <rtgwg@ietfa.amsl.com>; Mon, 15 Jun 2015 19:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Level:
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eHqhqaSNwSGi for <rtgwg@ietfa.amsl.com>; Mon, 15 Jun 2015 19:17:45 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D8C171ACD16 for <rtgwg@ietf.org>; Mon, 15 Jun 2015 19:17:41 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 422D71E3A1; Mon, 15 Jun 2015 22:18:47 -0400 (EDT)
Date: Mon, 15 Jun 2015 22:18:47 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>
Subject: Re: FW: New Version Notification for draft-nitish-vrrp-bfd-00.txt
Message-ID: <20150616021847.GR2288@pfrc.org>
References: <20150612134728.15333.53928.idtracker@ietfa.amsl.com> <D1A4D1E2.50F6A%nitisgup@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D1A4D1E2.50F6A%nitisgup@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/F5fhLwYJKEZdYYV1E_ShmChv32E>
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: <http://www.ietf.org/mail-archive/web/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: Tue, 16 Jun 2015 02:17:46 -0000

Nitish,

On Mon, Jun 15, 2015 at 01:37:04PM +0000, Nitish Gupta (nitisgup) wrote:
> We are proposing a peer learning mode in VRRP which will help in seamless
> integration of VRRP with BFD.
> We are looking forward to your comments on the draft.

I have some concerns about this draft.

My biggest concern is that if the system or network is unable to sustain the
appropriate centi-second rate for a single VRRP master, how will it handle
the potentially faster full-mesh BFD sessions presumably at a higher rate?

One possibility might be that you're considering VRRP to be implemented on a
portion of the network element that scales less nicely than BFD does on the
same network element.

A second concern I have is that the control paths being protected are not
necessarily the same.  VRRP is utilizing multicast to disseminate its state.
The BFD sessions in your proposal are unicast.  While protecting the unicast
addresses of the VRRP interfaces might be a useful feature, having the fate
not shared between the two detection mechanisms seems potentially hazardous.

Which brings up a different possibility: Why not utilize BFD multipoint to
protect the service?  This would involve some amount of innovation on that
feature, but might be a better match than unicast BFD sessions.  However,
protecting the same multicast address may run into implementation issues if
the receiver can't handle the BFD-speed multicast load.

In general, I question some of the motivation of this work but believe that
if the use case is appropriate there may be some potential to address the
technical issues.

-- Jeff