Document: draft-ietf-lsr-igp-ureach-prefix-announce Title: IGP Unreachable Prefix Announcement Reviewer: Bruno Decraene Review result: Has Nits Hello I have been selected to do a routing directorate “early” review of this draft. https://www.ietf.org/archive/id/draft-ietf-lsr-igp-ureach-prefix-announce-05.html The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Document: draft-ietf-lsr-igp-ureach-prefix-announce-05 Reviewer: Bruno Decraene Review Date: 2025-05-19 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG. Comments: == IS-IS UPA == It's not crystal clear to me what the normative UPA signal is for IS-IS. On one hand, section 2.1 seems to say that the UPA signal is a specific (set of) metric value(s) higher than 0xFE000000, to be chosen locally hence configured by the network operator. "any prefix advertisement with a metric value greater than 0xFE000000 can be used for purposes other than normal routing calculations. Such an advertisement can be interpreted by the receiver as a UPA." "Optionally, an implementation may use local configuration to limit the set of metric values which will be interpreted as UPA." On the other hand, section 5.3 specify that this is the setting of the flags which signals that the prefix is unreachable As this is required for interop, this should be clarified. (as per WG discussion, I believe that §5.3 is right and hence §2.1 needs to be updated) == OSPF UPA == §3.1 I'm not familiar with OSPF, but the 2 following sentences seems inconsistent: "Existing nodes in a network which receive UPA advertisements will propagate it following existing standard procedures defined by OSPF." "OSPF Area Border Routers (ABRs), which would be responsible for propagating UPA advertisements into other areas would need to recognize such advertisements." I'm reading the first sentence as saying existing (all) nodes will propagate UPA as per pre-existing OSPF standard procedures. While the second sentence seems to say that ABR would need to be upgrated or configured to recognize UPA. Also, those two sentences seem to be related to §3.2 "Propagation of UPA in OSPF" so may be they should be moved to §3.2. == UPA == §5.1 and §5.2.1/2 includes the specification on the receiver, in particular "error handling" when the flag does not match the metric. It would be good to also specify the error handling when the node advertising the UPA does not advertise a summary address. (this is mandatory as per §4) == deployment consideration == The first four paragraph of §6 seems to be part of the specification (for implementors) rather than part of "deployment consideration" (mostly for network operators) I think they should be moved to a different section. == §6 == " UPA advertisements SHOULD therefore be withdrawn after a modest amount of time" It's not clear to me why this time requirement ("modest amount of time") is added. This seems to double the amount of churn, while the UPA withdraw could possibly be delayed up to the next LSA/LSP refreshment. (the drawback seems some extra memory usage in routers, but few octets for a few hours are expected to be OK in such scalled networks requiring multiple areas and aggregation) -- The IANA section requests IANA to allocate new flags, while the IANA has already allocated them. I would suggest to update the text with the allocated values, and to ask IANA to make these allocations permanent. (An example of sentence may be found in first paragraph of https://datatracker.ietf.org/doc/html/draft-ietf-idr-entropy-label-17#name-iana-considerations) Other sections in the document have "Bit TBD" and needs to be updated to reflect the IANA allocations. === Typo: §1 :s/OSPFV3/OSPFv3 §2.2 :s/vice verse/vice versa §4 :s/ISIS/IS-IS §8.2 :s/registres/registries -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
