Hi Mahesh,
thanks for comments, please see inline (##PP):
On 23/09/2025 15:49, Mahesh Jethanandani via Datatracker wrote:
Mahesh Jethanandani 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:
----------------------------------------------------------------------
Section 1, paragraph 0
Link-state IGP protocols like IS-IS [ISO10589], OSPF [RFC2328], and
OSPFv3 [RFC5340] are primarily used to distribute routing information
between routers belonging to a single Autonomous System (AS) and to
calculate the reachability for IPv4 or IPv6 prefixes advertised by
the individual nodes inside the AS. Each node advertises the state
of its local adjacencies, connected prefixes, capabilities, etc. The
collection of these states from all the routers inside the area form
a link-state database (LSDB) that describes the topology of the area
and holds additional state information about the prefixes, router
capabilities, etc.
Use of OSPF, OSPFv2 and OSPFv3 is confusing in this draft. The title of RFC2328
is "OSPF Version 2", not "OSPF", which is often used to refer to both OSPFv2
and OSPFv3. Could the authors correct and clarify when the statement is
applicable to OSPFv2, or OSPFv3 or both (by using OSPF).
##PP
done. Now the term OSPF is used to refer to both OSPFv2 and OSPFv3 only.
I added following text in the Introduction section:
"The term OSPF in this document is used to cover both OSPFv2 and OSPFv3
protocols."
Section 2, paragraph 9
It is also RECOMMENDED that implementations limit the number of UPA
advertisements which can be originated at a given time.
This and other Sections documents several configuration parameters, including a
knob to enable the advertisment of UPA and the reception and processing of
them. It would be useful to summarize all the configuration (and maintenance)
options this document is introducing in a separate section called "Operational
Considerations".
##PP
I'm not a fan of "Operational Considerations" sections. I believe what
we have is sufficient.
Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:
* Term "traditionally"; alternatives might be "classic", "classical",
"common", "conventional", "customary", "fixed", "habitual", "historic",
"long-established", "popular", "prescribed", "regular", "rooted",
"time-honored", "universal", "widely used", "widespread"
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (viahttps://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.
Section 1, paragraph 3
IGP protocols typically only advertise the reachability of the
prefix. Prefix that was previously advertised as reachable is made
unreachable just by withdrawing the previous advertisement of the
prefix. In our use case, we want to signal unreachability for a
prefix for which the reachability was not explicitly signaled
previously, because it was covered by the reachability of the summary
address.
As Eric has already commented, who is "ours" or "we"? Please avoid the usage of
such terms.
##PP
it has been corrected based on Eric's comment
Section 1, paragraph 3
This document also defines how the UPA is propagated across ISIS
levels and OSPF areas.
s/ISIS/IS-IS/ here and everywhere in the document.
##PP
it has been corrected based on Eric's comment
Section 2, paragraph 6
The intent of UPA is to provide an event driven signal of the
transition of a destination from reachable to unreachable. It is not
intended to advertise a persistent state. UPA advertisements SHOULD
therefore be withdrawn after some amount of time, that would provides
sufficient time for UPA to be flooded network-wide and acted upon by
receiving nodes, but limits the presence of UPA in the network. The
time the UPA is kept in the network SHOULD also reflect the intended
use-case for which the UPA was advertised.
s/that would provides/that would provide/
##PP
fixed
Document references draft-ietf-lsr-ospf-prefix-extended-flags, but that has
been published as RFC9792.
##PP
that has been fixed based on Ketan's comment
Section 2, paragraph 5
e UPA was advertised. s/that would provides/that would provide/ Implementatio
^^^^^^^^
The modal verb "would" requires the verb's base form.
##PP
fixed
Section 2, paragraph 6
nd external prefix is advertised in it's own LSA, so the above optimisation
^^^^
##PP
fixed
Did you mean "its" (possessive pronoun) instead of "it's" (short for "it is")?
Section 2, paragraph 9
efix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see
^^^^^^^^^^^
##PP
fixed
Did you mean "larger than"?
Section 3, paragraph 6
s initially defined in [RFC7370], e.g.,: - SRv6 Locator [RFC9352] - Extended
^^
##PP
fixed
Did you just mean "," or ":"?
thanks,
Peter
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
