Hi Peter, Thank you for this information. I didn't know. Maybe this is at your background. In this case, I withdraw my conclusion, I don't support his point on IETF behavior.
Tianran ________________________________ Sent from WeLink 发件人：Peter Psenak <[email protected]<mailto:[email protected]>> 收件人：Tianran Zhou <[email protected]<mailto:[email protected]>>;Acee Lindem <[email protected]<mailto:[email protected]>> 抄 送：Yingzhen Qu <[email protected]<mailto:[email protected]>>;Aijun Wang <[email protected]<mailto:[email protected]>>;lsr <[email protected]<mailto:[email protected]>>;lsr-chairs <[email protected]<mailto:[email protected]>> 时 间：2025-05-05 20:58:32 主 题：Re: [Lsr] WG Last Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025) Tianran , On 05/05/2025 14:41, Tianran Zhou wrote: > 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." we offered Aijun co-authorship several times, but he insisted to push his own draft and solution. Peter > 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]
