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

Maik Pfeil <maik.pfeil@gmail.com> Tue, 16 June 2015 06:50 UTC

Return-Path: <maik.pfeil@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FB31B32AF for <rtgwg@ietfa.amsl.com>; Mon, 15 Jun 2015 23:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1YsIJxOq3sS for <rtgwg@ietfa.amsl.com>; Mon, 15 Jun 2015 23:50:42 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F181B32AA for <rtgwg@ietf.org>; Mon, 15 Jun 2015 23:50:42 -0700 (PDT)
Received: by lbbqq2 with SMTP id qq2so4473449lbb.3 for <rtgwg@ietf.org>; Mon, 15 Jun 2015 23:50:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tibEQwpQq+OVb6zwQ9E6cgFJqUrX+AeV5CtvUcnu/pU=; b=gos8ORcpJ5yB9YJg0BmkrekEnfxP0hNiukYPciD1mPLc5YE0/s1qu72cCJaxf59nwz 4hH7JYf8424ftq8NrPZcMtqcNHTM1Q5fq3Jl3bQi3Qtpx+RAc4N8YFaDEwPU4JQSsQkl IdYXagarZrGTwxRCchfSLZ014LOJ488Tg4QPuZ/VkWKjxx+BEAGf1fZpRyuhY5BFKUXj TBg19emkgvdzu5NZcYquI/eNjA+I42MrAk0Gec5OWv/4VHS+sPyhGHOZv7gesaniGYRC 8sHByzGO1/nGf7/pGiL6EhqaqupPFoDSALjdQDO0KBwY2MBYkXW0pLQ6BfjeUSlDKZaA ag6A==
MIME-Version: 1.0
X-Received: by 10.112.150.130 with SMTP id ui2mr4423310lbb.116.1434437440680; Mon, 15 Jun 2015 23:50:40 -0700 (PDT)
Received: by 10.152.114.38 with HTTP; Mon, 15 Jun 2015 23:50:40 -0700 (PDT)
In-Reply-To: <D1A4D1E2.50F6A%nitisgup@cisco.com>
References: <20150612134728.15333.53928.idtracker@ietfa.amsl.com> <D1A4D1E2.50F6A%nitisgup@cisco.com>
Date: Tue, 16 Jun 2015 08:50:40 +0200
Message-ID: <CAPM=O_u6gyOrQqpBu1nFe3DhzkmH5HAxueaKS2os4PwMYUSMEA@mail.gmail.com>
Subject: Re: FW: New Version Notification for draft-nitish-vrrp-bfd-00.txt
From: Maik Pfeil <maik.pfeil@gmail.com>
To: "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>, "colin@doch.org.uk" <colin@doch.org.uk>, "Aditya Dogra (addogra)" <addogra@cisco.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b3a821a1aba8405189cfe76
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/2neTnYmfdYZY7fl6XTcjHY-SCkQ>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2015 06:50:45 -0000

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>om>:

> 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" <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.
> >
> >The IETF Secretariat
> >
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>