IETF Logo Mail Archive

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

"Nitish Gupta (nitisgup)" <nitisgup@cisco.com> Fri, 26 June 2015 04:37 UTC

Return-Path: <nitisgup@cisco.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 A56671B32BA; Thu, 25 Jun 2015 21:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 TXzB7GOmd7Qq; Thu, 25 Jun 2015 21:37:10 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DC21AD0AF; Thu, 25 Jun 2015 21:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2680; q=dns/txt; s=iport; t=1435293431; x=1436503031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ovCbTELZVfeZUSwHPycLZ2L9wvmRPawZauQFT2VukQE=; b=gazgOe9ay/a6CusI38xyK8JyA9Q2VaEU0B14YphiRR6p3VZl9xNKGdIe qSwn7iZpc8/gPRfhv1JIXOgAIS7kLZHpTKVPbSNl6xnQaww9o+wPrA/Oz 486hCGsBshHvzKF5qevTQcTQvnZQmPg3F9oT9YVvKtmSpSwTvldm9Xrlz E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BoBACP1YxV/4oNJK1bgxFUXwa9DgmBZoJEgzQCgTw4FAEBAQEBAQGBCoQjAQEEOj0CEAIBCA4KHhAyJQIEAQ0FiC8NzkkBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIpIgQKEGjkzB4QrAQSUBgGEV4Z6gTqTI4NcJoN6bwGBRYECAQEB
X-IronPort-AV: E=Sophos;i="5.13,682,1427760000"; d="scan'208";a="162961285"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP; 26 Jun 2015 04:37:10 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t5Q4b96g011052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jun 2015 04:37:09 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.62]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 23:37:08 -0500
From: "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "maik.pfeil@gmail.com" <maik.pfeil@gmail.com>
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-00.txt
Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-00.txt
Thread-Index: AQHQqaJ11FfksUpD2Ey75lsakVRjlJ25JuyAgAXJXIA=
Date: Fri, 26 Jun 2015 04:37:08 +0000
Message-ID: <D1B2D3BB.52219%nitisgup@cisco.com>
References: <D1A87D0B.516C6%nitisgup@cisco.com> <20150622174511.GB30137@pfrc.org>
In-Reply-To: <20150622174511.GB30137@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [10.65.66.1]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B486F05ADEF9584588310F39C0EF993E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/Wbj-GFsYcszuuJeTYL3XgR0oUZ8>
Cc: "colin@doch.org.uk" <colin@doch.org.uk>, "Aditya Dogra (addogra)" <addogra@cisco.com>
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 26 Jun 2015 04:37:11 -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 rtg-bfd@ietf.org as per your request.
We are looking forward to hearing from you.

Thanks,
Nitish

On 22/06/15 11:15 pm, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

>Nitish,
>
>On Thu, Jun 18, 2015 at 08:40:42AM +0000, Nitish Gupta (nitisgup) wrote:
>> 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.
>
>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.
>
>> 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).
>
>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
>> our draft.
>
>I'll look forward to it.  I'd also suggest copying rtg-bfd@ietf.org for
>further comment.
>
>-- Jeff

v2.23.0 | Report a Bug | By Email