Speaking as WG member: > On Apr 24, 2025, at 7:57 AM, Aijun Wang <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 >>> >>> 发件人: [email protected] <mailto:[email protected]> >>> [mailto:[email protected]] 代表 Aijun Wang >>> 发送时间: 2025年4月22日 0:12 >>> 收件人: Yingzhen Qu <[email protected]> <mailto:[email protected]> >>> 抄送: lsr <[email protected]> <mailto:[email protected]>; lsr-chairs >>> <[email protected]> <mailto:[email protected]> >>> 主题: [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 <[email protected] >>> <mailto:[email protected]>> 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 -- [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]
