Aijun,
On 09/05/2025 15:22, Aijun Wang wrote:
Hi, Peter:
UPA doesn’t influence the results of the prefixes that are set to be
the LSInfinity at its originator, but it influences the results of the
prefixes whose metrics are lower than LSInfinity.
no UPA does not affect prefixes that are advertised with valid metric.
I have show you the example in the previous mail—-For example, in
https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/47864-ospfdb5.html
, when prefix 4.0.0.0/8 reaches to the ABR, it is reachable(prefix
cost is 0xffffff-0x40, lower than LSInfinity).
But after the ABR advertise the prefix in area 1 with the Summary LSA,
its metric will be LSInfinity.
According to the UPA rule, or RFC 2328, every router(includes the
final receiver) within the area 1 will treat this prefix as
unreachable, which is NOT right.
If the prefix metric is LSInfinity, the prefix is unreachable. UPA does
not change any of that.
It’s time to fix RFC2328/RFC5305/RFC5308.
I don't think so.
Let’s do this together before forwarding the UPA draft?
no, we are not going to modify the LSInfinity in any way inside or
outside of the UPA.
I'm done with this discussion now.
Regards,
Peter
Aijun Wang
China Telecom
On May 9, 2025, at 18:04, Peter Psenak <[email protected]> wrote:
Aijun,
the problem you have described below has no relevance to the UPA. In
the UPA case we are deliberately originating the prefix with the
unreachable metric, so adding anything to it at ABR is not going to
make any difference, it will stay as unreachable.
As I have replied to you many times the meaning of the LSInfinity was
defined in the base protocol specification and we are not altering it
in any way. We are using it the way it was defined.
Regards, Peter
On 09/05/2025 10:55, Aijun Wang wrote:
Hi, Peter:
I noticed the updated draft includes the new contributors to respect their
previous efforts, this should be encouraged within IETF.
But, I must point out that, the direction that Reusing the LSInfinity to
advertise the unreachable information should be discarded.
The LSInfinity feature that is defined in RFC 2328 is FLAWED, we should try to
fix it, not exploit it again.
Let's give you the simple example, that described in "OSPF Inter-Area Routing"
[1]
This is one 20 years ago article, it states clearly that when ABR do the
summary action, it will add the cost of the prefix itself and the cost of the
path between the prefix originator and the ABR together, as the newly cost of
the summary LSA for the prefix:
In the example, the original cost of 4.0.0.0/8 is 10, the link cost between Router
1.1.1.1 and Router 2.2.2.2 is 64, the ABR(router 2.2.2.2) will advertise the summary LSA
for 4.0.0.0/8 to Area 1, with the cost set to 10+64=74 (please see the output of
"r2.2.2.2#show ip ospf database summary 4.0.0.0")
Then coming the question(let's take the same example):
If the cost of prefix 4.0.0.0/8 is set to 0xffffff-0x40(64), on ABR(router
2.2.2.2), the cost of summary LSA for prefix 4.0.0.0/8 will reach 0xfffff.
If the ABR(router 2.2.2.2) follow the guideline of RFC 2328, the prefix
4.0.0.0/8 will be unreachable, and will be not advertised to area 1, router in
area 1 can't reach the 4.0.0.0/8.
But actually, 4.0.0.0/8 is reachable via the ABR(router 2.2.2.2).
If we consider there may be several hops between the prefix originator and the
ABR, then the cost of the prefix can't exceed 【0xffffff-(several
hops)*(possible link metric)】, which will be varied with different network
topology, and can't be considered as one universal value, even a definite range.
Then, such flaw in OSPF 2328, and also the similar mechanism in RFC
5305/RFC5308 for IS-IS should be fixed.
The reason that there is no emerged network outrage in these years is that the
operator configure seldom the cost of the prefix directly.
But if we expand the LSInfinity feature as described in this WG document, more
chaos, and network outrages will be emerged.
Let's stop forwarding to this direction.
[1]:https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/47864-ospfdb5.html
Best Regards
Aijun Wang
China Telecom
-----邮件原件-----
发件人:[email protected] [mailto:[email protected]]
代表[email protected]
发送时间: 2025年5月9日 2:21
收件人:[email protected]
抄送:[email protected]
主题: [Lsr] I-D Action: draft-ietf-lsr-igp-ureach-prefix-announce-05.txt
Internet-Draft draft-ietf-lsr-igp-ureach-prefix-announce-05.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-05.txt
Pages: 15
Dates: 2025-05-08
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/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-05
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-ureach-prefix-announce-05
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
Lsr mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
Lsr mailing list [email protected]
To unsubscribe send an email [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]
