Hi, Roman: Thanks for the detail responses for the appeal!
I read it also carefully and have the following responses: 1) For technical issue(a), the main point for the argument is that current description in [1] is contradict with the base document RFC 2328: "Else, if the routing table cost equals or exceeds the value LSInfinity, a summary-LSA cannot be generated for this route." You referred only the author's responses, which is just some assertion, no reasoning----If one new document wants to overturn the principle in base document, should it consider carefully the possibilities or potential influences? 2) For technical Issue (b), the protocol constant for the prefixes is one dormant feature that is almost no deployment in the network. The proposal just want to open the jar of the confusion. 3) For technical Issue (c), your response: "The document does not say that withdrawal of an UPA announcement indicates reachability.", then, there is no explicit UPA withdrawn signal, right? Doesn't it mean my appeal "No explicit UPA withdrawn signal" stands? In conclusion, I admire the process of the IETF standard activities, but the trends, that, the experts from the vendors dominate the outputs of the documents, based solely on the various possible implementations, not the possibilities of their deployments, and consideration of the challenges in large scale network, should be changed. Or else, these RFCs can only be shelved in the IETF repository, not in the operator's network. And, as you said, the process is not end, I would like to discuss with the coming ADs' review for this document. Expect the ADs can have their independent, fresh judgements on the above issues, not burdened with the past discussions. Best Regards Aijun Wang China Telecom [1] https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-09#section-4.1 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of IETF Chair Sent: Tuesday, September 9, 2025 4:50 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: [Lsr] Re: Appeal to the forwarding of draft-ietf-lsr-igp-ureach-prefix-announce Hi Aijun! A response to your appeal from the IESG has been posted at https://datatracker.ietf.org/group/iesg/appeals/artifact/145. Regards, Roman Danyliw (as Chair, for the IESG) -----Original Message----- From: IETF Chair <[email protected]> Sent: Thursday, June 26, 2025 12:02 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: [Lsr] Re: Appeal to the forwarding of draft-ietf-lsr-igp-ureach-prefix-announce Hi Aijun! (With some delay) I wanted to acknowledge receipt of your appeal. It was posted at https://datatracker.ietf.org/group/iesg/appeals/artifact/138 last week. Regards, Roman Danyliw (as Chair, for the IESG) From: Aijun Wang <[email protected]> Sent: Tuesday, June 17, 2025 4:02 AM To: 'The IESG' <[email protected]> Cc: 'lsr' <[email protected]>; 'rtg-ads' <[email protected]> Subject: Appeal to the forwarding of draft-ietf-lsr-igp-ureach-prefix-announce Hi, IESG: Again, the LSR WG tries to forward one problematic document. I am contacting you to formally appeal the forwarding of this document (I am cc'ing the LSR WG/Routing ADs for the sake of transparency and openness). • Appellants: Aijun Wang mailto:[email protected] • Description of the Disputes Draft [1] passed the WGLC, with the unsolved deficiency designs. I have summarized the remaining issues in document [2], which describes in detail the following aspects: a) The proposal doesn’t work even in simple scenario.(section 2 of [2]) b) The proposal is based on one flawed feature(section 3 of [2]) c) No explicit UPA withdrawn signal(section 4 of [2]) The related discussions for the above issues are here: Issue a), the author admits they needs to update the corresponding RFCs(although no any description to propose how to update), but it is still problematic. [3] Issue b), the author hasn’t answered the controversy scenario clearly until now [4] Issue c), current proposal can’t distinguish the two cases that lead to the end of UPA advertisement. [5] The responses from our AD [6], make some progress----I removed the unimportant issues in this appeal to IESG---but doesn’t address the above technical issues This is another example, that the proposal is implementable but can’t be deployed in operator’s network. • Requested Actions 1) Please let the authors, or any other experts that support to forward this document answer the above three issues. 2) If they can’t be solved, please abandon this document[1]. 3) It is necessary to let the experts from the operators, to add/update the administration of the LSR WG, to gauge and raise the bar of the document output from the LSR WG. [1]: https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/ [2]: https://datatracker.ietf.org/doc/draft-wang-lsr-reasons-of-abandon-upa-proposal/ [3]: Even updating the related RFC, the problem can’t be solved: https://mailarchive.ietf.org/arch/msg/lsr/v_RbVRf5sXwqhYnik2Kmr_5qu_8/ [4]: LSInfinity feature within OSPF is flawed: https://mailarchive.ietf.org/arch/msg/lsr/C0_vMZmk0e9uzEWayRYiIakQXtc/ [5]: Explicit Withdrawn is necessary: https://mailarchive.ietf.org/arch/msg/lsr/Ztpgb_DMYi2hwjDi4DxFfG1kbx4/ [6]: AD’s responses doesn’t address the remaining technical issues: https://mailarchive.ietf.org/arch/msg/lsr/WnRKUKOFIKP4tuHc3mORqLLs-KU/ Best Regards Aijun Wang China Telecom _______________________________________________ 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]
