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 to https://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). 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". 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 (via https://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. 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. 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/ Document references draft-ietf-lsr-ospf-prefix-extended-flags, but that has been published as RFC9792. 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. Section 2, paragraph 6 > nd external prefix is advertised in it's own LSA, so the above optimisation > ^^^^ 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 > ^^^^^^^^^^^ Did you mean "larger than"? Section 3, paragraph 6 > s initially defined in [RFC7370], e.g.,: - SRv6 Locator [RFC9352] - Extended > ^^ Did you just mean "," or ":"? _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
