On 30/05/2025 11:33, Peter Psenak wrote:
On 30/05/2025 11:24, Aijun Wang wrote:
Hi, Peter:
*From:*forwardingalgori...@ietf.org
[mailto:forwardingalgori...@ietf.org] *On Behalf Of *Peter Psenak
*Sent:* Friday, May 30, 2025 4:08 PM
*To:* Aijun Wang <wangai...@tsinghua.org.cn>; 'Robert Raszuk'
<rob...@raszuk.net>
*Cc:* 'Gunter van de Velde' <gunter.van_de_ve...@nokia.com>; lsr@ietf.org
*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.”
That does not mean the LSA is ignored during the processing. It means
the prefix in the LSA becomes reachable.
correction, the last word in the above sentence should be "unreachable".
If it was reachable before, it must me made unreachable and removed
from the forwarding. If we follow the logic that you trying to impose
you would never be able to make a reachable prefix unreachbale,
because you would ignore the LSA that is trying to make it unreachable.
Same applies when the LSA was advertised with the LSInfinity and that
LSA is removed (e.g. MaxAged) - that means that the unreachability
that was advertised previously is not announced anymore.
I'm done with this thread now.
Peter
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:*forwardingalgori...@ietf.org
[mailto:forwardingalgori...@ietf.org
<mailto:forwardingalgori...@ietf.org>] *On Behalf Of *Robert Raszuk
*Sent:* Friday, May 30, 2025 7:18 AM
*To:* Aijun Wang <wangai...@tsinghua.org.cn>
<mailto:wangai...@tsinghua.org.cn>
*Cc:* Gunter van de Velde <gunter.van_de_ve...@nokia.com>
<mailto:gunter.van_de_ve...@nokia.com>; Peter Psenak
<ppse...@cisco.com> <mailto:ppse...@cisco.com>; lsr@ietf.org
*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
<wangai...@tsinghua.org.cn> 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
<rob...@raszuk.net> 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 -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
