Acee, As co-chair, your statement "Aijun is the only one here exhibiting unprofessional behavior here in LSR." does not help to resolve the conflict in the working group. I present my perspective from a third party not involved. I read Aijun's reason to object the lc, the section 1: Decent IETF Behaviors. And I read Yingzhen's pointer to the history. https://mailarchive.ietf.org/arch/msg/lsr/P6nKRoztoxsq9ognWGc14ocELGY/ I see John Scudder said: " For this reason, I was a little surprised to see no acknowledgment of the contributions of your draft in draft-ppsenak." So I believe the authors are not professional.
Tianran -----邮件原件----- 发件人: Acee Lindem <[email protected]> 发送时间: 2025年5月5日 19:14 收件人: Tianran Zhou <[email protected]> 抄送: Yingzhen Qu <[email protected]>; Aijun Wang <[email protected]>; Peter Psenak <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]> 主题: Re: [Lsr] WG Last Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025) Speaking as Co-chair: Tianran, > On May 4, 2025, at 10:33 PM, Tianran Zhou > <[email protected]> wrote: > > Hi WG, > > I object to progress this draft. > I do not know the history. Just looking at the pointer to John's comment. He > has pointed out the unprofessional behavior by the authors. But I do not > agree with his decision. John who? Please provide an Email reference here. > We should not encourage this kind of unprofessional behavior in IETF. Aijun is the only one here exhibiting unprofessional behavior here in LSR. > I am with Aijun on this. You should actually read the drafts and the Email threads before commenting. Thanks, Acee > > Cheers, > Tianran > > > > > > Sent from WeLink > > 发件人：Yingzhen Qu <[email protected]> > 收件人：Aijun Wang <[email protected]> > 抄 送：Peter Psenak <[email protected]>;lsr <[email protected]>;lsr-chairs > <[email protected]> > 时 间：2025-04-25 00:04:50 > 主 题：[Lsr] Re: 答复: Re: WG Last Call for > draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025) > > Hi Aijun and all, > > A reminder that there was long discussion during the adoption call of > draft-ietf-lsr-igp-ureach-prefix-announce, especially whether there > was consensus for the adoption and the relationship to > https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-ann > oucement/. You can find the adoption call thread here: > https://mailarchive.ietf.org/arch/msg/lsr/Tyo0-puL8In1Swj-mYdtj0gc1qw/ > , and John's (responsible AD at the time) response: > https://mailarchive.ietf.org/arch/msg/lsr/P6nKRoztoxsq9ognWGc14ocELGY/ > > For this WGLC, please focus on the technical discussion of > draft-ietf-lsr-igp-ureach-prefix-announce and refrain from repeating what had > already been discussed. > > Thanks, > Yingzhen (LSR-CoChair) > > On Thu, Apr 24, 2025 at 7:58 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. > > 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”? > > 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]> 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]] 代表 Aijun Wang >>> 发送时间: 2025年4月22日 0:12 >>> 收件人: Yingzhen Qu <[email protected]> >>> 抄送: lsr <[email protected]>; lsr-chairs <[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]> 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-an >>> nounce/ >>> >>> 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] >>> To unsubscribe send an email to [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] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
