Hi, Gunter: Your example is not the Case 1 that I want to express. I explored it in detail based on your example inline below. Wish we can understand each other better and discuss further after that.
And, regarding to my previous statement of "it will be registered for further clarification", the real intention is that, if such issues can't be solved, it will be registered in [1] for further discussions. [1]: https://datatracker.ietf.org/doc/draft-wang-lsr-reasons-of-abandon-upa-proposal/ Best Regards Aijun Wang China Telecom -----Original Message----- From: Gunter van de Velde (Nokia) [mailto:[email protected]] Sent: Wednesday, May 28, 2025 6:41 PM To: Aijun Wang <[email protected]>; 'Peter Psenak' <[email protected]> Cc: [email protected] Subject: RE: 答复: 答复: 答复: [Lsr] Re: 答复: I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt [speaking as work group participant] I'm not quite sure what you meant by the comment “Or else, it will be registered for further clarification.” Could you clarify that a bit? It came across a little strongly, almost like a threat? I'm sure that wasn’t the intent, but I wanted to double-check. Now, shifting gears back to the technical discussion, specifically the “case 1” scenario. I think it helps if we step back and walk through the flow of events in the network. Let’s take a simple example: R1 ----- area 1 ----- ABR ----- area 0 ----- R2 (20.20.20.2/32), R3 (20.20.20.3/32), R4 (20.20.20.4/32) In normal operation: * R2 advertises 20.20.20.2/32, R3 advertises 20.20.20.3/32, and R4 advertises 20.20.20.4/32. * The ABR summarizes these into area 1 as a single route: 20.20.20.0/24. * There’s a BGP session between R1 and R2, exchanging BGP routes. * So, if R1 gets a packet destined for behind R2, it follows the BGP route via R2. Now, say R2 suddenly fails: * The ABR detects that 20.20.20.2/32 is no longer in area 0. * The ABR originates a UPA for 20.20.20.2/32 into area 1. * R1 receives this UPA and realizes that the prefix is now unreachable. * R1 triggers BGP PIC FRR and switches to a backup BGP egress router. * R1 keeps using this backup path for as long as the ABR continues to advertise the UPA. [WAJ] If the ABR stop advertising the UPA, will R1 still use this backup path? Please note, 20.20.20.2/32 may still be unreachable in such moment, even the ABR has advertised the UPA enough time for R1 accomplished BGP PIC FRR switchover. Let’s take a moment to look at what happens behind the scenes: 1. Initially, there’s an active BGP session between R1 and R2. 2. When R2 fails, this session will eventually go down after the hold timer expires. 3. When that happens, R1 withdraws all BGP prefixes it learned from R2. 4. At this point, R2 is no longer considered a BGP next-hop. 5. The backup BGP egress router becomes the new primary. 6. This is just normal BGP convergence behavior. [WAJ] This is well known process of BGP protocol How long this process takes depends on how BGP timers are configured. And that leads us back to the statement in the UPA draft: “The time the UPA is kept in the network SHOULD also reflect the intended use-case for which the UPA was advertised.” In other words, the ABR should keep advertising the UPA long enough for R1 to complete BGP convergence, so that R1 can fully withdraw routes received from R2 and that R1 has no BGP route anymore with R2 as next-hop. [WAJ] I know this point well because we have described such behavior far before the UPA proposal. Once that’s done, the ABR can safely withdraw the UPA, and the network remains stable (i.e. from R1 perspective the backup egress router became the new primary egress router once BGP converged because session with R2 failed). [WAJ] Then, R1 will keep using the backup egress router forever? When, how and what trigger the R1 switchback to the original egress router? To come back to your point, this also means that when the ABR would stop advertising the UPA before R1 completed the R1-R2 BGP convergence procedure that undesired forwarding happens. This would be a configuration error and should be avoided. This is exactly what the statement "The time the UPA is kept in the network SHOULD also reflect the intended use-case for which the UPA was advertised.” Is explaining. [WAJ] I am not arguing with you this "configuration error". Best regards, G/ [speaking as work group participant] -----Original Message----- From: Aijun Wang <[email protected]> Sent: Wednesday, May 28, 2025 10:58 AM To: 'Peter Psenak' <[email protected]>; Gunter van de Velde (Nokia) <[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. Your previous responses at here https://mailarchive.ietf.org/arch/msg/lsr/EFb71fc-hc-_oMCnksOZfSPt0-o/ is also for Case 2. Where your responses for Case 1? Please give the link. Or else, it will be registered for further clarification. -----邮件原件----- 发件人: Peter Psenak [mailto:[email protected]] 发送时间: 2025年5月28日 16:48 收件人: 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:46, Aijun Wang wrote: > OK, you say Gunter talk about the Case 2. It's no problem. > > Then, what's your considerations of Case 1? I have already responded to that. I'm done with this thread. Peter > > -----邮件原件----- > 发件人: 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/aAyfU1ziWTuTltmZoCGO1vht7Q >>> k >>> / >>> {3] >>> https://mailarchive.ietf.org/arch/msg/lsr/hg_v2ZAOkz5bhxE4979viIowkI >>> U >>> / >>> >>> -----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/S7Mqk2JljYgG8kjEPmH6KlLtbf >>> w >>> / >>> [2] >>> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-a >>> n >>> n >>> oucement/ [3] >>> https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-an >>> n >>> 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-u >>> p >>> 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-an >>> n >>> o >>> unce/ >>> >>> There is also an HTMLized version available at: >>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-pref >>> i >>> 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]
