Document: draft-ietf-lsr-igp-ureach-prefix-announce Title: IGP Unreachable Prefix Announcement Reviewer: Dale Worley Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-lsr-igp-ureach-prefix-announce-08 Reviewer: Dale R. Worley Review Date: 2025-06-24 IETF LC End Date: 2025-06-24 IESG Telechat date: [not known] Summary: This draft is on the right track but has open issues, described in the review. As far as I can tell, the proposed mechanism is sound as a solution to the stated problem. But I am not a routing expert. However, the document needs improved organization as an exposition of the mechanism. It seems like the current version would be sufficient for a routing expert to implement the mechanism but it lacks the clarity needed for either a standards definition or for non-expert readers. Major issues: It would help if the earlier parts of the document (that is, sections 1 and 2, before the specifics of IS-IS and OSPF usage are introduced) explained the mechanism conceptually. In particular, it would be helpful to have a direct statement of the significance of the U and UP bits, independent of how the bits are implemented in each routing protocol. E.g. A UPA announcement is indicated by attaching the U bit to the announcement of a prefix, which thus indicates that the prefix is unreachable. A UPA may also have the UP bit attached, indicating that the unreachability is due to a planned event. How the U and UP bits are attached to a prefix is dependent on the routing protocol and is described later. In the earlier parts of the document, the phrase "the protocol specific maximum prefix metric" is used in many places. However, it appears that this does not necessarily mean a specific value in the metric field of the protocol, nor is the value necessarily the one descried as "the maximum metric" in the routing protocol definition. For instance, it appears that the condition for IS-IS is: a prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000) (Note that the metric value that indicates unreachability is greater than the one described as "maximum path metric"!) And for OSPF: a prefix that has the age set to a value lower than MaxAge and metric set to LSInfinity or possibly a prefix having the NU-bit set (The situation for OSPF is not at all clear, there seem to be multiple indications of unreachability; see below for more details.) If I am correct, you want to define a term like "the protocol specific way of specifying unreachability". Then you want to state early in the document something like A router that implements UPA MUST attach the U-bit to any announcement that contains the protocol specific way of specifying unreachability. Conversely, any announcement with the U-bit MUST also include the protocol specific way of specifying unreachability. The goal is to give a complete *conceptual* description of the UPA mechanism in sections 1 and 2, and then provide the details of its implementation in IS-IS and OSPF in sections 3, 4, and 5. There are a considerable number of places in the document where all-caps normative words should be used. I have noted some of these below. And almost all uses of the subjunctive "would" should be replaced by more definitive wording. Minor issues: Nits/editorial comments: Some flag bits are described as "bits" and some as "flags", and the capitalization is not consistent. In the document I see NU-bit OL-bit U-Flag UP-Flag These should be made consistent. 1. Introduction ... OSPFV3 ... Comparing with RFC 5340, that probably should be spelled "OSPFv3". Similarly, when an egress router needs to be taken out for Perhaps "taken out of service". the ABR/ASBR It might be useful to expand this acronym or give a phrase explaining what it is/does. "ABR" is used frequently in the document, but the first explanation is in section 4.1. This document proposes protocol extensions to carry information about such prefixes in a backward compatible manner. "such prefixes" is vague here. Perhaps "prefixes in the area which are not reachable". This document defines two new flags in IS-IS and OSPF. It seems to me that the introduction should include some further description of the flags, as at this point, I have no idea what the flags mean. At this point in my reading, I *think* the description is, "This document defines two new flags. One flag is applied to prefixes listed in announcements to the outside world by an ABR to indicate that the prefix is not reachable. The second flag indicates that a prefix is unreachable due to a planned event." These flags, together with the existing protocol mechanisms, provide the support for the necessary functionality. Better "provide what is needed to support this functionality". (The "functionality" itself is not "necessary", as no routers have this functionality today.) 2. Generation of the UPA UPA MAY be generated by the ABR or ASBR for a prefix that is summarized by the summary address originated by the ABR or ASBR in the following cases: 1. Reachability of a prefix that was reachable earlier was lost. 2. For planned maintenance if the node originating the prefix is signalling the overload state in ISIS, or if the prefix itself is advertised with the protocol specific maximum prefix metric. When the ABR/ASBR does so, it MAY set the UP bit to indicate that. ISTM that case 2 has two or possibly three parts, and so it would be better to say 1. Reachability of a prefix that was reachable earlier was lost. 2. For planned maintenance. 3. If the node originating the prefix is signalling the overload state in IS-IS. [hyphenate IS-IS here] 4. If the prefix itself is advertised with the protocol specific maximum prefix metric. When the ABR/ASBR does so, it MAY set the UP bit to indicate that. And it's not clear to me whether that last sentence is part of case 4 or applies to all cases. But case 4 is unclear in regard to who is advertising the prefix with max-metric. The second sentence suggests that this can be done in at least two ways, one "when the ABR/ASBR does so", and one where another unnamed advertiser does so. In any case, since this text talks about the UP bit, the UP bit should have been introduced before this point. Implementations are free to limit the UPA generation to specific prefixes, Why not use "Implementations MAY limit ..."? ABR or ASBR MUST withdraw the previously advertised UPA when the reason for which the UPA was generated was lost Perhaps better, "reason for which the UPA was generated ceases". As UPA advertisements in IS-IS are advertised in existing Link State PDUs (LSPs) and the unit of flooding in IS-IS is an LSP, it is recommended that, when possible, UPAs are advertised in LSPs dedicated to this type of advertisement. Probably clearer to say "dedicated to UPA advertisements", as well as shorter. 3. Supporting UPA in IS-IS (If sections 3 and 4 (not including their subsections) are intended purely as background, it would be helpful to state that initially, as when I was reading both of those sections, I kept trying to figure out how the facts presented connected with the thread of the narrative.) This section gives a somewhat lengthy discussion of the MAX_PATH_METRIC value. But it doesn't specifically say how that interacts with the U/UP bits. I *think* the idea is that "the metric is larger than MAX_PATH_METRIC" is the "protocol specific maximum prefix metric", but of course, MAX_PATH_METRIC isn't that value, instead all values larger than it (0xFE000001 to 0xFFFFFFFF) are meant. This functionality can be used to advertise a prefix (IPv4 or IPv6) in a manner which indicates that reachability has been lost - and to do so without requiring all nodes in the network to be upgraded to support the functionality. I *think* the intention of this is that if a conforming router applies the U-bit to a prefix, it should *also* apply a metric value larger than MAX_PATH_METRIC so that the advertisement is understood as indicating unreachability by routers that don't implement UPA. See the discussion above. 3.1. Advertisement of UPA in IS-IS Area Border Routers (ABRs), which would be responsible for propagating UPA advertisements into other areas would need to recognize such advertisements. Exactly which routers have a requirement are not clear. One meaning is Area Border Routers (ABRs), which are responsible for propagating UPA advertisements into other areas, MUST recognize such advertisements. that is, all ABRs are responsible for propagating into other areas, and so they all must recognize UPAs. But another meaning is Those Area Border Routers (ABRs) which are responsible for propagating UPA advertisements into other areas MUST recognize such advertisements. that is, a specific subset of ABRs. In either case, consider using MUST rather than "need to". 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. Such metric MUST be used when advertising UPA in IS-IS. "purposes other than normal routing calculations" might include a very wide range of semantics. The critical fact is that *all* such values indicate the prefix is unreachable, or, perhaps, that *this* advertisement does not indicate that the prefix is reachable. It would be clearer to state it that way. UPA in IS-IS is supported for all IS-IS Sub-TLVs Advertising Prefix Reachability, e.g., ... Comparing with RFC 9352 suggests you want to mention that "IS-IS Sub-TLVs Advertising Prefix Reachability" is a defined registry ("initially defined in [RFC7370]") and then perhaps continuing with a list of prominent members of the registry: UPA in IS-IS is supported for all sub-TLVs registered in the IS-IS Sub-TLVs Advertising Prefix Reachability registry, which was initially defined in [RFC7370], e.g., ... Importantly, if any sub-TLVs are added to the registry, UPA is automatically applicable to them. 3.2. Propagation of UPA in IS-IS IS-IS allows propagation of IP prefixes in both directions between level 1 and level 2. For reachable prefixes this is only done if the prefix is reachable in source level ... Perhaps clearer as "reachable prefixes are only propagated from a level in which the prefix is reachable." (If that is the correct wording.) 4. Supporting UPA in OSPF This section gives a lengthy discussion of LSInfinity, which is used as a metric value, something called "premature aging", and the NU-bit. All of these seem to be ways of indicating a prefix is unreachable. But their interaction with UPA is not specified. In particular, if an ABR implements UPA, which of these conditions requires that the ABR add the U bit if it is not already present? And for upward compatibility, if the ABR sets the U bit on an advertisement, which of these mechanisms must also be applied to the prefix? 4.1. Advertisement of UPA in OSPF This section additionally mentions the condition "the age set to value lower than MaxAge", which probably integrates with the discussion in section 4 in some way. 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 UPA. This sentence is hard to read, as the essential condition is given only at the very end. Better would be: If an ABR advertises UPA in an advertisement of an inter-area or external prefix inside OSPFv2 or OSPFv3, then it MUST set the age to a value lower than MaxAge and set the metric to LSInfinity. 4.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. Use normative words -- what does "would" mean here? 5. Signaling UPA In IS-IS a prefix can be advertised with metric higher than 0xFE000000, in OSPF with metric LSInfinity, or in OSPFv3 with NU-bit set in PrefixOptions, for various reasons. Even though in all cases the treatment of such metric, or NU-bit, is specified for IS-IS, OSPF and OSPFv3, having an explicit way to signal that the prefix was advertised in order to signal unreachability is required to distinguish it from other cases where the prefix with such metric is advertised. If the metric is LSInfinity, that would seem to indicate definitively that the prefix is unreachable. It would help to give some discussion of what the "other cases" are. 5.1. Signaling UPA in IS-IS If the U-Flag is not set, the UP-Flag MUST be ignored. It seems to me that this holds for UPA generally, not just for IS-IS. And that this is a situation where you want to be "strict in what you send and lenient in what you accept". So put in the routing protocol-independent sections at the beginning: If an ABR does not set the U-Flag on a prefix, it MUST NOT set the UP-flag. In a received advertisement, if the U-Flag is not set on a prefix, the UP-Flag MUST be ignored. 5.2.2. Signaling UPA in OSPFv3 In OSPFv3 the Prefix Attribute Flags Sub-TLV is defined as a Sub-TLV of the following OSPFv3 TLVs as defined in [RFC8362]: Probably should be "that are defined in [RFC8362]", because "as they are defined in [RFC8362]" they don't include Prefix Attribute Flags. 5.3. Treatement of the U-Flag and UP-Flag The setting of the U-Flag or the UP-Flag signals that the prefix is unreachable. This is oddly phrased, given that if UP is set, U MUST be set. UP is not an independent signal. Better to say "The setting of the U-Flag signals that the prefix is unreachable." And then "If the U flag is set, the setting of the UP flag signals that the unreachability is due to a planned event." (It's not clear to me what use an ABR could make of UP independently of U, but there likely are use cases I am not aware of.) And indeed, this semantics should be stated in the routing protocol independent part of the document. Treatment of these flags on the receiver is optional and the usage of them is outside of scope of this document. Clarify that the usage of the flags *by the receiver* is outside the scope of this document, given that this entire document is about the usage of these flags. And given section 7, why is this stated here? 8.2. OSPFv2 and OSPFv3 Prefix Extended TLV Flag Field This document adds two new bits in the "OSPFv2 Prefix Extended TLV Flag Field" and "OSPFv3 Prefix Extended TLV Flag Field" registries: These registries are named "OSPFv2 Prefix Extended Flags" and "OSPFv3 Prefix Extended Flags". 9. Security Considerations - [I-D.ietf-lsr-ospf-prefix-extended-flags] for both OSPFv2 and OSPFv3. Checking draft-ietf-lsr-igp-ureach-prefix-announce-08, its Security Considerations is only Procedures and protocol extensions defined in this document do not affect the OSPFv2 or OSPFv3 security models. See the "Security Considerations" Section of [RFC7684] for a discussion of OSPFv2 TLV- encoding considerations, and the "Security Considerations" Section of [RFC8362] for a discussion of OSPFv3 security. It seems to me that you might as well include RFC 7684 and RFC 8362 in the list of section 9 of the current document and omit referring to draft-ietf-lsr-igp-ureach-prefix-announce. If draft-ietf-lsr-igp-ureach-prefix-announce contains security information beyond its Security Considerations referencing those RFCs, it would be desirable to point that out explicitly here, as otherwise the reader might follow this reference and only read the Security Considerations of the referenced I-D. [END] -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
