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

"Nitish Gupta (nitisgup)" <> Fri, 26 June 2015 04:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A56671B32BA; Thu, 25 Jun 2015 21:37: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 TXzB7GOmd7Qq; Thu, 25 Jun 2015 21:37:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 08DC21AD0AF; Thu, 25 Jun 2015 21:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2680; q=dns/txt; s=iport; t=1435293431; x=1436503031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ovCbTELZVfeZUSwHPycLZ2L9wvmRPawZauQFT2VukQE=; b=gazgOe9ay/a6CusI38xyK8JyA9Q2VaEU0B14YphiRR6p3VZl9xNKGdIe qSwn7iZpc8/gPRfhv1JIXOgAIS7kLZHpTKVPbSNl6xnQaww9o+wPrA/Oz 486hCGsBshHvzKF5qevTQcTQvnZQmPg3F9oT9YVvKtmSpSwTvldm9Xrlz E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,682,1427760000"; d="scan'208";a="162961285"
Received: from ([]) by with ESMTP; 26 Jun 2015 04:37:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t5Q4b96g011052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jun 2015 04:37:09 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 23:37:08 -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: AQHQqaJ11FfksUpD2Ey75lsakVRjlJ25JuyAgAXJXIA=
Date: Fri, 26 Jun 2015 04:37:08 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
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: Fri, 26 Jun 2015 04:37:11 -0000

Hi Jeff/Maik,

Thanks a lot for your comments and suggestions on the draft.
We have incorporated all the below comments and comments given by Maik in
the latest version.


I am also including as per your request.
We are looking forward to hearing from you.


On 22/06/15 11:15 pm, "Jeffrey Haas" <> wrote:

>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
>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
>> 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
>protocols.  This part is fine, whether it is single-hop or multipoint.
>Since BFD is capable of being dynamically boostrapped, it may be also
>pointing out that you can make this scale better by both provisioning
>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
>not even be provisioned immediately.  You could also provision the backup
>use less aggressive timers until it becomes the master, after which you
>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 for
>further comment.
>-- Jeff