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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F1881B308B for <>; Thu, 18 Jun 2015 01:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 wp5fFi-7nEi0 for <>; Thu, 18 Jun 2015 01:56:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 643571A2130 for <>; Thu, 18 Jun 2015 01:56:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14812; q=dns/txt; s=iport; t=1434617790; x=1435827390; h=from:to:subject:date:message-id:mime-version; bh=oNnl/zfHa06Wxrd8ncEdVZuYmR2RUyx9V49Gp0KqZQM=; b=de5TbL4wJ3aR16JZyZ5QaeEQmFBaeXYEu2mP3qLOprwFLQXnqR7gDVuN 6OUF2TmJCcxDC08hgGUJ3tqPxq6dFe6oaYlFNH6EhqjHZPZ+RFAFnyNBR uPnOgeGVsNeEtt7yEeaFKxbyuIrjteH0o+4Ugd5fvI4XRpjFNOL5sRDgY Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,638,1427760000"; d="scan'208,217";a="2629466"
Received: from ([]) by with ESMTP; 18 Jun 2015 08:56:29 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t5I8uTT7027680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jun 2015 08:56:29 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 18 Jun 2015 03:56:29 -0500
From: "Nitish Gupta (nitisgup)" <>
To: Maik Pfeil <>, "" <>, "Aditya Dogra (addogra)" <>, "" <>
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: AQHQqaSpV8Ns/qjFVUi8wI3eWuh93w==
Date: Thu, 18 Jun 2015 08:56:28 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D1A88234516E0nitisgupciscocom_"
MIME-Version: 1.0
Archived-At: <>
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:56:33 -0000

Hi Maik,

Thanks for your comments, they are very useful.

Yes configuring the Peers statically could be a possible solution. But can quickly become tedious if there are large number of devices in part of the VRRP instance.
The motivation of this draft is to automate this operation. But the implementation should allow for both the modes to co-exists.
You are right that the Backups can send the Advert messages at slower pace than VRRP Master.

We will incorporate these into the next version of the draft.

There may be some more thought around removing the peer from the peer table when BFD DOWN notification is received for a peer.
What if there is a flap and the peer comes back up fast. This would lead to creation/deletion/creation of the BFD session.
So as you pointed out there can be a wait, possibly a timeout before the peer is removed from the table and BFD session torn down.

The VRRP instance is already aware of which peer is the master and rest including itself is a backup.
So this may be redundant info in the peer table.

Looking forward to hear from you.


From: Maik Pfeil <<>>
Date: Tuesday, 16 June 2015 12:20 pm
To: Nitish Gupta <<>>, "<>" <<>>, "Aditya Dogra (addogra)" <<>>, "<>" <<>>
Subject: Re: FW: New Version Notification for draft-nitish-vrrp-bfd-00.txt


The draft propose a automatic detection of VRRP Backup peers. Which is not needed in every case. Backup Peers are well known and peer addresses often follow operational/planning rules, eg. 1. IP of subnet VIP, 2. Master, 3. Backup and maybe more. It should be described that a static configured peer table could be a viable option to not increase overall overhead.

3) BACKUP ADVERTISEMENTs should not need to be send at same periodic rate as the Master Advert packets. Master Advert packets could use a more aggressive rate.

4) Peer table forming should be more precise, eg:
   a) Learning peer by BACKUP ADVERTISEMENT (or static) should add a peer.
   b) Removing from peer table by timeout ?
     a. What if BFD session already up?
   c) If a BFD session goes from UP to DOWN, the Peer Address should be immediatley deleted from Peer Table

5) If you say Critical BFD Session you mean the top of an ordered peer table descending sorted by priority. Peer table is not aware of the state, only priority.

// Maik

2015-06-15 15:37 GMT+02:00 Nitish Gupta (nitisgup) <<>>:
Hi All,

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.


On 12/06/15 7:17 pm, "<>" <<>>

>A new version of I-D, draft-nitish-vrrp-bfd-00.txt
>has been successfully submitted by Nitish Gupta and posted to the
>IETF repository.
>Name:          draft-nitish-vrrp-bfd
>Revision:      00
>Title:         Fast failure detection using peer learning in VRRP with BFD
>Document date: 2015-06-12
>Group:         Individual Submission
>Pages:         16
>   This draft presents an enhanced failure detection mechanism to detect
>   the failure of VRRP Master router on the LAN using a peer learning
>   mode.  Typically the VRRP protocol is able to perform the transparent
>   fail-over detection within a time period of 3 seconds with default
>   fail-over timers.  Real-time protocols (voice/video/real-time
>   transactional) require a maximum network disruption in the order of
>   150ms for traffic on the network.  A failure detection and fail-over
>   time of 150ms on conventionally configured VRRP protocol is extremely
>   aggressive and may impact the reliability and performance of the
>   network.
>   A more efficient mechanism for real-time failure detection can be
>   enabled in VRRP protocol by building a peer table, using a new VRRP
>   Advert packet type.  This will help in forming a mesh of BFD
>   sessions.  Once the BFD sessions are created, VRRP can receive faster
>   notification of failures, without the overhead of increased VRRP
>   protocol Advert messages.
>Please note that it may take a couple of minutes from the time of
>until the htmlized version and diff are available at<>.
>The IETF Secretariat

rtgwg mailing list<>