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

"Nitish Gupta (nitisgup)" <> Thu, 18 June 2015 08:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DE441B3074 for <>; Thu, 18 Jun 2015 01:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U-wOt4R0lK_s for <>; Thu, 18 Jun 2015 01:41:09 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7715C1B3073 for <>; Thu, 18 Jun 2015 01:41:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4238; q=dns/txt; s=iport; t=1434616869; x=1435826469; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=t9ETxG0uJcO0JfZi345wa2ohrc6MsX7goX1ubu0oN6U=; b=GY3YJocyq4mqMBHx6vsfUTe4XW7iL20WQ+H81gVgPOkPFd4U2QkiyZob xTMdz3G2cofiVgrU1lWkR7FBlBYYKttFFTnIAkFqZGSrnujHGh/LCGEhV kq6+/az4zb032ieHpZL8sV7Fz4HugdeSwTF75PsnpTq0cBWY5RLkQBbmO A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,638,1427760000"; d="scan'208";a="160585176"
Received: from ([]) by with ESMTP; 18 Jun 2015 08:40:43 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t5I8ehBt016135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jun 2015 08:40:43 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 18 Jun 2015 03:40:42 -0500
From: "Nitish Gupta (nitisgup)" <>
To: Jeffrey Haas <>
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-00.txt
Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-00.txt
Thread-Index: AQHQqaJ11FfksUpD2Ey75lsakVRjlA==
Date: Thu, 18 Jun 2015 08:40:42 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "Aditya Dogra \(addogra\)" <>, "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jun 2015 08:41:11 -0000

Hi Jeff,

Thanks for your comments on the draft.

Yes you are correct, the assumption is VRRP may be implemented in
control-plane along with other routing protocols.
As VRRP depends on Advert(Hello) messages to detect the master Router
It might not scale well in case there are large number of VRRP instances
on the device and all of them send Advert(Hello) messages at a fast Rate.

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.

The motivation behind this draft is to be able to provide a mechanism
where this integration can be achieved with less manual intervention or
As we have outlined in the Draft, if VRRP interfaces with BFD, each Router
taking part in the VRRP instance needs to know about its peers.

In current VRRP specification its only the Master VRRP router that sends
Advert(Hello) messages.
So the Master is not aware of any backups, also the Backups are not aware
of other backups.

One potential solution could be to configure the Address of VRRP peers on
each peer statically.
But with this approach if there is a new device joining the VRRP instance,
the information about this new peer would have to be made available to
other peers by manual configuration
Which can quickly become tedious if there are more device or more Virtual
router instances participating in the VRRP instance.
Even with  multipoint BFD, this config would still need to be done, to
statically populate the peer table on each peer.

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).

Also if there is another peer joining the network, there will be no manual
intervention required.
The peer will announce itself when joining the network, as well as learn
about its peers already present in the network.

As rightly pointed by you, multipoint bfd  can simplify the design,
instead of point to point connections initiated by VRRP.

But as we have outlined with Multi-point BFD as well, VRRP needs a
mechanism to learn its peer nodes. Which is what we are purposing in this
We will incorporate your points about multipoint BFD in next version of
our draft.


On 16/06/15 7:48 am, "Jeffrey Haas" <> wrote:

>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
>> 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
>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
>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
>The BFD sessions in your proposal are unicast.  While protecting the
>addresses of the VRRP interfaces might be a useful feature, having the
>not shared between the two detection mechanisms seems potentially
>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
>the receiver can't handle the BFD-speed multicast load.
>In general, I question some of the motivation of this work but believe
>if the use case is appropriate there may be some potential to address the
>technical issues.
>-- Jeff