IETF Logo Mail Archive

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

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Thu, 21 January 2016 18:56 UTC

Return-Path: <rrahman@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 D6A461A8A6C; Thu, 21 Jan 2016 10:56:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 mZ3n2fYDGJRg; Thu, 21 Jan 2016 10:56:40 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72B41A8A68; Thu, 21 Jan 2016 10:56:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8375; q=dns/txt; s=iport; t=1453402600; x=1454612200; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z6eg6J2pxk5OYdWjI0tJyOf1evLN8ddWGF8XExQq7/M=; b=L2CMVmoJ8GUUiFR1tW6p8RrPh71dCWveaEazgYBLdsdSPIQNQcaSH+ID 6uscltO6pwwZZy8HlKnV5bMAVCgP8pvZivyn2df31zFu3QfFQy/TKJe8I Ut6ATLfDOKQMv3zW9I8KkrSyEEGk7XJPdxMzmJODuwfZj7vojyVwQdX6A c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AHAgAKKaFW/5xdJa1egm5MgT8GiFGyHwENgWKGDwKBPzgUAQEBAQEBAYEKhDQBAQEEdwIQAgEIDgMDAQIoBzIUCQgCBAENBYgbvhsBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhjiEdIQUWYQbBY1hhRGEAwGNVo55jjsBHgEBQoNmaoYnfAEBAQ
X-IronPort-AV: E=Sophos; i="5.22,326,1449532800"; d="scan'208,217"; a="63864337"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2016 18:56:39 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u0LIudxf001716 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2016 18:56:39 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 21 Jan 2016 12:56:38 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Thu, 21 Jan 2016 12:56:38 -0600
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Jeff Haas <jhaas@juniper.net>, "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt
Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt
Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgIOSG4CAAPKPAIAAwjmAgAGG3wCAAKFngIABfbcA
Date: Thu, 21 Jan 2016 18:56:38 +0000
Message-ID: <D2C511E7.1132E6%rrahman@cisco.com>
References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> <D253ACCC.58856%nitisgup@cisco.com> <C555189F-51EC-42D5-92C5-E99EF5938345@gmail.com> <DM2PR05MB623370167984E7B510B3712A9C00@DM2PR05MB623.namprd05.prod.outlook.com> <6B91DFE6-1CC9-4D17-BD19-8D3F1FDBF365@gmail.com> <D2C514DF.5CE46%nitisgup@cisco.com> <AFF69AEE-78DF-4E32-8493-0317E89A163E@juniper.net>
In-Reply-To: <AFF69AEE-78DF-4E32-8493-0317E89A163E@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.9.151119
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.242.102]
Content-Type: multipart/alternative; boundary="_000_D2C511E71132E6rrahmanciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/T1OmJySzgwGO8zEz_xvovkfGXBQ>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "colin@doch.org.uk" <colin@doch.org.uk>, "Aditya Dogra (addogra)" <addogra@cisco.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
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: Thu, 21 Jan 2016 18:56:44 -0000

<Speaking as individual contributor>

BFD YANG spec doesn't currently support multipoint, what I recall is that the DT had agreed to wait for the multipoint draft to become RFC.

I assume the YANG model in draft-liu-rtgwg-yang-vrrp would need to be modified/augmented to support this capability?

Regards,
Reshad.

From: Rtg-bfd <rtg-bfd-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>> on behalf of Jeff Haas <jhaas@juniper.net<mailto:jhaas@juniper.net>>
Date: Wednesday, January 20, 2016 at 10:10 AM
To: "Nitish Gupta (nitisgup)" <nitisgup@cisco.com<mailto:nitisgup@cisco.com>>
Cc: "Aditya Dogra (addogra)" <addogra@cisco.com<mailto:addogra@cisco.com>>, "colin@doch.org.uk<mailto:colin@doch.org.uk>" <colin@doch.org.uk<mailto:colin@doch.org.uk>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, "rtgwg@ietf.org<mailto:rtgwg@ietf.org>" <rtgwg@ietf.org<mailto:rtgwg@ietf.org>>
Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt


On Jan 20, 2016, at 12:32 AM, Nitish Gupta (nitisgup) <nitisgup@cisco.com<mailto:nitisgup@cisco.com>> wrote:

The other thing I want to make sure if there is any particular configuration requirement from a BFD YANG model perspective. I understand that you are using the fast timer in BFD to detect next-hop IP address liveliness check. We address that configuration in the BFD YANG model today. However, we have not addressed the issue of p2mp BFD configuration as yet. Depending on how that discussion proceeds we might want to look at that also.

[nitish] There is no particular requirement that we can see from BFD YANG model perspective. As VRRP should interface with BFD as another protocol using BFD as a means of fast failure detection of its peer.

The desired behavior we're looking for in yang is ideally making use of the groupings exported by the BFD yang module.  This permits a simple maintainable place to put BFD session parameters.

There are two issues Mahesh is alluding to:
1. Multipoint is currently not in the BFD yang spec.  Thus, the BFD yang team has homework to provide support for that option to allow modules such as a vrrp module supporting this feature to import it.
2. VRRP would only utilize this in *some* circumstances; namely the master/backup scenario rather than each backup.  Configuration state would likely be consistent, but ti does make the operational state a bit trickier.  The session is provisioned, but may not be started - and it may not even be *instantiated* depending on the implementation and whether the priority of the VRRP router is lower than the first available backup.

-- Jeff

v2.23.0 | Report a Bug | By Email