Re: draft-nitish-vrrp-bfd

Greg Mirsky <gregimirsky@gmail.com> Thu, 31 August 2017 17:20 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15275132E11; Thu, 31 Aug 2017 10:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 JHL34WlqUNtG; Thu, 31 Aug 2017 10:20:13 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (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 61572132025; Thu, 31 Aug 2017 10:20:13 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id r187so698459pfr.3; Thu, 31 Aug 2017 10:20:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bmUb20nK9/9oN36b0LY7rR/UEt7ZC7+K359DC5/vAc0=; b=nL/XUHkpyGH8qzmIpCo2pQQKK64N6QEKR7EhWynEcnZwUdhj3WPqTYk4BsxXaqlJhY 3dTUFx9+Uct+XXcUVnpNVUuMl6Ui8n13kL24Mjp8Mw3aDxXgZclM+yjJjKovkK9LlGnX PpXJ+682bM+GDZwh52UPjpLSZcuLXjwZwHi3XTgpVL20VJtF420OLwqow+97pC1zB2PL 9hGmu738gxWhJ0ziAePpVXV1jBUwghYEQ543Nr/5I+OS/9yEYw7/KEhzl2XLQB2JwXiQ a5RcnsQHzjjkhtUr6E44JjA1YMX9yf0IIGtDXrWHN0OL6YNpP+bZmxyPnDN+BoKMgk/A 9ZIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bmUb20nK9/9oN36b0LY7rR/UEt7ZC7+K359DC5/vAc0=; b=OFfACJLYDuSmxjMD5SdBii6uHQg2w+N6+CR3EaU3NmSkEXYuSBQ/Zsuvv+lAd5vyDi 3B7+kSpbBw5atgxwh3E55psruvvoUwOwGpkPlEEzXnT0iTUcGAQRvCQ4ZgFV1rY4xFRr xb5aIEyuuIkDJQU1ODfBNB4v4hoFtQBImAIS3Y0q31oAiBbcP+sumwtNpBcfNV15qaDz XkbH/Wu6A+8FRt3M/ZoJREQOmVL8TQfyjpPJEnzj6jfIBIUQ5Ab/FEqPCYl+0jWTsujj cizfO+/kxnvdU0d7aDiKqmEKPSBkSdzuG+bpTIuk1rYpNf+1vbWKGSaO/LsKlfDPIYh7 OXmA==
X-Gm-Message-State: AHYfb5jAbu/S2d2QY3wBVZn/qSUL6raI3jI1xc/oUHnHkvPKFPEUjDtk KsuD5H3iHnibxks7HqstnfD6qPRWsg==
X-Google-Smtp-Source: ADKCNb6+xcaY1LjZi2pWlwWehpFJA1fytLzxEeMXuN9uZjoB62xAkogyhOXyPAO9xRG+fZvuhF30IbfBOqhb3sr3Zsc=
X-Received: by 10.99.4.135 with SMTP id 129mr3306631pge.57.1504200012428; Thu, 31 Aug 2017 10:20:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.182.110 with HTTP; Thu, 31 Aug 2017 10:20:11 -0700 (PDT)
In-Reply-To: <D5CD54E2.C53E2%acee@cisco.com>
References: <CA+RyBmWyxFp447nGSsZvgnKp61LrSxwSoYeJft=Z_dZcSHeUVA@mail.gmail.com> <EE790B27-2DC3-4BEE-9D5A-6B75178C1604@cisco.com> <D5CD54E2.C53E2%acee@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 31 Aug 2017 10:20:11 -0700
Message-ID: <CA+RyBmXM=vkuV_+ZmaGn6UBCKNj7+RxGehxc-J2ZN4=Ww04jrg@mail.gmail.com>
Subject: Re: draft-nitish-vrrp-bfd
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>, "thibault.tabani@altran.com" <thibault.tabani@altran.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "colin@doch.org.uk" <colin@doch.org.uk>, "draft-nitish-vrrp-bfd@ietf.org" <draft-nitish-vrrp-bfd@ietf.org>, "Aditya Dogra (addogra)" <addogra@cisco.com>
Content-Type: multipart/related; boundary="001a114f174e6a292b05580fdbd4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/9-gRKqmme9KCPyb3BoTGAOUXB64>
X-Mailman-Approved-At: Thu, 31 Aug 2017 11:05:24 -0700
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Aug 2017 17:20:20 -0000

Hi Acee,
I'd refer to BFD for Multipoint Networks
<https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/?include_text=1>
that being prepared for publication. I believe that this very nicely
matches VRRP scenario when Backup need to monitor the Master and Master
doesn't have to know about the Backup at all.
Appreciate your consideration and comments.

Regards,
Greg

On Thu, Aug 31, 2017 at 2:55 AM, Acee Lindem (acee) <acee@cisco.com>; wrote:

> Hi Nitish,
>
> Irrespective of any IPR discussions, BFD is inherently a P2P protocol and,
> consequently, I would vote for P2P peer table.
>
> Thanks,
> Acee
>
> From: rtgwg <rtgwg-bounces@ietf.org>; on behalf of "Nitish Gupta
> (nitisgup)" <nitisgup@cisco.com>;
> Date: Thursday, August 31, 2017 at 1:51 AM
> To: "thibault.tabani@altran.com"; <thibault.tabani@altran.com>;, "
> rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;, Routing WG <rtgwg@ietf.org>;
> Cc: "colin@doch.org.uk"; <colin@doch.org.uk>;, "draft-nitish-vrrp-bfd@ietf.
> org" <draft-nitish-vrrp-bfd@ietf.org>;, "Aditya Dogra (addogra)" <
> addogra@cisco.com>;
> Subject: Re: draft-nitish-vrrp-bfd
>
> Hi Thibault,
>
>
>
> Thanks for the interest in the Draft, appreciate it. Please review the
> draft and let us know if you have any comments, suggestions.
>
>
>
> Hi RTGWG/RTGBFD,
>
>
>
> There were two solutions proposed in the draft.
>
> One pertains to making a peer table in VRRP and uses p2p BFD.
>
> The second solution pertains to p2mp BFD.
>
>
>
> While we were working on the draft there was an IPR associated to the
> DRAFT and the WG felt that we need to wait until we can see the IPR and
> what its associated to.
>
> We can see that the IPR is available for us to view and we can see that
> the IPR is associated to p2mp BFD.
>
>
>
> https://www.google.com/patents/US20170005915
>
>
>
> We are going to submit a draft with the p2p BFD so that we can continue
> working on the Draft.
>
> There was lot of interest last time as well, just because of the IPR claim
> we had stopped the work.
>
>
>
> Thanks,
>
> Nitish
>
>
>
> *From: *Greg Mirsky <gregimirsky@gmail.com>;
> *Date: *Tuesday, August 29, 2017 at 11:01 AM
> *To: *TABANI Thibault <thibault.tabani@altran.com>;
> *Cc: *"draft-nitish-vrrp-bfd@ietf.org"; <draft-nitish-vrrp-bfd@ietf.org>;,
> "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>;, "rtg-bfd@ietf.org"; <
> rtg-bfd@ietf.org>;, "rtgwg@ietf.org"; <rtgwg@ietf.org>;
> *Subject: *Re: draft-nitish-vrrp-bfd
> *Resent-From: *<alias-bounces@ietf.org>;
> *Resent-To: *<nitisgup@cisco.com>;, <addogra@cisco.com>;, <colin@doch.org.uk>;,
> <gregimirsky@gmail.com>;, <jefftant.ietf@gmail.com>;
> *Resent-Date: *Tuesday, August 29, 2017 at 11:01 AM
>
>
>
> Hi Thibault,
>
> thank you for your interest in the draft, much appreciated. Please don't
> be discouraged that it lapsed, we can fix it easily. I think that authors
> had similar to your idea when we've started thinking about BFD supporting
> VRRP. And like you we haven't found any reference in existing documents,
> hence this draft draft-nitish-vrrp-bfd. Would be much obliged if you review
> and share your comments, suggestion regarding solutions proposed in the
> draft.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Aug 29, 2017 at 9:20 AM, TABANI Thibault <
> thibault.tabani@altran.com>; wrote:
>
> Hello,
>
>
>
> I am working at improving VRRP convergence time. (target a few 100’s of
> milliseconds)
>
>
>
> It appears that VRRP supports BFD health monitoring which might be a
> better option than tuning VRRP aggressive timers.
>
>
>
> Unfortunately I cannot find any active RFC where VRRP supports BFD. The
> only document I found is your draft document:
>
>
>
> Fast failure detection in VRRP with BFD
> draft-nitish-vrrp-bfd-04
>
>
>
> Unfortunately date expires of this document.  As BFD support for VRRP is
> implemented on most routers, I suppose that an active RFC might exist on
> that specific BFD implementation within VRRP. (new backup advertisement
> messages….peer table….)
>
> br
>
>
>
>
>
> *Thibault TABANI *
> architect Altran Connected Solutions
> Altran France
>
>
> *[image: id:image001.png@01CF8AFD.950B79F0]*
>
>
>
> 1, Impasse Charles Trenet
>
> 44800 Saint-Herblain
> France
>
> Tel. : +33 2 40 67 62 62 <+33%202%2040%2067%2062%2062>
> Mob. : +33 6 79 06 33 63 <+33%206%2079%2006%2033%2063>
> *thibault.tabani@altran.com <thibault.tabani@altran.com>*
> *www.altran.fr <http://www.altran.fr/>*
>
>
>
> [image: escription : Description : cid:image002.png@01CD89E1.42D19210]
> <http://facebook.com/AltranFrance>[image: escription : Description :
> cid:image003.png@01CD89E1.42D19210] <http://twitter.com/AltranFrance>[image:
> escription : Description : LinkedIn_signatureMail]
> <http://linkedin.com/company/altran-france>[image: escription :
> Description : pictog_viadeo] <http://www.viadeo.com/fr/company/altran>
>
>
>
>
>
>