Peter, Dale, Please see inline [Bruno]
From: Peter Psenak <[email protected]> Sent: Thursday, June 26, 2025 5:04 PM To: Dale Worley <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: [Lsr] Re: draft-ietf-lsr-igp-ureach-prefix-announce-08 ietf last call Genart review Hi Dale, thank you for your comments, please see responses inline (look for ##PP): I have updated the draft and attached the diffs. On 24/06/2025 19:57, Dale Worley via Datatracker wrote: 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><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. ##PP I appreciate your effort to make the document more readable for the non-experts, but I'm afraid, some level of routing expertise would still be required from the reader. We are building on existing RFCs and a familiarity with those is expected. But I'll try to make easier to read. 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. ##PP: This document does NOT define how to advertise prefix unreachability. That has been defined long time back in RFC5305, RFC2328, and RFC5340. [Bruno] That is not the case for IS-IS [RFC5305]. IS-IS has no existing procedure to advertise negative reachability (aka advertising unreachability). It has procedure for: - Advertising reachabilty (by advertising the prefix in Extended IP Reachability TLV with a metric below 0xFE000000) - Not advertising reachability (by either not advertising the prefix or by advertising a metric larger than MAX_PATH_METRIC (0xFE000000) Not advertising reachability (0) is different from advertising unreachability (-1). This document only defines a method to signal WHY the explicit unreachability is sent, to distinguish it from any other possible cases, where sending explicit unreachability may be used. Please note that protocols typically just stop advertising the prefix reachability, which makes the previously advertised prefix unreachable. Here the use case is to signal unreachability for a prefix for which the previous reachability was not explicitly signaled, because it was covered by the reachability of the summary-address. 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) ##PP "the protocol specific maximum prefix metric" is used in two places. There are two different thing that the document refers to: a) metric used when advertising unreachability - e.g. in case of ISIS metric higher than 0xFE000000 , in case of OSPFv3 LSInfinity, and in case of OSPFV3 it's the NU-bit b) "the protocol specific maximum prefix metric", which is not the metric used for UPA itself. It is the maximum reachable prefix metric protocols allow to advertise, e.g. 0xFE000000 for ISIS. To avoid the confusion, I will replace the "the protocol specific maximum prefix metric" , by the "user configured protocol metric threshold", which would be much more clear and also flexible in terms of when the UPA can be generated. (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. ##PP advertisement of the prefix unreachability has been defined in the past and we are not allowed to change it, as that would result in a backward compatibility issue. [Bruno] It's good that we agree that changing the semantic of IS-IS metric 0xFE000000 would result un a backward compatible issue and that we are not allowed to change it. This has already been discussed on the list and we had agreed that the resolution was to use a flag to signal unreachability for IS-IS https://mailarchive.ietf.org/arch/msg/lsr/DS7L3CQd5UCTuv-S_pH7iCysxwI/ So we can not mandate any new-bit for signaling the unreachability. We are just indicating with the optional new flags the reason why the unreachbaility was advertised. 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. ##PP let me add some additional clarification text, possibly from my responses above, to see if that would make you fell better about it. 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. ##PP I have respond to individual case below 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. ##PP NU-bit is the name from OSPFv3 Prefix Options registry OL-bit ISO10589 ras well as RFC5120 refer to it as bit, I will replace it with OVERLOAD bit to be consistent with RFC5120. U-flag and UP-flag are defined in: "IS-IS Bit Values for Prefix Attribute Flags Sub-TLV" "OSPFv2 Prefix Extended Flags" "OSPFv3 Prefix Extended Flags" all of the above registries use "flag", rather than bit. So we are consistent to the degree possible I believe. 1. Introduction ... OSPFV3 ... Comparing with RFC 5340, that probably should be spelled "OSPFv3". ##PP absolutely, fixed it. Similarly, when an egress router needs to be taken out for Perhaps "taken out of service". ##PP fixed it. 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. ##PP done 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". ##PP replaced with "these summarized prefixes" 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." ##PP the definition of these flags are in section 5.1 and 5.2. The definition of these flags are not tight to the ABR role. They may be used elsewhere in the future if the use case arises. 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.) ##PP again, we are coming back to the fact that the functionality exists today, we are only defining a way to signal WHY we are using it. I have updated the text, let me know if you agree. 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. ##PP no, 3 and 4 are part of planned maintenance case, that's why they are bundled in (2). I have split the bullet 2 to multiple sub-bullets to make it clear. 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. ##PP well, some other reviewer asked me to move this section before the protocol specific sections :) So what I did is that I removed the reference to UP-bit in section 2, it was not needed there. Implementations are free to limit the UPA generation to specific prefixes, Why not use "Implementations MAY limit ..."? ##PP done 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". ##PP done 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. ##PP the whole point of the above paragraph is to say that dedicated LSPs, so I would rather use that explicit terminology. 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.) ##PP there are quotes from RFC5305 and RFC5308 about how to advertise the prefix unreachability. They also specify how to do that for the use case that we are trying to address - e.g. summarization. They also talk about the specifics of UPA propagation, that are new. So it's not just a background. 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. ##PP These are existing protocol definitions that we refer to. And yes, existing RFC clearly states that any metric larger than MAX_PATH_METRIC is considered unreachable. 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. ##PP again the new bits are to signal WHY the unreachability has been sent, they are not meaning unreachability by themselves. 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". ##PP good comment, changed it. 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. ##PP that terminology was taken from the RFC5308 and it was done intentionally. I would prefer to keep it as it gives the reader a clear reference to the existing specification. 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., ... ##PP done 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.) ##PP done 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? ##PP I hope my previous responses made it clear. 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. ##PP done 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? ##PP done 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. ##PP there are none defined today, we are defining the first standardized "case" for sending prefix with unreachable metric. One can possibly advertise the prefix with unreachable metric and attach some private TLVs to it. Obviously these would be non-standard, but that was where the need for these new bits started originally in the WG. I have put some text around this in the section 1. 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. ##PP done 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. ##PP done 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. ##PP I have removed the sentence. It was not correct anyway, because the meaning of the bits have already defined earlier. I have removed the entire section and updated the section 7. [Bruno] The use of the flags to _signal_ the unreachability in IS-IS is a WG consensus at the time of WG adoption. https://mailarchive.ietf.org/arch/msg/lsr/DS7L3CQd5UCTuv-S_pH7iCysxwI/ I object to this removal; especially that late in the process. Thanks --Bruno 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. ##PP done in section 7 And given section 7, why is this stated here? ##PP good point, above two responses should address this comment. 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". ##PP good catch, fixed. 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. ##PP I suppose you meant ietf-lsr-ospf-prefix-extended-flags. It is now RFC9792, and I replaced the reference to it with reference to RFC 7684 and RFC 8362 as you suggested thanks, Peter 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] ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
