Hi Peter, Please see inline ##Bruno2
From: Peter Psenak <[email protected]> Sent: Tuesday, May 20, 2025 6:53 PM To: DECRAENE Bruno INNOV/NET <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: draft-ietf-lsr-igp-ureach-prefix-announce-05 ietf last call Rtgdir review Hi Bruno, please see inline (##PP2): On 20/05/2025 18:02, [email protected]<mailto:[email protected]> wrote: Hi Peter, Thanks for your reply. Please see inline ##Bruno From: Peter Psenak <[email protected]><mailto:[email protected]> Sent: Tuesday, May 20, 2025 2:22 PM To: DECRAENE Bruno INNOV/NET <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: draft-ietf-lsr-igp-ureach-prefix-announce-05 ietf last call Rtgdir review Hi Bruno, thanks for your review, please see inline (##PP): On 19/05/2025 16:54, Bruno Decraene via Datatracker wrote: 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." ##Bruno Looks good. Thank you. == 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. ##Bruno Looks good. Thank you. == 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. ##Bruno OK == 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 :) ##Bruno I would move them in § 4. "Generation of the UPA". But I'm not insisting, up to you. == §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. ##Bruno State is ephemeral. But this delay may be enforced locally without requiring signaling. ##PP2 how? The UPA TLV is a regular prefix TLV that can only be removed by its originator. ##Bruno2 Sure, TLV would stay. But thanks to the metric, it will not be used for normal routing calculations. Then "usage of them is outside of scope of this document". And the usage could be defined to not use the UPA after a certain duration. Cf draft-ppsenak-lsr-igp-event-notification "Limited Lifetime - pulses are short-lived. There is no flushing or purging mechanism for pulses. » ##PP2 right, but there we defined a new LSP that had the ephemeral nature, we don't have it in the base protocol. My question is about the cost & benefit of _signaling_ the UPA withdraw. And its urgency. The document recommends a second signaling within the timeframe of the failure. However, the failure may be more extensive and may require more signaling from other nodes. Adding signaling for very added value within this failure timeframe is adding stress at the wrong time. ##PP2 UPA usefulness ends once it is fully flooded. There is no point to keeping it around for a long time. I think the document is very good in stating that a minimal delay should be used, to make sure that the LSP had time to be flooded. (which may be a question in itself given the discussion on draft-rigatoni-lsr-isis-fragment-timestamping. i.e., how long does it take to flood LSP in large deployment). But to me the maximum delay could be left to each implementation, possibly depending on the conditions at the time (the scale, instability in the network, number of UPA to be withdrawn...). ##PP2 We are not specifying any specific time, we are leaving it up to the implementation. The existing text tries to explain the fact that there is no point keeping the UPA for a long period of time. I can change "SHOULD therefore be withdrawn after a modest amount of time" with "SHOULD not be kept for a prolonged period of time" if that makes you fell better about it. ##Bruno2 Works for me, thanks (alternatively, :s/modest amount of/some). I also like "The time the UPA is kept in the network SHOULD also reflect the intended use-case for which the UPA was advertised." But this adds an unnecessary dependency as the ABR would need to be aware of the application using the UPA. One option would be for this delay to be configuration by the network operator, but this may be a bit late to introduce this, even if a MAY makes it purely optional. Another option may be to specify a minimum amount of time such that application can decide whether this is enough for them, or not. May be also adding an example with BGP PIC as "a modest amount of time" may means something different for an IGP guy and for a BGP guy. For example "For BGP PIC Edge, this means enough time for the BGP convergence to be finished." Finally, I would prefer to see a text requiring the withdraw of the UPA if the prefix comes back up. I don't remember reading this point in the current text. Anyway, up to you. Feel free to upload a new version at your convenience. Thanks, --Bruno thanks, Peter Thanks, --Bruno -- 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 ____________________________________________________________________________________________________________ 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. ____________________________________________________________________________________________________________ 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.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
