OK, you say Gunter talk about the Case 2. It's no problem. Then, what's your considerations of Case 1?
-----邮件原件----- 发件人: Peter Psenak [mailto:[email protected]] 发送时间: 2025年5月28日 16:40 收件人: Aijun Wang <[email protected]>; 'Gunter van de Velde (Nokia)' <[email protected]> 抄送: [email protected] 主题: Re: 答复: 答复: [Lsr] Re: 答复: I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt On 28/05/2025 10:24, Aijun Wang wrote: > Hi, Peter: > > We are talking about when to switch back to the remote failure PE, not switch > from it. > > In Case 1, when UPA advertise for a configured time to "allows BGP to > converge after the remote PE failure ", then ABR stop advertising UPA, right? > At this moment, should the receiver switch back BGP PIC to the previous > failure PE? it can not switch back to failed PE, because BGP on remote nodes know that such PE does not exist anymore - e.g. BGP has converged. > > According to Gunter's logic, it should switch back to the previous failure > PE, because the summary address indicates the specific failure PE is > reachable again. Gunter was talking about the case, where the remote PE loopback prefix reachability was recovered shortly after the UPA was generated, so there would still be a valid BGP path via such PE. Peter > What's your thought? > > > Best Regards > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: Peter Psenak [mailto:[email protected]] > 发送时间: 2025年5月28日 16:10 > 收件人: Aijun Wang <[email protected]>; 'Gunter van de Velde > (Nokia)' <[email protected]> > 抄送: [email protected] > 主题: Re: 答复: [Lsr] Re: 答复: I-D Action: > draft-ietf-lsr-igp-ureach-prefix-announce-06.txt > > On 28/05/2025 09:35, Aijun Wang wrote: >> Hi, Gunter: >> >> I don’t recommend to design one " brand-new control plane signal " to signal >> the prefix reachability. >> >> What I argue with you until now, is the following statements: >> "when a UPA stops being advertised, that unreachability signal goes away, >> and at that point, the summary route takes over and signals reachability." >> >> From the UPA document, we can know there at least two reasons can lead the >> "UPA stops being advertised": >> Case 1: "UPA advertisements SHOULD therefore be withdrawn after some amount >> of time, that would provide sufficient time for UPA to be flooded >> network-wide and acted upon by receiving nodes, but limits the presence of >> UPA in the network." >> Case 2: " ABR or ASBR MUST withdraw the previously advertised UPA when the >> reason for which the UPA was generated was lost " >> >> Then, if the reason that lead " UPA stops being advertised " is Case 1, then >> your logic that " at that point, the summary route takes over and signals >> reachability." is wrong. >> When the BGP PIC FRR switch back at this moment, the traffic will be lost. > no. > > The draft also says: > > "The time the UPA is kept in the network SHOULD also reflect the intended > use-case for which the UPA was advertised." > > For BGP PIC, you need to keep it for a time that allows BGP to converge after > the remote PE failure. > > Peter > > >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> -----邮件原件----- >> 发件人: [email protected] >> [mailto:[email protected]] 代表 Gunter van de Velde (Nokia) >> 发送时间: 2025年5月28日 15:04 >> 收件人: Aijun Wang <[email protected]> >> 抄送: [email protected]; 'Peter Psenak' <[email protected]> >> 主题: [Lsr] Re: 答复: I-D Action: >> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >> >> [speaking as work group participant] >> >> Hi Aijun, >> >> Let’s wrap up this thread. I feel we’ve explored this topic quite thoroughly >> from different angles, and I’d prefer not to keep circling back and >> repeating the same points. >> (this is my last email on this thread) >> >> Regarding your comment: >> " >> 1) The data-plane OAM tools(BFD, ICMP, STAMP, and TWAMP) should be used to >> test and verify the prefix reachability. >> Along the evolution of PUAM/UPA drafts, there are lots of discussions >> among the efficiency of these OAM tools, versus the PUAM/UPA mechanism. >> I think you may miss these previous discussions. >> Here I want just to say, if the WG agree with you, the PUAM/UPA draft >> shouldn't be existed. >> " >> >> Let me try to explain my point again, one last time, just in a different way >> for clarity. >> >> A router forwards packets based on the unicast forwarding table, which is >> typically populated by routing protocols like OSPF or IS-IS. Once a route is >> selected, the router uses that information to forward packets, plain and >> simple. But here’s the thing: the router doesn’t really “know” if the packet >> will make it all the way to its final destination. It just follows the best >> path it has available, based on its local view. What happens downstream, >> packet drops, blackholing, filtering, or misrouting. can’t be predicted by >> the control plane alone. That’s just the reality of distributed routing. >> >> At the end of the day, if we really want to be sure something is reachable >> and working as expected, the best way to confirm that is to actually test it. >> Tools like BFD, ICMP, STAMP, and TWAMP are exactly what we use to validate >> that, since they measure actual behavior in the data plane. >> >> From your comments, it sounds like you're proposing a new control plane >> signal that says, “Hey, trust me, I’m really reachable.” But I’m not >> convinced such a signal would be any more reliable than the routes we >> already learn through established routing protocols like OSPF or IS-IS. That >> kind of new control plane signal could still be based on outdated, >> incorrect, or incomplete information, and wouldn’t really help when it comes >> to truly assessing data plane reachability. >> >> Coming back to UPA. When using UPA the procedure as described in [1], [2], >> and [3] is predictable and behaves in an operationally efficient way. That >> way, in most cases, we don’t even need to rely on OAM data plane testing >> tools. From my point of view, adding a new control plane message to somehow >> validate reachability on top of an already installed unicast route doesn’t >> really add much value. Instead, it risks introducing more complexity without >> solving a real problem. >> >> Regarding your comment: >> " >> 2) In BGP PIC FRR scenario, when the router stops receiving the UPA signal, >> and "switching back to the primary egress router" is wrong. >> As stated in your reply, stop receiving the UPA signal " ...doesn’t >> imply anything about whether the prefix is reachable ", then, when the >> prefix is still unreachable, switch back to the primary egress router >> will result in the traffic black hole. >> " >> >> GV> If the UPA disappears then the assumption is that the prefix is indeed >> reachable, assuming the prefix would be a member prefix covered by the >> summary route. See [1],[2] and [3] for the procedure. This is basic network >> behavior when using aggregate routes on ABRs. If this is not the behavior >> desired, then an alternative is to not summarize prefixes into aggregate >> prefixes (but this has other operational implications). >> >> " >> In summary, current UPA proposal try to signal the unreachability on demand, >> but lack of the signaling mechanism to revoke such announcement on demand. >> " >> >> GV> What I’m saying is pretty straightforward: when a UPA stops being >> advertised, that unreachability signal goes away, and at that point, the >> summary route takes over and signals reachability. Summary routes have been >> used in networks for years and has worked reliably. That’s why I’m having a >> hard time understanding how introducing a brand-new control plane message to >> signal destination reachability would actually help. It doesn’t really add >> anything new when it comes to confirming data plane reachability, and we >> already have mechanisms that work well in practice. >> >> Note that this was my last email on this subject as I think we now discussed >> this enough. >> >> Brgds, >> G/ >> [speaking as work group participant] >> >> [1] >> https://mailarchive.ietf.org/arch/msg/lsr/EFb71fc-hc-_oMCnksOZfSPt0-o >> / >> {2] >> https://mailarchive.ietf.org/arch/msg/lsr/aAyfU1ziWTuTltmZoCGO1vht7Qk >> / >> {3] >> https://mailarchive.ietf.org/arch/msg/lsr/hg_v2ZAOkz5bhxE4979viIowkIU >> / >> >> -----Original Message----- >> From: Aijun Wang <[email protected]> >> Sent: Wednesday, May 28, 2025 3:06 AM >> To: Gunter van de Velde (Nokia) <[email protected]> >> Cc: [email protected]; 'Peter Psenak' <[email protected]> >> 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, Gunter: >> >> There are two misunderstanding in your arguments: >> 1) The data-plane OAM tools(BFD, ICMP, STAMP, and TWAMP) should be used to >> test and verify the prefix reachability. >> Along the evolution of PUAM/UPA drafts, there are lots of discussions >> among the efficiency of these OAM tools, versus the PUAM/UPA mechanism. >> I think you may miss these previous discussions. >> Here I want just to say, if the WG agree with you, the PUAM/UPA draft >> shouldn't be existed. >> >> 2) In BGP PIC FRR scenario, when the router stops receiving the UPA signal, >> and "switching back to the primary egress router" is wrong. >> As stated in your reply, stop receiving the UPA signal " ...doesn’t >> imply anything about whether the prefix is reachable ", then, when the >> prefix is still unreachable, switch back to the primary egress router >> will result in the traffic black hole. >> >> In summary, current UPA proposal try to signal the unreachability on demand, >> but lack of the signaling mechanism to revoke such announcement on demand. >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> -----邮件原件----- >> 发件人: Gunter van de Velde (Nokia) >> [mailto:[email protected]] >> 发送时间: 2025年5月27日 17:39 >> 收件人: Aijun Wang <[email protected]> >> 抄送: [email protected]; 'Peter Psenak' <[email protected]> >> 主题: RE: [Lsr] Re: 答复: I-D Action: >> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >> >> [speaking as work group participant] >> >> A router makes its forwarding decisions based on the routes it has in the >> unicast forwarding table, which are populated by the control plane. When a >> packet comes in, the router looks up the destination, and if there’s a >> match, it uses the forwarding info tied to the best route it has at that >> moment to send the packet on its way. >> >> It is worth pointing out that the router doesn’t actually know whether the >> packet will make it all the way to the final destination. It simply follows >> the best available path based on local routing information. Along the way, >> anything from packet filtering, DDoS mitigation, or buffer drops could >> affect delivery, that’s just the nature of network behavior. >> >> If there are concerns about whether a specific destination is actually >> reachable, that’s where data-plane OAM tools come in. Things like BFD, ICMP, >> STAMP, and TWAMP are built specifically to test and verify reachability >> beyond what the control plane can determine. >> >> To clarify something mentioned earlier when I said “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,” I >> meant exactly that. It doesn’t imply anything about whether the prefix is >> reachable, it just means the system sees the UPA is gone, and so it reverts >> to whatever route is considered best in the routing table. >> >> In the case of BGP PIC FRR, that usually means switching back to the primary >> egress router, depending on how the feature is configured. Whether it >> actually switches back or sticks with the alternate path depends on the >> specific BGP PIC settings and current network state. >> >> G/ >> (speaking as WG participant) >> >> >> -----Original Message----- >> From: Aijun Wang <[email protected]> >> Sent: Tuesday, May 27, 2025 10:47 AM >> To: Gunter van de Velde (Nokia) <[email protected]> >> Cc: [email protected]; 'Peter Psenak' <[email protected]> >> 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, Gunter: >> >> Here is the tricky issue: >> "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." >> >> Then, you assumes that: when no UPA is advertised, the specific prefix is >> reachable again? >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> -----邮件原件----- >> 发件人: Gunter van de Velde (Nokia) >> [mailto:[email protected]] >> 发送时间: 2025年5月27日 16:17 >> 收件人: Aijun Wang <[email protected]> >> 抄送: [email protected]; Peter Psenak <[email protected]> >> 主题: RE: [Lsr] Re: 答复: I-D Action: >> draft-ietf-lsr-igp-ureach-prefix-announce-06.txt >> >> [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-an >> n >> oucement/ [3] >> https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-ann >> o >> unce/ [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 <[email protected]> >> Sent: Tuesday, May 27, 2025 1:05 AM >> To: Peter Psenak <[email protected]> >> Cc: [email protected] >> 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:[email protected]> 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:[email protected]] >> 发送时间: 2025年5月26日 15:41 >> 收件人: Aijun Wang mailto:[email protected] >> 抄送: mailto:[email protected] >> 主题: 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:[email protected]] >> 发送时间: 2025年5月23日 19:11 >> 收件人: Aijun Wang mailto:[email protected] >> 抄送: mailto:[email protected] >> 主题: 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:[email protected] 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:[email protected] >> [mailto:[email protected]] 代表 Peter Psenak >> 发送时间: 2025年5月23日 14:55 >> 收件人: Aijun Wang mailto:[email protected]; mailto:[email protected] >> 主题: [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-up >> a >> -proposal/ >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> >> >> >> >> -----邮件原件----- >> 发件人: mailto:[email protected] >> [mailto:[email protected]] 代表 >> mailto:[email protected] >> 发送时间: 2025年5月22日 21:20 >> 收件人: mailto:[email protected] >> 抄送: mailto:[email protected] >> 主题: [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-ann >> o >> unce/ >> >> There is also an HTMLized version available at: >> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefi >> x >> -announce-06 >> >> A diff from the previous version is available at: >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-ureach-p >> r >> efix-announce-06 >> >> Internet-Drafts are also available by rsync at: >> rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> Lsr mailing list -- mailto:[email protected] To unsubscribe send an email >> to mailto:[email protected] >> >> >> _______________________________________________ >> Lsr mailing list -- mailto:[email protected] To unsubscribe send an email >> to mailto:[email protected] >> >> >> >> _______________________________________________ >> Lsr mailing list -- mailto:[email protected] To unsubscribe send an email >> to mailto:[email protected] >> >> >> _______________________________________________ >> Lsr mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
