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

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.

Thanks,
Nitish

From: Maik Pfeil <maik.pfeil@gmail.com<mailto:maik.pfeil@gmail.com>>
Date: Tuesday, 16 June 2015 12:20 pm
To: Nitish Gupta <nitisgup@cisco.com<mailto:nitisgup@cisco.com>>, "colin@doch.org.uk<mailto:colin@doch.org.uk>" <colin@doch.org.uk<mailto:colin@doch.org.uk>>, "Aditya Dogra (addogra)" <addogra@cisco.com<mailto:addogra@cisco.com>>, "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>
Subject: Re: FW: New Version Notification for draft-nitish-vrrp-bfd-00.txt

Authors,

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) <nitisgup@cisco.com<mailto:nitisgup@cisco.com>>:
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.

Thanks,
Nitish

On 12/06/15 7:17 pm, "internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>" <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
wrote:

>
>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
>URL:
>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-00.txt
>Status:         https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/
>Htmlized:       https://tools.ietf.org/html/draft-nitish-vrrp-bfd-00
>
>
>Abstract:
>   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
>submission
>until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
>The IETF Secretariat
>

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg