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)
##PP
In the Introduction section we have a text that says:
"This document defines two new flags in IS-IS and OSPF. These flags, together with the existing protocol mechanisms, provide the support for the necessary functionality. The functionality being described is called Unreachable Prefix Announcement (UPA)."
Section 2.1 talks specifically about the metric used with the
UPA. It does not conflict with the section 5.3.
What about if I modify the text in section 2.1 as follows:
"As per the definitions referenced in the preceding section, any prefix advertisement with a metric value greater than 0xFE000000 can be used for purposes other than normal routing calculations. The usage of such metric MUST be used when advertising the UPA."
And I will remove the following text:
"Optionally, an implementation may use local configuration to limit the set of metric values which will be interpreted as UPA. The only restriction is that such values MUST be greater than 0xFE000000."
== 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.
##PP
What about this:
3.1 Advertisement of UPA in OSPF
Using the existing mechanism already defined in the standards, as described in previous section, an advertisement of the inter-area or external prefix inside OSPFv2 or OSPFv3 LSA that has the age set to value lower than MaxAge and metric set to LSInfinity MUST be used when advertising the UPA.
"UPA flooding inside the area follows the existing existing standard procedures defined by OSPF."
3.2 Propagation of UPA in OSPF
OSPF Area Border Routers (ABRs), which would be responsible for propagating UPA advertisements into other areas would need to recognize such advertisements.
Advertising prefix reachability between OSPF areas assumes prefix
reachability in a source area. Such requirement of reachability
MUST NOT be applied for UPAs, as they are propagating
unreachability.
OSPF ABRs may wish to advertise received UPAs into other connected areas. When doing so, the original LSInfinity metric value in UPA MUST be preserved. The cost to reach the originator of the received UPA MUST NOT be considered when readvertising the UPA to connected areas.
== 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)
##PP
I' would not limit the UPA usage to summarization. Maybe we find
other use case in the future.
Section 4 says MAY, it does not say UPA MUST NOT be generated
otherwise.
== 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.
##PP
I'm not sure I feel the same, but if you insist, I can move them
to a new section that you provide a name for :)
== §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)
##PP
UPA is by nature ephemeral, so it makes no sense to keep it in the
network when it provides no useful state.
-- 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.
##PP
sure, will update that once we agree on the above changes. We now
have the IANA allocations for OSPFv2/v3
thanks,
Peter
=== 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
