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 protected]>:
> 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 protected]" <[email protected]>
> 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
> >
>
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
