Hi, Peter:
From: [email protected] [mailto:[email protected]] On Behalf Of Peter Psenak Sent: Friday, May 30, 2025 4:08 PM To: Aijun Wang <[email protected]>; 'Robert Raszuk' <[email protected]> Cc: 'Gunter van de Velde' <[email protected]>; [email protected] Subject: [Lsr] Re: 答复: 答复: 答复: Re: 答复: I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt On 30/05/2025 02:46, Aijun Wang wrote: Hi, Robert: Yes, in link state protocols, when the LSP/LSA is updated, the SPF will run again, the node will recalculate the RIB, and exclude the missing prefixes. But for UPA, the situation is different: 1. The LSP/LSA that include UPA doesn’t participate the SPF calculation. that is not correct. They are processed during the SPF and they have a special meaning defined by the protocol specification - e.g. they represent unreachability. [WAJ]: Please see RFC 2328. “If the cost specified by the LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the the next LSA.” 2. There are at least two reasons that can lead UPA disappearing [1], which is to say, the missing of UPA doesn’t represent the specific prefix is reachable again. UPA explicitly signals unreachability of the prefix that is covered by the summary prefix reachability advertisement. UPA withdrawal removes the explicitly signaled unreachability of the prefix, making it reachable by the summary prefix reachability advertisement. [WAJ]: Please see the example that described by Gunter and my responses: https://mailarchive.ietf.org/arch/msg/lsr/HnRhGkekX7aDRLxIAZ0Qim1dufI/ In the example, when ABR stops advertising UPA after the configured time(to let R1 finish the BGP PIC FRR process), 20.20.20.2/32 is still unreachable. The summary address 20.20.20.0/24 from ABR gives still the wrong information. Peter Then, for UPA, the explicit withdraw procedure, which indicates the specific prefix is back again, is necessary. [1]: https://mailarchive.ietf.org/arch/msg/lsr/s1I2Fj7kcYm85CwwYBURYL8RPQE/ Best Regards Aijun Wang China Telecom From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Friday, May 30, 2025 7:18 AM To: Aijun Wang <mailto:[email protected]> <[email protected]> Cc: Gunter van de Velde <mailto:[email protected]> <[email protected]>; Peter Psenak <mailto:[email protected]> <[email protected]>; [email protected] <mailto:[email protected]> Subject: [Lsr] Re: 答复: 答复: 答复: Re: 答复: I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-06.txt Hi Aijun, > How to revoke the UPA explicitly when the prefix is reachable again? In link state protocols when LSP/LSA is readvertised without UPA that is equivalent to withdrawing it - but I think Peter already indicated that at least twice here. > Please note “stopping sending UPA” is not equal to “revoking the UPA”. > For example, in BGP, when you want to revoke some prefixes, you will > advertise explicitly “withdrawn” prefixes , not just stopping sending the > related BGP Updates. Yes it is very different in distance vector protocols ... I don't think LSR can't help with that :( Thx, R. On Fri, May 30, 2025 at 1:09 AM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Robert: We are discussing how and when to back to the normal state before UPA is triggered, not how to configure BGP active/backup via Local_Pref Attribute. Or, let’s change the statement in more general manner: How to revoke the UPA explicitly when the prefix is reachable again? Please note “stopping sending UPA” is not equal to “revoking the UPA”. For example, in BGP, when you want to revoke some prefixes, you will advertise explicitly “withdrawn” prefixes , not just stopping sending the related BGP Updates. Aijun Wang China Telecom On May 29, 2025, at 18:33, Robert Raszuk <[email protected] <mailto:[email protected]> > wrote: 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? Even without UPA at all in the picture if operators chooses active/backup scheme (as opposed to active/active model) for multihomed sites or networks typically BGP paths carry properly set LOCAL_PREF attribute. UPA does not have anything to do with it. Thx, R.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
