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

From: "Nitish Gupta (nitisgup)" <[email-masked]>
Date: Thu, 18 Jun 2015 08:40:42 +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
availability.
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
configuration.
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
draft.
We will incorporate your points about multipoint BFD in next version of
our draft.

Thanks,
Nitish

On 16/06/15 7:48 am, "Jeffrey Haas" <[email-masked]> wrote:

>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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Jun 2015 13:45:11 -0400

Nitish,

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

> Once learnt the peers can form the BFD session automatically (point to

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

I'll look forward to it.  I'd also suggest copying [email-masked] for
further comment.

-- Jeff

---

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