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

Colin Docherty <colin@doch.org.uk> Tue, 16 January 2018 09:32 UTC

Return-Path: <colin.doch.org.uk@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 1868F12FB2C; Tue, 16 Jan 2018 01:32:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 g30cohXIdxNx; Tue, 16 Jan 2018 01:32:27 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 1547E12FB25; Tue, 16 Jan 2018 01:32:22 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id b141so6963652wme.1; Tue, 16 Jan 2018 01:32:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:reply-to:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=r3AMRGiUyR7a8arS6u7AyMs0panZF0xB35WPuzr8zuU=; b=h6YiZDueEE11qD741GNu4URRYQf80eOThpmJuC+N9nmg2bk3kMoUbaemC8ZlmEJOAE xWOsYimVOD31K9epBfkpD7AEPT622CRPRULxPuuKCeEqZfmyyqUjMIHyiJALMY8IscPE mt6b6WAxRhLzwgmC5Jby11ZCduQZvmRG/drHR90xZLud78qv634DDImlfJwGNoLy5Pq0 K6xrXTABiQfiJ/ESlybGb2iAmu92KqW2R8UVjtIqofHs5bLH8V0k/3lF3G0Oyu3hxy4I YcY1BV19X+RXGSs8gKP0eRoNxq9BURYcDRY6279WwepB0v20CV4Spxgg+v3Id7wwoF7S iD7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to; bh=r3AMRGiUyR7a8arS6u7AyMs0panZF0xB35WPuzr8zuU=; b=XnayZBx9A9pYIxmhaF396rfHbJNIPjxpFj93pddvA5dkYcwpQw//h25p/IaawtNnAc RBJWlJfDCq9l5MYGxMhJxI7KJFQCMywpCol9LOvbigycISNNUk7NSkU2yxbBcPFpgI+X 8VF099sTDhVUvReNPEv13TCO2HZy7JZpXMgwrnLRUvyeiApehoKQ1MfxyZiIjotqN5oG ejijYDBMKH6VwRuDBYGVbjADtmgae5QGSzTOEGRTOH1yELk+oye0SNhhTdPudRCbzo8s vUsT9Co3vVhRiHdA4syP+I2BeNFy4zAWWMfbXpdsD3/mMd4aA1HfnfuzMIVNB91fWQeZ g7bw==
X-Gm-Message-State: AKGB3mIOXXe0VUMh64+ySv89LnRHmkHYPK3YOEcGCTrNTZGKWv8wo0oo ojeAacNi0hc1cIbxDi4Epx3sGkru
X-Google-Smtp-Source: ACJfBovjMc/1wQLBMKvYQ0YllNW/uBfDSqToFw+zliAblOAXALZHKycc1UibWm+zxgWzWrxOAO5B7A==
X-Received: by 10.80.178.133 with SMTP id p5mr54686091edd.149.1516095140241; Tue, 16 Jan 2018 01:32:20 -0800 (PST)
Received: from [172.24.1.123] (82-69-35-28.dsl.in-addr.zen.co.uk. [82.69.35.28]) by smtp.gmail.com with ESMTPSA id z2sm1325459edc.50.2018.01.16.01.32.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jan 2018 01:32:19 -0800 (PST)
Sender: Colin Docherty <colin.doch.org.uk@gmail.com>
Reply-To: colin@doch.org.uk
Subject: Re: WG adoption poll for draft-nitish-vrrp-bfd-p2p
To: Alexander Vainshtein <sasha@axerra.com>, "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>
Cc: "chrisbowers.ietf@gmail.com" <chrisbowers.ietf@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "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>
References: <CAHzoHbvEUAqRL-dBxMQ2KxcVVMkJCpxPQ1bA84U0KT2YiW9mNw@mail.gmail.com> <AM4PR03MB1713EAEFE31431C1B4BA45EF9D160@AM4PR03MB1713.eurprd03.prod.outlook.com> <4B4949C5-91F8-4D85-A078-554216EAF24D@cisco.com> <1664030238.1629235.1516092897556@mail.yahoo.com>
From: Colin Docherty <colin@doch.org.uk>
Message-ID: <a9d7d660-8aa4-5341-8401-719f89f57aef@doch.org.uk>
Date: Tue, 16 Jan 2018 09:32:09 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <1664030238.1629235.1516092897556@mail.yahoo.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="mksQp0aS8GuGJs2HbOeH7QmdDPTfVBAfk"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/7rcFkVEtzt5KZYctD9wCEdbzAXs>
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: Tue, 16 Jan 2018 09:32:30 -0000

Hi Alexander/Group,

Some replies,

On 16/01/18 08:54, Alexander Vainshtein wrote:
> Nitish and all,
> Lots of thanks for a prompt and detailed response.
>
> Based on your response I think that some changes to the draft should
> be made prior to its adoption by the WG. Some other changes can be
> safely handled once the draft becomes a WG document. The details can
> be found in */my comments to your responses/*.
>
> I would also like to discuss one more issue that I did not mention in
> my original set of comments. 
> The last statement in Section 5 says:
> <quote>
>    This Draft does not preclude the possibility of the peer table being
>    populated by means of manual configuration, instead of using the
>    BACKUP ADVERTISEMENT as defined by the Draft.
> <end quote>
>
> I wonder if this statement is sufficient of and by itself for the
> implementers of such an option.
>
> If the peer table is populated by  manual configuration, and if, say,
> object tracking is used to modify priorities of different members of
> the VRRP group, priority-based selection of the CRITICAL PATH member
> becomes more or less meaningless (because priorities become dynamic).
> As a consequence, all BACKUP members of the group would have to
> monitor their BFD sessions with teh Master and would treat failure of
> these sessions as the Master Down event. Once this happens, they would
> all sent VRRP Advertisement messages and resolve the mastership in teh
> usual VRRP way. I do not see any serious issues with this approach but
> it is different from the approach defined in the draft. I wonder if
> clarification of this behavior should not be added to the draft. In
> any case, this is not a stopper for adopting the draft as a WG document.

If we leave the statement as is then it is open to further expansion in
the future, however I think it would be good to just to focus on the
core functionality, and I don't think its a stopper at this stage.

>
> Hopefully my comments will help.
>
> Here begin my comments to your responses:
> -----
>  
> 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.
> */[Sasha] Taking into account that VRRPv2 is much more widely used
> with IPv4 than VRRPv3, I think that at least a declaration of
> intention to include also VRRPv2 should be done before the draft is
> adopted. 
> /*

I strongly disagree with this. Around 2013 when I was developing the
initial BFD/VRRPv3 design, VRRPv2 was been actively deprecated with our
team for our new VRRPv3 implementation. VRRPv2 at that point had already
been deprecated since 2010. I really think it is time to move forward,
there is nothing in the VRRPv2 specification that isn't improved on in
VRRPv3. If anything this draft should serve as an incentive for
widespread adoption of VRRPv3 over its deprecated predecessor. Most
implementations have relatively straightforward upgrade paths for the
VRRPv2->VRRPv3 transition.

> 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.
> */[Sasha] OK with me, can be done after adoption. /*

Agreed.

> 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.
> */[Sasha] From my POV this should be explicitly stated in teh draft
> before adoption.  /*
I don't think this needs to be explicitly stated before adoption.

> 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.
> */[Sasha] My point was that, with preemption mode enabled, some of the
> BACKUP members could have higher priority of the current Master.
> Clarifying that this does not affect determination of the CRITICAL BFD
> session would be useful  - could be done after teh draft is adopted.  /*
> 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. */[Sasha] OK - could be done after adoption
> /*

Agreed.

> 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. */[Sasha] Sams
> as above for me too/**:) happy

Agreed.
>

Regards,
Colin.