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-ann
oucement/ [3]
https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-anno
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-upa
-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-anno
unce/
There is also an HTMLized version available at:
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-pr
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]
