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

From: "Nitish Gupta (nitisgup)" <[email-masked]>
Date: Fri, 26 Jun 2015 04:37:08 +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.

URL:https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-01.txt
Status:         https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/
Htmlized:       https://tools.ietf.org/html/draft-nitish-vrrp-bfd-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-nitish-vrrp-bfd-01

I am also including [email-masked] as per your request.
We are looking forward to hearing from you.

Thanks,
Nitish

On 22/06/15 11:15 pm, "Jeffrey Haas" <[email-masked]> wrote:

>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 [email-masked] for
>further comment.
>
>-- Jeff