Hi Stewart,
Thanks for the review and comments.
Pls see inline for replies. Version -10 will address your comments
Juniper Business Use Only
-----Original Message-----
From: Stewart Bryant via Datatracker <noreply@xxxxxxxx>
Sent: Monday, April 8, 2024 10:00 PM
To: rtg-dir@xxxxxxxx
Cc: draft-ietf-lsr-flex-algo-bw-con.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx
Subject: Rtgdir last call review of draft-ietf-lsr-flex-algo-bw-con-08
[External Email. Be cautious of content]
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.
<SH> I added full expansion for all acronyms on first use. Hope that helps.
=========
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.
and
** 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.
=======
<SH> Fixed
Minor English
constraint based paths in IGP. This draft documents a generic metric
SB> s/in/in an/
=======
<SH> Fixed
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
deployed.
SB> Indeed, but so can any micro-loop avoidance method.
<SH> Referred RFC 5715 as well for other possible mechanisms.
=======
A------B====C====F====D
| |
------E-------
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
SB> lower
metric than B E D to attract the traffic via B C F D, but it is not well expressed in the text.
<SH> Updated 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.
=======
<SH> This one is not clear me. Could you pls elaborate more?
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.
<SH> Fixed. The generic metric on for same sub-TLV multiple code points are taken based which TLV it appears-in.
Will have to be co-ordinated with RFC editors I think.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
