[Last-Call] Opsdir last call review of draft-ietf-lsr-ip-flexalgo-11

Qin Wu via Datatracker <noreply@ietf.org> Sat, 13 May 2023 08:26 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41999C169508; Sat, 13 May 2023 01:26:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Qin Wu via Datatracker <noreply@ietf.org>
To: ops-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.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168396640425.52858.8450539260599240244@ietfa.amsl.com>
Reply-To: Qin Wu <bill.wu@huawei.com>
Date: Sat, 13 May 2023 01:26:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/eiuDm70yhohOe7SgzVmlC-Rx1Lw>
Subject: [Last-Call] Opsdir last call review of draft-ietf-lsr-ip-flexalgo-11
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 May 2023 08:26:44 -0000

Reviewer: Qin Wu
Review result: Has Issues

I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

This document extends Flex-Algorithm that is originally used for SR MPLS and
SRv6 data plane, allowing it to compute paths to IPv4 and IPv6 prefixes. This
draft is well written, however I do have a few comments on the latest version
before seeing this work being moved forward:

1. Abstract:
Is regular IPv4 and IPv6 forwarding related to Native IP data plane,
IP dataplane has been describe once in section 5, but most of other places use
IP forwarding, which lack consistency. 2. Introduction, last paragraph: It
looks there are some contradiction here, On one hand, Flex algorithm can be
used independent of data plane technologies such as SR MPLS, SRv6, Native
IPv4/IPv6 On the other hand, it said: Flex algorithm is tied to SR MPLS or SRv6
data plane technology, lack consistency. 3. Section 3 Do we use specific GTP
data plane technology in this 5G use case? If not the case, is there IGP
protocol enabled on both gNodeB and UPF? GTP/Native IP/ IP network with IGP
protocol support Please be more explcit in the use case section. 4.Section 6.1:
Last Paragraph Lack RFC reference for IPv4 Prefix Reachability TLV and IPv6
Prefix Reachability TLV. Why IPv4 prefix reachability TLV can not be used to
Carry algo prefix reachability related information? Suppose both IPv4 prefix
reachability TLV and IPv4 Algorithm Prefix reachability TLV can be used to
carry the similar information, then the question is when we use IPv4 Prefix
Rechability TLV? When we use IPv4 Algorithm Prefix Reachability TLV? Do we over
design for this? 5. Section 6.2: Last two Paragraphs It looks both ISIS SRv6
locator TLV an ISIS IPv6 algorithm Prefix rechability TLV serve the similar
purpose? Why we should introduce ISIS IPv6 Algorithm Rechability TLV?