[Lsr] Re: WG Last Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025)

Thu, 24 Apr 2025 13:42:09 -0700

Hi, Acee:

Firstly, you have some stubborn prejudices—-what I call the copycat behavior was the description of the configuration control at the ABRs for the announcement of prefix unreachable announcements—-I have given the evidence(section link) of such behavior.

If you call “it’s certainly isn’t a novel concept”, please give the original idea link that before us. 

After it is described after our initial statement, it is not a novel concept.

Even for this novel concept, the WGLC document gives only the partial solution, there is also other configuration knob you can learn from the Founder Draft[1]

I can give you also another copycat behavior of the WGLC document——the partition issue—-which is also first discussed at the Founder Draft. The WGLC document mentions the issue, but failed to give the correct solution, because there is no other alternative way, other than the knob described in the Founder Draft.

Secondly, if you think the section 2.1 describes already the backward compatibility of the solution, why define the U flag again in the “Prefix Attributes Flag” sub-TLV, which is obviously not backwards compatibility?

And to Yingzhen, I am not arguing the past WG adoption process, I am arguing that current WGLC document doesn’t meet the threshold to pass the WGLC——there are still several unsolved challenges, similar with the MP-TLV document, should be addressed before forwarding it.

I have given the Technical Analysis list in previous mail.



Aijun Wang
China Telecom

On Apr 25, 2025, at 01:20, Acee Lindem <acee.i...@gmail.com> wrote:

Speaking as WG member: 

On Apr 24, 2025, at 7:57 AM, Aijun Wang <wangai...@tsinghua.org.cn> wrote:

Hi, Peter:

I noticed you omitted the responses to the Technical Analysis, please answer them.

Regarding to your response to the “Decent IETF Behavior”, please response the item 2), which describes the copycat behavior.
Or, please remove these descriptions in your document.

Specifically what are you claiming ownership of here? Configuration of prefixes to protect -
This certainly isn’t a novel concept. The application of signaling unreachability without
modifying the RIB/FIB directly was discussed on the list prior to you saying 
you could do that too in your draft. So, perhaps you’re looking in the wrong place for
copycats.




And, in this WGLC document, it depends on the newly defined “Prefix Attributes Sub-TLV”, which is obviously not supported by existing router, then why can you call it is “fully backward compatible”?

See section 2.1, first paragraph. 

Thanks,
Acee





For the adoption of this document, I have appealed to the AD, but am finally reluctant to accept the WG decision——I expected it will be refined until the time of WGLC.

But, until now, there is no any improvement on this document. It is still one partial, confusing, incomplete, derived, non-efficient solution.

Again, please response the previous Technical Analysis.

Aijun Wang
China Telecom

On Apr 24, 2025, at 16:29, Peter Psenak <ppse...@cisco.com> wrote:


On 23/04/2025 11:18, Aijun Wang wrote:
Hi, All:
 
I read carefully again the WGLC draft, and OBJECT strongly for its forwarding.
The reasons are the followings:
 
Section I:  Decent IETF Behaviors
1)    The scenario, initial solution and intense discussions are described, initiated, organized by the authors of https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-00 (From October 2019), there is no any mentions in this document for these experts’ efforts. This is not the decent behavior within IETF.
2)    The idea of https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-04#section-4 is first describe in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7(March, 2021), ONE YEAR Earlier than the initial draft of the WGLC document.(https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-00) (March, 2022).  This is another non-decent behavior within IETF. 

I find above claims to be false and rather aggressive. 

As a response to the accusations above I'm sending the historical summary of how things evolved over time the time. Thanks to Les for remembering and collecting some of these facts.

I'm not planing to participate in any further discussion on this matter.


The Prefix Unreachable Advertisement Draft(PUA) https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ was first published in October of 2019.Significant discussion of the merits of the draft continued over the next few years - both on and off the WG list.

It was pointed out to the authors that the proposed solution was problematic - not least because it depended on a non-backwards compatible advertisement (using a source router-id of 0.0.0.0 in prefix reachability advertisements).

Although various modifications were made to the draft over the years, the core mechanism of the solution was never changed.

Over the years, customer interest in a solution to this problem increased. In March of 2022 an alternative solution to the problem - the Unreachable Prefix Advertisement Draft (UPA) https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/ was published.

It uses a fully backwards compatible advertisement - sending prefix reachability with a metric value already defined in existing RFCs are meaning "do not consider this prefix in SPFs".

The authors of the PUA draft, who rightfully deserve credit for first bringing this problem to the attention of the WG, were invited to join as co-authors on the UPA draft, but they declined and continued to promote the PUA solution.

WG presentations for both drafts were made at IETF 114:

https://datatracker.ietf.org/meeting/114/materials/slides-114-lsr-08-prefix-unreachable-announcement-00

https://datatracker.ietf.org/meeting/114/materials/slides-114-lsr-07-upa-00

In September of 2023 the UPA draft was adopted as a WG document - indicating that the consensus of the WG favored the  UPA solution (backwards compatible) over the PUA solution (not-backwards compatible).

Since then, implementations of the UPA draft have been written and successfully deployed.

In April of 2025 WG Last Call has been initiated on the UPA draft.

thanks,
Peter



 
Section II: Technical Analysis
1)    The WGLC provide two methods to label the unreachable prefixes, one depends on LSInifinity setting of the advertised prefix, the other depends on the newly defined flag. 
They are redundancy and confusion. The meaning of LSinifinity is already defined in the existing documents, and there is no necessary to rephrase them. The solution needs only depend on one method.
 
2)    For the usage of LSInifinity, although RFC 2328 and RFC 5305 defines its possible usage, if they are used in such way(I have not heard any operator deploy such mechanics), their deployment should be gradually disappearing, not enhance instead. There are three reasons for such considerations:
a)     The maximum metric value is often treated as the last resort of reachability, not the unreachability.  It will lead more confusions for the setting of such metric in the network.
b)     It states clearly in the RFC 2328 section 14.1, that  “Premature aging can also be used when, for example, one of the router's previously advertised external routes is no longer reachable. In this circumstance, the router can flush its AS- external-LSA from the routing domain via premature aging. This procedure is preferable to the alternative, which is to originate a new LSA for the destination specifying a metric of LSInfinity."
c)     During the SPF calculation, the final cost is the summary of every segment cost. It is possible that the final cost exceed also the LSinfinity, but the prefix is reachable.
 
3)    For the Signaling Method, it defines the additional flags based one newly defined sub-TLV for OSPF, and existing sub-TLV for IS-IS. 
Far complex than the usage of “Prefix Originator” directly.  The document just want to make some differences, not the efficiency.
 
4)       The WGLC document doesn’t solve the area/domain partition scenaro, which may appear in the network, and is already covered by https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ (let’s call it Founder Document).  It states, “UPA does not make the problem of an area partition any worse. ”-----Actually, it does worse----If one ABR can’t reach the egress router(PE1), but another ABR can reach, there should be no switchover of the egress router(PE2), which may be reachable, or may be unreachable.-----There should be some coordinate mechanism among the ABRs, as that described in the above Founder Document.
 
5)    There is no any consideration for the balance of reachable information and unreachable information announcements. It will be disaster in some critical condition.
 
 
Best Regards
 
Aijun Wang
China Telecom
 
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Aijun Wang
发送时间: 2025年4月22日 0:12
收件人: Yingzhen Qu <yingzhen.i...@gmail.com>
抄送: lsr <lsr@ietf.org>; lsr-chairs <lsr-cha...@ietf.org>
主题: [Lsr] Re: WG Last Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025)
 
I object its forwarding, from the beginning of its WG adoption.
 
 
Aijun Wang
China Telecom


On Apr 18, 2025, at 02:13, Yingzhen Qu <yingzhen.i...@gmail.com> wrote:

Hi,
 
This email begins a 2 week WG Last Call for the following draft:
IGP Unreachable Prefix Announcement
https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/
 
Please review the document and indicate your support or objections by May 2nd, 2025.
 
Authors and contributors,
Please indicate to the list your knowledge of any IPR related to this work.
 
Thanks,
Yingzhen
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org


_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org

Reply via email to