[RTG-DIR] Rtgdir last call review of draft-ietf-lsr-flex-algo-bw-con-08

Stewart Bryant via Datatracker <noreply@ietf.org> Mon, 08 April 2024 16:30 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 3E265C1516EA; Mon, 8 Apr 2024 09:30:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stewart Bryant via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-lsr-flex-algo-bw-con.all@ietf.org, last-call@ietf.org, lsr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171259380923.52434.3772146290498308106@ietfa.amsl.com>
Reply-To: Stewart Bryant <stewart.bryant@gmail.com>
Date: Mon, 08 Apr 2024 09:30:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/qW7ULX1F22E7hlrQI4TDPR81je4>
Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-lsr-flex-algo-bw-con-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: Mon, 08 Apr 2024 16:30:09 -0000

Reviewer: Stewart Bryant
Review result: Has Nits

I reviewed version 08 as a RTG Area reviewer.

This is a well written document that has a few editorial issues that could
usefully  be looked at before proceeding. Some affect the text that the reader
will see, some affect the production process.

It is not clear that all abbreviations are expanded on first use and a detailed
check by the editor should be carried out. The editor could usefully include a
terminology section or a glossary to help the new reader with the
not-officially-well-known abbreviations. I picked up ASLA, FAPM, FAEMB there
may be others.


The nits checker picked up:

  ** There are 13 instances of too long lines in the document, the longest
     one being 11 characters in excess of 72.


 ** Obsolete normative reference: RFC 8919 (Obsoleted by RFC 9479)

  ** Obsolete normative reference: RFC 8920 (Obsoleted by RFC 9492)

  -- Obsolete informational reference (is this intentional?): RFC 5316
     (Obsoleted by RFC 9346)

It also picked up RFC-ietf-lsr-flex-algo-bw-con-04 meaning "This RFC" perhaps
consider that to avoid all the reviewers figuring out what is happening.

Minor English
   constraint based paths in IGP.  This draft documents a generic metric
SB> s/in/in an/


 The micro-loop avoidance procedures
   described in [I-D.bashandy-rtgwg-segment-routing-uloop] can be used
   to avoid micro-loops when the automatic metric calculation is
SB> Indeed, but so can any micro-loop avoidance method.

                  |              |

                       Figure 7: Parallel interfaces

   For exmple, in the above diagram, there are two parallel links
   between B->C, C->F, F->D.  Let us assume the link bandwidth is
   uniform 10Gbps on all links and the metric for each link will be the
   same.  Traffic from B to D will be forwarded B->E->D.  Since the
   bandwidth is higher on the B->C->F->D path, the metric for that path
   should be lower, and that path should be selected.  Interface Group
   Mode is preferred in cases where there are parallel layer-3 links.

SB> This paragraph is not well expressed. Please consider rewording.
SB> I think that you man to say that the B C F D path needs to have a lower
metric than B E D to attract the traffic via B C F D, but it is not well
expressed in the text.

   In the interface group mode, every node MUST identify the set of
   parallel links between a pair of nodes based on IGP link
   advertisements and MUST consider cumulative bandwidth of the parallel
   links while arriving at the metric of each link.
SB> Of course it is a bit more subtle because there will be additional
forwarding delay in F and we need to consider ingress traffic at C, F and E.


In the text you use a uniform term TBD and in IANA a uniform term TBA. For
clarity in later stages of the publication process it might be useful to give
each IANA parameter a unique identifier, for example TBD1, TBD2 etc.