Speaking as WG member - see inline. > On May 22, 2025, at 8:51 AM, Peter Psenak <[email protected]> wrote: > > Hi Bruno, > > please see inline (##PP3): > > > On 21/05/2025 17:18, [email protected] wrote: >> 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] wrote: >> Hi Peter, >> Thanks for your reply. >> Please see inline ##Bruno >> From: Peter Psenak <[email protected]> >> Sent: Tuesday, May 20, 2025 2:22 PM >> To: DECRAENE Bruno INNOV/NET <[email protected]>; [email protected] >> Cc: [email protected]; >> [email protected];[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. > > ##PP3 > what you are proposing is to add a timestamp to the TLV and use the TLV based > on its lifetime. I don't think we want to make such a change to the protocol > operation. Pulse draft attempt that at the LSP level and it was considered > too radical change to the protocol. Doing it at TLV level is even more > radical...
I strongly agree that no expiration time or similar info should be added. The originator is responsible for purging the the LSP/LSA. >> >> 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. > ##PP3 > I will add that to the draft. >> 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.” > > ##PP3 > I would rather avoid getting into the specifics of the particular use > case/application. We want to keep the UPA mechanism generic enough. I agree that we don't want to talk about BGP PIC or any other specific use case. Note that after almost 10 years, the BGP PIC draft STILL isn't published. 😎 https://datatracker.ietf.org/doc/draft-ietf-rtgwg-bgp-pic/ Thanks, Acee >> 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. > ##PP3 > that is assumed to be the case, but I can add a text. > thanks, > Peter >> 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]
