Hi Eric,
thanks for your comments, please see my responses inline (##PP):
On 17/09/2025 17:35, Éric Vyncke via Datatracker wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-lsr-igp-ureach-prefix-announce-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
# Éric Vyncke, INT AD, comments for draft-ietf-lsr-igp-ureach-prefix-announce-09
CC @evyncke
Thank you for the work put into this document.
Please find below some non-blocking COMMENT points/nits (replies would be
appreciated even if only for my own education).
Special thanks to Yingzhen Qu for the shepherd's detailed write-up including
the WG consensus (important to note for this I-D) _but it lacks_ the
justification of the intended status.
I hope that this review helps to improve the document,
Regards,
-éric
## COMMENTS (non-blocking)
### Title
s/IGP Unreachable Prefix Announcement/Unreachable Prefix *IGP* Announcement/
sounds clearer to me but English is not my primary language.
##PP
I let the RFC Editors to decide, I feel what we have is better.
### Abstract
s/This document describes/This document *specifies*/ as this is proposed
standard.
##PP
done
### Section 1
Who is the "we" in `we want to signal unreachability` ? The authors ? The LSR
WG ? The IETF ? Please avoid using ambiguous "we" by rephrasing the sentence.
##PP
done
s/ISIS/IS-IS/ ? and in other places.
##PP
done
### Section 2
s/for a prefix that is summarized by the summary *address*/for a prefix that is
summarized by the summary *prefix*/ ?
##PP
done
There are two "SHOULD" in this section but nothing is written the cases when
these "SHOULD" can be bypassed and/or what are the consequences.
##PP
I added:
"Not withdrawing the UPA would result in stale information being kept in
the link state database of all
routers in the area."
Add "and OSPFv3" at the end of `so the above optimisation does not apply to
OSPF` ? It seems that the I-D sometimes uses OSPF for OSPFv2 alone and
sometimes for OSPFv2 and OSPFv3.
##PP
I added and OSPFv3 at the end of the sentence,
### Section 3.1
Add "to support this specification" after `without the need to upgrade all
nodes in a network.` ?
##PP
done
`Those ABRs or ASBRs, which are responsible for propagating UPA advertisements
into other areas or domains MUST also recognize UPA advertisements.` what are
the consequences if this is not the case (e.g., not all ABR/ASBR have been
upgraded). Should this be mentioned in an operational considerations section ?
##PP
added:
"Failure to do so would prevent UPA to reach the routers in the remote
areas or domains."
### Section 5.1
Was the use of a 2-bit field considered rather than using 2 flags ? It would
have allowed 4 values as opposed as the current 3 values. Out of curiosity
because it is probably too late to change it...
##PP
RFC7444 defines the "IPv4/IPv6 Extended Reachability Attribute Flags"
TLV, which is a variable length bitfield. We are simply adding two new
bits in that bitfield.
### Section 8
It is often preferable to add an informational reference to the URI of the
registries.
#PP
never done it, can you please provide an example RFC/draft, I'll follow
that.
thanks,
Peter
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
