[RTG-DIR] Rtgdir early review of draft-ietf-rtgwg-vrrp-p2mp-bfd-08

Emmanuel Baccelli via Datatracker <noreply@ietf.org> Tue, 12 March 2024 14:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 014A9C15154F; Tue, 12 Mar 2024 07:46:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Emmanuel Baccelli via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-rtgwg-vrrp-p2mp-bfd.all@ietf.org, rtgwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.7.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171025478699.63593.16128498870865949381@ietfa.amsl.com>
Reply-To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Date: Tue, 12 Mar 2024 07:46:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/czNc5Ryibco0JYl2D0SBsV-zg5Y>
Subject: [RTG-DIR] Rtgdir early review of draft-ietf-rtgwg-vrrp-p2mp-bfd-08
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2024 14:46:27 -0000

Reviewer: Emmanuel Baccelli
Review result: Has Nits


I've been selected as Routing Directorate (early) reviewer for this draft.

I have a few nits (nothing major) and a couple of suggestions.

Some of my comments might come through as pedantic -- mostly due to my
superficial prior knowledge concerning VRRP!

# Abstract:

suggested change/clarification
"...sub-second convergence of the Active router and..."
=> "...sub-second convergence for the process determining the Active router
and..." or something equivalent.

# Section 1:

suggested change/clarification
"this document demonstrates how... can enable faster detection..."
=> "this document specifies fast transition to a new Active router, upon
detection of..." or something equivalent.

# Section 2:

"Supporting sub-second mode... in the data plane may prove challenging"
=> Would be best to hint at the main reason why (costs in terms of control
traffic overhead?).

"BFD already has many implementationq based on HW"
=> Cite at least one implementation, if possible?

# Section 3:

My Discriminator => cite RFC5880 upon first use of this term in the doc ;)

"... starts transmitting BFD control packets with VRID as a source IP address
and ..." => it is unclear how VRID (1 Byte) can be used as IP address. Can you

"... when a backup router detects failure of the Active router, ..."
=> using which mechanism/RFC ? I suggest citing it explicitly

"... it reevaluates its role as VRID."
=> it is unclear how this happens exactly. If this is intentionally left
unspecified as implementation-dependent, I suggest to say it explicitly in the

"... the new Active router MUST select My Discriminator and..."
=> it is unclear which discriminator is meant here. Do you mean the value
locally allocated (as it was still Backup router)?

# Section 5:

"... to accelerate detecting a failure that affects VRRP"
=> it is unclear what in the doc accelerates *detecting* a failure. I suggest a
rephrase such as "...to accelerate transition to a new Active router upon
detection of BFD failure" or something equivalent.