[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
- [bess] Rtgdir early review of draft-ietf-bess-evp… Mohamed Boucadair via Datatracker
- [bess] Re: [EXTERNAL] [RTG-DIR]Rtgdir early revie… Alexander Vainshtein
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… mohamed.boucadair
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… Alexander Vainshtein
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… Donald Eastlake
- [bess] Re: [RTG-DIR]Re: Rtgdir early review of dr… mohamed.boucadair
- [bess] Re: [RTG-DIR]Re: Rtgdir early review of dr… Greg Mirsky
- [bess] Re: [RTG-DIR]Re: Rtgdir early review of dr… Greg Mirsky
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… Donald Eastlake
- [bess] Re: Rtgdir early review of draft-ietf-bess… Donald Eastlake
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… Alexander Vainshtein
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… Donald Eastlake
- [bess] Re: [RTG-DIR]Re: Rtgdir early review of dr… mohamed.boucadair