[speaking as work group participant] Hi Aijun,
I just wanted to share a couple of thoughts in response to your message. First, I feel your note is revisiting the topic around the PUA draft [2] in a way that runs counter to the earlier formal warning from Yingzhen [1]. Reopening that discussion at this point doesn’t help strengthen the UPA procedures and seems to be circling back on a topic that the working group has already moved past. Second, based on the procedures outlined in the UPA draft [3], my development team has successfully implemented UPA and is using it as foundational part of our BGP PIC FRR solution. We’re quite familiar with how link-state protocols operate, and we’ve found the documented behavior in [3] to be sufficient for developing an interoperable and reliable implementation. In our solution, the UPA is used to trigger BGP PIC fast reroute exactly as Peter described [4]. When a UPA is received, the BGP PIC FRR process kicks in, and when the UPA is no longer advertised and only the summary prefix remains, the system quickly and gracefully reverts back to the original state without any issues. This solution is now used by network operators who understand the procedures of link-state routing protocols, UPA and BGP PIC FRR well. [1] https://mailarchive.ietf.org/arch/msg/lsr/S7Mqk2JljYgG8kjEPmH6KlLtbfw/ [2] https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ [3] https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/ [4] https://mailarchive.ietf.org/arch/msg/lsr/EFb71fc-hc-_oMCnksOZfSPt0-o/ Hope this helps clarify our experience and perspective. Gunter Van de Velde (speaking as WG participant) From: Aijun Wang <wangai...@tsinghua.org.cn> Sent: Tuesday, May 27, 2025 1:05 AM To: Peter Psenak <ppse...@cisco.com> Cc: lsr@ietf.org Subject: [Lsr] Re: 答复: I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi, Peter: Please refrain your comments. As the initiators of such mechanism, we describe the whole process 3 years earlier than the first version of your draft. Respect the creator of any idea is the basic behavior of IETF community. Back to your example: You forgot the important part of the puzzle—-the application that the UPA triggered. How and when the application being triggered back to its original state? Image one scenario, some nodes advertised accidentally the wrong UPA signals within the network, how can you revoke it quickly and eliminate the wrong triggered actions? Aijun Wang China Telecom On May 26, 2025, at 17:52, Peter Psenak <mailto:ppse...@cisco.com> wrote: On 26/05/2025 10:26, Aijun Wang wrote: No, summary can’t achieve the same aim of the “Explicit Withdrawn Signal”, for example, switch back to the application’s original state. you don't understand the basic operation of the protocol. 1. prefix p1/32 is summarized with p2/16. P1 is reachable via summary 2. router that generated p1 went down 3. UPA for p1/32 was generated 4. router that generated p1 came back 5. UPA was removed and we are back to state (1) Peter 发件人: Peter Psenak [mailto:ppse...@cisco.com] 发送时间: 2025年5月26日 15:41 收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn 抄送: mailto:lsr@ietf.org 主题: Re: 答复: [Lsr] Re: 答复: I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt On 26/05/2025 03:29, Aijun Wang wrote: Then one new deficiency for the mechanism is emerging: The lack of the Explicit Withdrawn Signal(EWS) when the prefix is reachable again. Please note, stop sending the UPA message doesn’t mean the prefix is reachable again. If there is no EWS, then the network can’t back to its original state before the UPA signaling when the reachable of prefix recover. there is still a summary that covers the prefix reachability. Peter Best Regards Aijun Wang China Telecom 发件人: Peter Psenak [mailto:ppse...@cisco.com] 发送时间: 2025年5月23日 19:11 收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn 抄送: mailto:lsr@ietf.org 主题: Re: [Lsr] Re: 答复: I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt On 23/05/2025 12:48, Aijun Wang wrote: Then nothing needs to be standardized when the prefix becomes reachable again. 1) In some critical scenarios, when the ABR sends one UPA message out and the prefix becomes reachable immediately, what the ABR can do is to stop advertising UPA. and that is exactly what the text says. Peter The sent UPA message will eventually trigger the action on the receiver, even the prefix is reachable immediately. 2) In normal situations, the ABR sends the UPA message for some time and stop sending it further. At this time, when the prefix becomes reachable, nothing needs to be done at ABR. The receiver will also act on the UPA signaling. It’s irrelevant then whether the prefix is reachable or not after the UPA signaling is sent out. Aijun Wang China Telecom On May 23, 2025, at 17:18, Peter Psenak mailto:ppse...@cisco.com wrote: On 23/05/2025 10:10, Aijun Wang wrote: Then, what’s the differences between the two statements: first is for case when the prefix reachability is not regained after UPA was generated. Second is when the prefix reachability was regained before the UPA was withdrawn. It basically says UPA must be withdrawn at the time the prefix becomes reachable. “UPA advertisements SHOULD therefore be withdrawn after some amount of time, that would provides sufficient time for UPA to be flooded network-wide and acted upon by receiving nodes, but limits the presence of UPA in the network.” And: “ABR or ASBR MUST withdraw the previously advertised UPA when the reason for which the UPA was generated was lost - e.g. prefix reachability was restored or its metric has changed such that it does not represent the protocol specific maximum prefix metric.” Here, does “withdraw” just mean to “stop advertisement”? yes. Peter If no, what’s the mechanism of second “withdraw”? Best Regards Aijun Wang China Telecom 发件人: mailto:forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Peter Psenak 发送时间: 2025年5月23日 14:55 收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn; mailto:lsr@ietf.org 主题: [Lsr] Re: 答复: I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt On 23/05/2025 03:32, Aijun Wang wrote: Hi, All: I must point out that the updated draft doesn't address previous issues that described in [1]. Especially, the activation of flawed LSInfinity feature(there is detail analysis for this flawed feature that is defined in OSPF 2328). And, some updated contents will deteriorate the traffic pattern within the network. For example, It says: “ABR or ASBR MUST withdraw the previously advertised UPA when the reason for which the UPA was generated was lost”. The above requirement will advertise the specific prefixes within the network, which will weaken the original summary effect, and attract the traffic via one or some of ABRs. no, above is not true, the new text does not say to advertise reachablity for a summarized prefix, it only talks about removing the previously advertised UPA. Please read carefully before commenting. Peter [1]: Reasons of abandoning UPA: https://datatracker.ietf.org/doc/draft-wang-lsr-reasons-of-abandon-upa-proposal/ Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: mailto:forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 mailto:internet-dra...@ietf.org 发送时间: 2025年5月22日 21:20 收件人: mailto:i-d-annou...@ietf.org 抄送: mailto:lsr@ietf.org 主题: [Lsr] I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt Internet-Draft draft-ietf-lsr-igp-ureach-prefix-announce-06.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: IGP Unreachable Prefix Announcement Authors: Peter Psenak Clarence Filsfils Daniel Voyer Shraddha Hegde Gyan Mishra Name: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt Pages: 14 Dates: 2025-05-22 Abstract: In the presence of summarization, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic away from the node which owns the prefix and is no longer reachable. This document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-06 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-ureach-prefix-announce-06 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ Lsr mailing list -- mailto:lsr@ietf.org To unsubscribe send an email to mailto:lsr-le...@ietf.org _______________________________________________ Lsr mailing list -- mailto:lsr@ietf.org To unsubscribe send an email to mailto:lsr-le...@ietf.org _______________________________________________ Lsr mailing list -- mailto:lsr@ietf.org To unsubscribe send an email to mailto:lsr-le...@ietf.org _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
