[Int-dir] Intdir telechat review of draft-ietf-lsr-ip-flexalgo-12

Antoine Fressancourt via Datatracker <noreply@ietf.org> Thu, 01 June 2023 09:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: int-dir@ietf.org
Delivered-To: int-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBAFC151994; Thu, 1 Jun 2023 02:22:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Antoine Fressancourt via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: draft-ietf-lsr-ip-flexalgo.all@ietf.org, last-call@ietf.org, lsr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168561134224.9013.2692506261437440094@ietfa.amsl.com>
Reply-To: Antoine Fressancourt <antoine.fressancourt@huawei.com>
Date: Thu, 01 Jun 2023 02:22:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/ohGCGJbY_SoZ-JMOwtX1_lKIU4Y>
Subject: [Int-dir] Intdir telechat review of draft-ietf-lsr-ip-flexalgo-12
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jun 2023 09:22:22 -0000

Reviewer: Antoine Fressancourt
Review result: Ready

I have reviewed this document as part of the INT area directorate's ongoing
effort to review all IETF documents being processed by the IESG.

The document, in version 12, is well written. The objectives of the draft are
clearly stated, and relate to the requirement stated in RFC 9350 to describe in
specific document each extension of Flex-Algorithm beyond SR-MPLS and SRv6
data-planes. The draft's structure is borrowed from RFC 9350 and describes
forwarding or operational considerations.

In my view, the document is ready to be published. I only have one minor
comment that the author might ignore as it may stem from my inexperience with
IGP Flex Algorithms. As far as I can tell, the metrics that can be used in
flexalgo can be rather dynamic. Given this dynamicity, what is the policy that
should be adopted in case the metric for a given prefix is updated very
frequently? IGP convergence can take time, and consumes resources on the
routers, and I was wondering if there would be some sort of threshold or
minimum time before an update is considered.

Nits from the Gen-ART review have been addressed in version 12.