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 <[email protected]>
*抄送:*[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 <[email protected]>
<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
*发件人:*[email protected]
<mailto:[email protected]>[mailto:[email protected]
<mailto:[email protected]>] *代表 *Peter Psenak
*发送时间:*2025年5月23日14:55
*收件人:*Aijun Wang <[email protected]>
<mailto:[email protected]>; [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-upa-proposal/
Best Regards
Aijun Wang
China Telecom
-----邮件原件-----
发件人: [email protected]
[mailto:[email protected]
<mailto:[email protected]>] 代表
[email protected]
发送时间: 2025年5月22日21:20
收件人: [email protected]
抄送: [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-announce/
<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
<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
<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 -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
Lsr mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
