FW: WG adoption poll for draft-nitish-vrrp-bfd-p2p

"Nitish Gupta (nitisgup)" <nitisgup@cisco.com> Mon, 15 January 2018 06:29 UTC

Return-Path: <nitisgup@cisco.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C92A1252BA; Sun, 14 Jan 2018 22:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 FG42uDwC98S0; Sun, 14 Jan 2018 22:29:05 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285A1124B18; Sun, 14 Jan 2018 22:29:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26142; q=dns/txt; s=iport; t=1515997745; x=1517207345; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qJUTuphVaM0wnU0Pq43z2TMKN1WPqwb6F8nViGeInlo=; b=Wv7EPAHHpejcS+XFfQWT+pnRdXWK0VNacTUcHB5vFnq0mkTXeSimTaHm iuFhBZAt1HLp1Xg+oWHJ/w3CCPORRrImh0yGpF0A2tcz4qLbMvtUO0CCC B/jw/T3/dNVBz/xB1KSSGX9FrEtib9bX9xP8BRrNw148gFZuUUzgiwYjG 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DwAADDSFxa/4sNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYJKd2Z0JweEDIokjl2CAoJnhh+OJhSCAgojhRgCGoQnPxgBAQEBAQEBAQFrKIUjAQEBBCMKTAwCAgIBCBEDAQEBKAMCAgIUCxETAQcBAQUDAgQBDQWJT0wDFRCtKYInJocODYJwAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFhDeCFYFXgWkpgwWCa0QCAgEBgSkRARIBJgcJCRYCgl8xgjQFiGQMmjc9AogKgSCHHQaEfIIZhh2LWo0+QIh6AhEZAYE7AR85YHBvFWcBgX+EV3iJZYElgRcBAQE
X-IronPort-AV: E=Sophos;i="5.46,362,1511827200"; d="scan'208,217";a="343422632"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2018 06:29:03 +0000
Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w0F6T2dP023806 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Jan 2018 06:29:03 GMT
Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 15 Jan 2018 01:29:02 -0500
Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1320.000; Mon, 15 Jan 2018 01:29:02 -0500
From: "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>
To: "Aditya Dogra (addogra)" <addogra@cisco.com>, "Alexander.Vainshtein@ecitele.com" <Alexander.Vainshtein@ecitele.com>, "draft-nitish-vrrp-bfd-p2p@ietf.org" <draft-nitish-vrrp-bfd-p2p@ietf.org>
CC: "chrisbowers.ietf@gmail.com" <chrisbowers.ietf@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "vinesasha@yahoo.com" <vinesasha@yahoo.com>
Subject: FW: WG adoption poll for draft-nitish-vrrp-bfd-p2p
Thread-Topic: WG adoption poll for draft-nitish-vrrp-bfd-p2p
Thread-Index: AQHTillGRgYOMWhx50ijX00CC9/ouaNvOn4AgAUSz4A=
Date: Mon, 15 Jan 2018 06:29:01 +0000
Message-ID: <4B4949C5-91F8-4D85-A078-554216EAF24D@cisco.com>
References: <CAHzoHbvEUAqRL-dBxMQ2KxcVVMkJCpxPQ1bA84U0KT2YiW9mNw@mail.gmail.com> <AM4PR03MB1713EAEFE31431C1B4BA45EF9D160@AM4PR03MB1713.eurprd03.prod.outlook.com>
In-Reply-To: <AM4PR03MB1713EAEFE31431C1B4BA45EF9D160@AM4PR03MB1713.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.19.241]
Content-Type: multipart/alternative; boundary="_000_4B4949C591F84D85A078554216EAF24Dciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/XJL05iDKl3Kvk3AnX1qIWNSI9k0>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 15 Jan 2018 06:29:08 -0000

Hi Sasha,

We would like to Thank you for your questions and its good to see interest in the Draft. Will be Happy to answer the questions.
Please find our responses inline.

Thanks,
Nitish

From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Date: Thursday, January 11, 2018 at 9:00 AM
To: "draft-nitish-vrrp-bfd-p2p@ietf.org" <draft-nitish-vrrp-bfd-p2p@ietf.org>
Cc: Chris Bowers <chrisbowers.ietf@gmail.com>, RTGWG <rtgwg@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "vinesasha@yahoo.com" <vinesasha@yahoo.com>
Subject: RE: WG adoption poll for draft-nitish-vrrp-bfd-p2p
Resent-From: <alias-bounces@ietf.org>
Resent-To: <nitisgup@cisco.com>, <addogra@cisco.com>, <ietf@doch.org.uk>, <gregimirsky@gmail.com>, <jefftant.ietf@gmail.com>
Resent-Date: Thursday, January 11, 2018 at 9:00 AM


Hi all,

I have several questions regarding the draft that I would like to clarify before providing any firm opinion regarding its adoption.



1.       The draft seems to deal just with VRRPv3 (RFC 5798) while completely ignoring VRRPv2 (RFC 3768). I wonder if this omission is due to some technical issue; if not, do the authors plan to extend the draft to cover also VRRPv2 in future? (The context for this question is that, AFAIK, VRRPv2 is more widely deployed for IPv4)

[nitisgup] Since VRRPv3 covers First Hop redundancy for both ipv4 and ipv6, We have taken VRRPv3 as the base for this RFC and the same can be extended to VRRPv2. We can cover that in future version of the draft.

2.       Neither RFC 3768 nor RFC 5798 do not mention a “Master Down event”; rather they speak about “expiration of the Master_Down_Timer”. However, the draft uses the term “Master Down event” several times. Can I safely assume that it is the same as “expiration of the Master_Down_Timer”?

[nitisgup] We have already covered in the Draft, that Master down event is triggered by either “expiration of the Master_Down_Timer” or “Critical_BFD_Session going down”. But We will also define it in the section 3.6 of the Draft.

3.       While neither RFC 3768 nor RFC 5798 mention it, most VRRP implementations support tracking mechanisms that result in dynamic change of priorities of VRRP group members. The draft does not discuss what happens when priority of one of the group members changes. E.g.:

a.       Do the backup member that experiences such a change immediately send a new Backup Advertisement?

                        [nitisgup] When the VRRP Router Enters the Backup State it will send a BACKUP ADVERTISEMENT.

b.       Is the “Critical Path” re-estimated each time this happens etc.

[nitisgup] Ciritical Path is determined every time an Advert(MASTER/BACKUP) is received from the PEER, as it will be updated in the PEER table.

4.       Both VRRPv2 and VRRPv3 support no-preemption mode. Please explain what happens if this mode is set in a VRRP group member whose priority becomes (due to dynamic changes) higher than that of the current Master?

[nitisgup] We have not changed the Behavior of VRRPv3 with this Draft the, We have already captured the updated State machine in section 3.6.3, which takes care of Preempt_Mode of the VRRP router.

5.       Suppose that the draft is used with VRRPv3 for IPv6. Is the Source IPv6 address of the Backup Advertisement packet a link-local address of the interface via which this message is transmitted? (This is explicitly specified in RFC 5798 for the VRRP Advertisement message, but not specified in the draft)

[nitisgup] We can take care of this in next version of the Draft.

6.       In the scenario above, will the 1-hop IPv6 BFD session use link-local IPv6 addresses of the VRRP Master and its primary Backup? (I assume that the answer is positive, but it would be nice to see this in the draft and not to leave it for the implementers to guess).

[nitisgup] Same as above we will explicitly mention it.

Your timely feedback would be highly appreciated.



Regards, and lots of thanks in advance,

Sasha



Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com



-----Original Message-----
From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Chris Bowers
Sent: Wednesday, January 10, 2018 11:23 PM
To: RTGWG <rtgwg@ietf.org>; rtg-bfd@ietf.org
Subject: WG adoption poll for draft-nitish-vrrp-bfd-p2p



RTGWG,



This email starts the two week WG adoption poll for draft-nitish-vrrp-bfd-p2p.



https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd-p2p/



Please indicate whether you support or oppose having RTGWG work on this topic with this draft as the starting point.



This WG adoption poll will end on Thursday, January 25th.



An IPR poll for this draft was conducted last month.



Thanks,

Chris



___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________