[bess] Rtgdir early review of draft-ietf-bess-evpn-bfd-07

Mohamed Boucadair via Datatracker <noreply@ietf.org> Mon, 16 September 2024 14:56 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bess@ietf.org
Delivered-To: bess@ietfa.amsl.com
Received: from [10.244.2.118] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id EC195C14F6AB; Mon, 16 Sep 2024 07:56:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mohamed Boucadair via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172649857459.4021334.16064172944993408610@dt-datatracker-68b7b78cf9-q8rsp>
Date: Mon, 16 Sep 2024 07:56:14 -0700
Message-ID-Hash: FI5KOQQYTPPX2ZZPEF6XB6XMGUVNWEKD
X-Message-ID-Hash: FI5KOQQYTPPX2ZZPEF6XB6XMGUVNWEKD
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: bess@ietf.org, draft-ietf-bess-evpn-bfd.all@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Mohamed Boucadair <mohamed.boucadair@orange.com>
Subject: [bess] Rtgdir early review of draft-ietf-bess-evpn-bfd-07
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/Or7FL0wbuCKYxSQHnNuFLPrbhOo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>

Reviewer: Mohamed Boucadair
Review result: Has Issues

Hi authors,

Thanks for the effort put into this document.

Overall, the document reads well. The specification leverages existing
specifications with exceptions called out it in the document. This approach
seems reasonable, but there are some issues that need to be fixed. These are
highlighted in the detailed review (see below). A subset of them are
highlighted hereafter:

# Better position the document: For example, I failed to find this "network
layer" defined in RFC7432 or 7432bis. I think that you are referring to the
layering in 2.1 of 9062. For example, you can consider adding a sentence in the
introduction about 2.1 of 9062 to position the layer you are considering.

# 7432 or 7432bis: Any reason why the bis is cited explicitly here? Are there
parts of the spec that are not applicable to 7432? I don't think so, but it is
better clarify this in the doc rather than leaving the readers guess.

# "future versions of this document" vs "other documents": The document says in
several places that "It is intended to address this in future versions of this
document.". The intended scope should be clarified.

# Internal inconsistency:

## The document refers to TBD3 and cites Section 8, but there is no such
definition in the IANA section ## The document cites "dedicated unicast MAC"
and "dedicated multicast MAC" but these are not defined in the document.

## RFC 9026

Previous sections state that 9026 is not mandatory and other mechanisms can be
used. However, Section  This text seems to assume that it is always used:

"It also contains a BFD Discriminator
   Attribute [RFC9026] with BFD Mode TDB4 giving the BFD discriminator
   that will be used by the tail.
"

(note that s/TDB4/TBD2)

# Redundant requirements: For example, the document says

"   The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] and
   BFD for VXLAN [RFC8971] are, except as otherwise provided herein,
   applied to test loss of continuity for unicast EVPN traffic.
"
 but then

"   Once the BFD session is UP, the ends of the BFD session MUST NOT
   change the local discriminator values of the BFD Control packets they
   generate, unless they first bring down the session as specified in
   [RFC5884].
"

the intended behavior vs "local discriminator values" here is redundant with
this part in Section 7 of 5884:

"Note that once the BFD session for the MPLS LSP is UP, either end of the BFD
session MUST NOT change the source IP address and the local discriminator
values of the BFD Control packets it generates, unless it first brings down the
session."

No?

# Detailed review can be found here, fwiw:

* pdf:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.pdf
* doc:
https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.doc

Feel free to grab whatever you think useful.

Hope this helps.

Cheers,
Med