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

From: "Nitish Gupta (nitisgup)" <[email-masked]>
Date: Mon, 15 Jun 2015 13:37:04 +0000

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, "[email-masked]" <[email-masked]>
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.
>
>The IETF Secretariat
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Jun 2015 22:18:47 -0400

Nitish,

> 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: Maik Pfeil <[email-masked]>
Date: Tue, 16 Jun 2015 08:50:40 +0200

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) <[email-masked]>:

> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>