Hi Aijun, On Wed, Jun 11, 2025 at 4:57 AM Aijun Wang <[email protected]> wrote: > Hi, Donald: > > Based on your explanation, then everyone in the IETF can copycat other's idea?
I am not a lawyer and don't want to try to go into details of copyright and patents but, yes, if someone has submitted a Contribution to an IETF standards effort under the usual IETF provisions then the ideas, words, diagrams, expressions, etc., in that Contribution can be used in other Contributions to IETF standards efforts by other persons. (They cannot, in general, "copy" things for purposes other than the IETF standards effort.) If the amount "copied" is significant, then I would say that the original contributor should be acknowledged (unless the do not want to be acknowledged). Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] > Best Regards > > Aijun Wang > China Telecom > > > -----Original Message----- > From: Donald Eastlake [mailto:[email protected]] > Sent: Wednesday, June 11, 2025 12:23 PM > To: Aijun Wang <[email protected]> > Cc: James Guichard <[email protected]>; lsr <[email protected]>; > lsr-chairs <[email protected]>; rtg-ads <[email protected]> > Subject: Re: [Lsr] Re: Appeal for the WGLC of UPA draft 答复: Re: WG Last Call > for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025) > > On Tue, Jun 10, 2025 at 10:45 PM Aijun Wang <[email protected]> wrote: > > Hi, Jim: > > > > Thanks for your pointer to the BCP 78(RFC 5378) “Rights Contributors > > Provide to the IETF Trust)”. > > > > I have reviewed carefully this document, and it states clearly: > > “The right to produce derivative works must be granted in order for an IETF > > working group to accept a Contribution as a working group document or > > otherwise work on it.” > > This sentence is from Section 3 of RFC 5378 which provides motivation for > other sections of RFC 5378. > > > Obviously, this WGLC document violates the rules. If it isn’t prohibited, > > how can the IETF prevent such copycat behavior in future? > > No. RFC 5378 / BCP 78 includes giving the right to produce derivative works > as specified in Section 5.3, point c. The draft being last called as well as > your draft-wang-lsr-prefix-unreachable-annoucement > specifically say they conform to BCP 78 and therefore the posting of those > drafts grants the right to produce derivative works as provided in RFC 5378. > While there can be special types of documents with a lesser grant of rights, > with regard to standards track documents, it is a goal of the IETF to enable > production of derivative works as part of the IETF standards development > process, not to prohibit such production. > > Donald > > > Regarding to your technical arguments responses: > > > > 1) Your referred mail discussion [2] is not relevant to the questions > > that I raised in > > https://datatracker.ietf.org/doc/html/draft-wang-lsr-reasons-of-abandon-upa-proposal-02#name-lsinfinity-feature-is-flawe. > > > > 2) The question raised in [2] is one NEW example that can prove current > > UPA don’t work. > > > > 3) I have once expected that you could have some distinctive technical > > opinions/explanations for other technical arguments. It seems that you > > emphasized mainly on the correct procedures, even for technical arguments. > > > > If so, once the WG make the wrong selection, It will be more difficult to > > correct it. After all, the Routing ADs are the experts that are most > > familiar with the routing related work. > > > > > > > > Finally, according to the procedure, I will submit the appeal to the > > IESG for the next state review in these days, with updated document > > https://datatracker.ietf.org/doc/html/draft-wang-lsr-reasons-of-abando > > n-upa-proposal-02 > > > > > > > > > > > > Best Regards > > > > > > > > Aijun Wang > > > > China Telecom > > > > > > > > From: James Guichard [mailto:[email protected]] > > Sent: Tuesday, June 10, 2025 9:02 PM > > To: Aijun Wang <[email protected]> > > Cc: 'lsr' <[email protected]>; 'lsr-chairs' <[email protected]>; > > 'rtg-ads' <[email protected]>; James Guichard > > <[email protected]> > > Subject: Re: Appeal for the WGLC of UPA draft 答复: [Lsr] Re: WG Last > > Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - > > 5/2/2025) > > > > > > > > Hi Aijun, > > > > > > > > Below you will find my responses inline. Please note that I now consider > > this appeal closed and I will move the document forward to the next stage > > of the IETF process. I have removed any text from my original message that > > is no longer relevant. > > > > > > > > Thanks! > > > > > > > > Jim > > > > > > > > ** references used below > > > > [1] > > https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-anno > > unce/ > > > > [2] > > https://mailarchive.ietf.org/arch/msg/lsr/-kpVLgvYhnrk_vK1kLCm7EO3rRA/ > > > > [3] > > https://mailarchive.ietf.org/arch/msg/lsr/WGpVq1GLDKKqXgH4FwhiBvgyvmU/ > > > > > > > > From: Aijun Wang <[email protected]> > > Date: Tuesday, June 3, 2025 at 10:39 PM > > To: James Guichard <[email protected]> > > Cc: 'lsr' <[email protected]>, 'lsr-chairs' <[email protected]>, > > 'rtg-ads' <[email protected]> > > Subject: RE: Appeal for the WGLC of UPA draft 答复: [Lsr] Re: WG Last > > Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - > > 5/2/2025) > > > > Hi, Jim: > > > > > > > > Sorry for replying your responses so late. I am trying to get the clear > > answer for some disputed points[17] but until now there is none. > > > > The author(and also other experts) can’t answer the example[17] clearly, > > then I add the point to updated document[18]. > > > > > > > > Until now, the issues and mimic parts described in[18] exists still in the > > document [1], no substantive changes even it updated two new versions again. > > > > > > > > The IETF standard shouldn’t build on one unsteady base, nor should it > > encourage the imitation behaviors that are displayed obviously on [1], > > which acquires the most parts of the idea from [16]. > > > > > > > > Please see more detail replies inline below. > > > > > > > > [17]: Example of stop advertising UPA doesn’t represent the specific > > prefix is reachable again: > > https://mailarchive.ietf.org/arch/msg/lsr/HnRhGkekX7aDRLxIAZ0Qim1dufI/ > > > > [18]: > > https://datatracker.ietf.org/doc/html/draft-wang-lsr-reasons-of-abando > > n-upa-proposal-02 > > > > > > > > > > > > Best Regards > > > > > > > > Aijun Wang > > > > China Telecom > > > > > > > > From: James Guichard [mailto:[email protected]] > > Sent: Friday, May 23, 2025 10:13 PM > > To: Aijun Wang <[email protected]> > > Cc: 'lsr' <[email protected]>; 'lsr-chairs' <[email protected]>; rtg-ads > > <[email protected]> > > Subject: Re: Appeal for the WGLC of UPA draft 答复: [Lsr] Re: WG Last > > Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - > > 5/2/2025) > > > > > > > > Hi Aijun, > > > > > > > > Thank you for bringing your concerns regarding > > draft-ietf-lsr-igp-ureach-prefix-announce [1] to my attention. While your > > email was not clear as to whether you are appealing on a procedural basis > > or technical concerns with the document, I am responding with my assessment > > of both having reviewed how the document has been handled by the WG and the > > WG chairs, as well as the technical concerns that you raise in your > > document [2]. Please note however that I encourage you to read > > https://www.rfc-editor.org/rfc/rfc2026#section-6.5.1 of RFC2026 as it > > provides guidance on the difference between appealing procedural errors > > and/or inaccurate technical choices made by the WG. > > > > [WAJ]: My appeals are mainly for the technical choices. The mimics parts > > relates to the code of IETF conduct. > > > > I notices there is one RFC9775(IRTF Code of Conduct) describes that > > “Plagiarism, misrepresentation of authorship, and content falsification > > constitute dishonesty and fraud”, but found none for such behavior in IETF. > > > > Should IETF defines the similar document to refrain such behaviors? > > > > > > > > <Jim> Code of Conduct guidelines for the IETF are covered within RFC 7154. > > I do not have an opinion on whether that RFC is sufficient, but you are > > welcome to pursue an update through the normal IETF processes if you > > believe additional content needs to be added. > > > > > > > > Before providing my assessment of the current appeal I would like to note > > that you previously appealed the WG adoption for this document and that > > appeal was processed by the responsible Area Director, John Scudder [3]. > > Given the guidelines provided in section 6.5.4 of RFC2026 [4], I will not > > revisit the conclusion of that appeal and consider it to have no bearing on > > the outcome of the current appeal. > > > > [WAJ]: Yes, I don’t try to change the adoption result. What I want to is > > that the mimics parts should be removed from the adopted document [1]. > > > > John’s responses in [3] states clearly we are the first to > > publish the document to solve the problem. > > > > If the contents/ideas are adopted/incorporated by other > > document, the original authors should at least be the authors of the > > adopted document, or else, please remove the mimic parts. > > > > > > > > If IETF indulge such behaviors, there will be no person > > contribute the fresh ideas. This is one bad example and should be corrected > > immediately. > > > > > > > > <Jim> The IETF is very clear on this topic from a procedural perspective. > > BCP79 (RFC5378) defines in Section 1 contribution as: > > > > > > > > any submission to the IETF intended by the Contributor for publication as > > all or part of an Internet-Draft or RFC (except for RFC Editor > > Contributions described in Section 4 below) and any statement made within > > the context of an IETF activity. > > > > > > > > Following this, RFC5378 Section 3.2 describes the formality around “Rights > > to Use Contributions” and in Section 3.3 “Right to Produce Derivative > > Works” describes that contributions can be used for derivative works. > > > > > > > > [7] “LSInfinity Feature is Flawed”. > > > > > > > > This objection, labeled "LSInfinity Feature is Flawed," was thoroughly > > discussed on the working group mailing list [14]. I have reviewed the > > points raised in the email exchange as well as the relevant specifications, > > including RFC 2328, RFC 5305, and RFC 5308. Based on this review, I find no > > indication of a protocol defect. The behavior described is consistent with > > the original design and intent of the protocols, and I do not consider this > > objection to warrant further action. > > > > [WAJ]: Along the discussions, we have summarized one simple scenario to > > illustrate the flawed design. > > > > If you think there is “no indication of a protocol defect” in RFC 2328, > > please see the example in [2] and answer the following questions: > > > > Why two prefixes, P0 and P1, with the total cost same as “LSInfinity” > > on R3, but one is reachable(P0), another is unreachable(P1) > > > > Why the reachable prefix P0 on ABR can’t be reached on R1/R2 in another > > area? > > > > How to assure it is reachable in another area? > > > > > > > > <Jim> This example has been reviewed by the working group and discussed on > > the mailing list [2]. Based upon my review, I find no indication of a > > protocol defect, and in addition I note that Section 4.3 of [1] states: > > > > Advertising prefix reachability between OSPF areas assumes prefix > > reachability in a source area. Such requirement of reachability MUST NOT be > > applied for UPAs, as they are propagating unreachability. > > > > OSPF ABRs may wish to advertise received UPAs into other connected areas. > > When doing so, the original LSInfinity metric value in UPA MUST be > > preserved. The cost to reach the originator of the received UPA MUST NOT be > > considered when readvertising the UPA to connected areas. > > > > In summary I do not consider that working group consensus should be > > overridden as the document [1] is very clear on this point. > > > > > > > > [8] “U/UP Flag Definition should be removed”. > > > > > > > > This objection appears to relate to whether the U-Flag and UP-Flag are (a) > > useful and (b) adequately convey the reason for prefix unreachability. I > > reviewed the relevant mailing list discussion [15], which includes > > clarifications from the authors. As explained, the definition of prefix > > unreachability using a specific metric does not depend on the presence of > > these flags—meaning their use is optional. This is explicitly stated in > > Section 5.3 of the document [1]: > > > > > > > > "The setting of the U-Flag or the UP-Flag signals that the prefix is > > unreachable. They constitute the UPA signals. Treatment of these flags on > > the receiver is optional and the usage of them is outside of the scope of > > this document." > > > > > > > > The working group reached consensus that inclusion of these flags is > > appropriate. In fact, the flags were added following WG list discussions > > and input received prior to WG adoption. Based on this background and the > > consensus that has formed around the current text, I see no justification > > to override the working group’s conclusion on this matter. > > > > > > > > [WAJ]: As you and the document stated, these flags are optional. They are > > not the MUST part of the UPA signaling. > > > > Then the document tries to advertise some non-topology, > > management information within the IGP. > > > > If it is allowed, there will be many such information flooded within the > > IGP protocol, which will certainly overflow the protocol. > > > > Such trend should be prohibited. > > > > > > > > <Jim> This matter is now considered closed. The working group, with its > > collective expertise and understanding of the procedural and technical > > implications, reached consensus that inclusion of these flags is > > appropriate. The flags were introduced because of WG list discussions and > > input received prior to WG adoption. Given this background and the > > consensus that has clearly formed around the current text, there is no > > justification to revisit or override the working group’s decision. Any > > future enhancements, such as the introduction of new, unrelated information > > into the flooding process, will follow the usual IETF process: open > > discussion within the working group and consensus determination. > > > > > > > > [9] “Mimic Parts should be removed”. > > > > > > > > This objection relates to issues that were already addressed in the context > > of the earlier, concluded appeal concerning WG adoption. Additionally, the > > contributions in question have been acknowledged by the authors in Section > > 11 of [1]. While such acknowledgments are not strictly required by the > > formal IETF process, the authors included them as a matter of good spirit, > > professional courtesy, and in support of the integrity of the process. > > Given this, I do not believe any further action is warranted. > > > > > > > > [WAJ]: Previous appeal and response [3] is mainly for adopting which > > document. It doesn’t state when adopt one document, it can then > > mimic/acquire the contents of the another document, without the > > authorization of authors of the related document. From the history > > comparison of the document[1] and [16], we can know [16] contribute > > not only “problem statement and the solution requirement discussion” > > declared in [1], but all the mimic parts described in [2] > > > > > > > > <Jim> First, the IETF process and procedures as outlined in BCP78 allow for > > content and/or ideas from prior contributions to be used for derivative > > works. As part of this process, one would expect that the original authors > > be consulted and indeed I note that a discussion on this point was held on > > the working group mailing list [3]. Specifically, in that mail archive I > > note the following: > > > > > > > > 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. > > > > > > > > Again, these previous contributions have been acknowledged by the authors > > in Section 11 of [1], and I do not believe that any further action is > > warranted. > > > > > > > > [10] “Control Knob at the ABR”. > > > > > > > > This objection appears to consist of two elements: (1) that Section 4 of > > draft-ietf-lsr-igp-ureach-prefix-announce [1] closely resembles content > > from a previously submitted individual draft, and (2) that the document > > lacks additional configuration controls (referred to as "control knobs") at > > the ABR. > > > > > > > > Regarding the first point, this concern is procedural rather than technical > > in nature, and it was already considered during the previous appeal > > concerning WG adoption. The issue was also discussed on the working group > > mailing list at the time. Furthermore, I note that the authors of [1] > > explicitly acknowledge your contributions to both the problem statement and > > the solution discussion in Section 11 of the draft. > > > > > > > > With respect to the second point, the only explicit reference I could find > > to "control knobs" appears in Section 6 of [16]. You are correct that both > > drafts include a configurable parameter to control UPA generation. However, > > such configuration options are standard practice in routing protocol design > > and do not represent a novel mechanism. The working group reviewed this > > aspect of the solution, and consensus was reached that the behavior is > > appropriate and should remain as defined in [1]. > > > > > > > > Based on the established WG consensus and the procedural considerations > > outlined above, I do not find sufficient justification to override the > > working group's decision. > > > > > > > > [WAJ]: The “Control Knob” is not derived from the discussions, but directly > > from the document[16]. If such behavior can’t be constrained, anyone can > > copy other’s ideas from the original document. > > > > > > > > <Jim> As previously stated, such control mechanisms are standard practice > > for many protocols and there is nothing novel in this case as far as I can > > tell. Again, based upon my review I do not see any evidence to suggest that > > the authors or the working group copied ideas from elsewhere other than > > documenting something that is widely used in most protocols. > > > > > > > > [11] “Partition Consideration” > > > > > > > > This objection concerns the absence of a solution for area or domain > > partitioning in draft-ietf-lsr-igp-ureach-prefix-announce [1]. > > > > > > > > It is important to clarify that the authors have explicitly stated that > > addressing area or domain partition scenarios is outside the scope of the > > document. This is clearly noted in Section 6 of [1], where the document > > acknowledges the limitations of the proposed mechanism with respect to > > partition scenarios. Additionally, the authors make it clear that the > > introduction of UPA neither improves nor worsens the behavior of IGPs in > > the presence of partitions. > > > > > > > > Given this clear scoping statement and the fact that the document does not > > claim to solve the partitioning problem, I do not consider this objection > > as grounds for further action. > > > > > > > > [WAJ]: Then just simply remove the contents of “out of scope”. There are > > also other issues that the document[1] can’t solve, should it document them > > also? > > > > > > > > <Jim> As previously noted, the document explicitly states that the topic in > > question is out of scope. This approach is consistent with standard > > practice in many RFCs. It is neither expected nor practical for a document > > to enumerate all problems or scenarios it does not attempt to address. > > > > > > > > From: Aijun Wang <[email protected]> > > Date: Friday, May 16, 2025 at 11:04 AM > > To: James Guichard <[email protected]> > > Cc: 'lsr' <[email protected]>, 'lsr-chairs' <[email protected]> > > Subject: Appeal for the WGLC of UPA draft 答复: [Lsr] Re: WG Last Call > > for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025) > > > > Hi, Jim: > > > > > > > > As expected, I appeal the final conclusion of WGLC of UPA draft. > > > > I have summarized the detail reasons at > > draft-wang-lsr-reasons-of-abandon-upa-proposal-00 > > > > > > > > Please review it and I expect to hear your responses. > > > > I have discussed the related issues with the authors, and also the LSR > > chair, they don’t give the reasonable explanations. > > > > > > > > I would like to hear your opinions, online, or offline, or discuss it at > > the coming IETF 123 meeting. > > > > > > > > Best Regards > > > > > > > > Aijun Wang > > > > China Telecom > > > > > > > > 发件人: [email protected] > > [mailto:[email protected]] 代表 Yingzhen Qu > > 发送时间: 2025年5月14日 13:31 > > 收件人: Aijun Wang <[email protected]> > > 抄送: Acee Lindem <[email protected]>; Peter Psenak > > <[email protected]>; Robert Raszuk > > <[email protected]>; Les Ginsberg > > <[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) > > > > > > > > Hi, > > > > > > > > Thanks to the authors for updating the draft, and we've received IPR > > replies from all the authors and contributors. > > > > > > > > During the WGLC, there were the following objections: > > > > Tony Li and John Drake think the problem shouldn't be solved using IGP: > > > > https://mailarchive.ietf.org/arch/msg/lsr/298QAjMcDSuS9fEgx8eMgfBMNN0/ > > > > https://mailarchive.ietf.org/arch/msg/lsr/84A3IqPRvOMih7wofaDfc0290r8/ > > > > Aijun Wang is objecting: > > > > https://mailarchive.ietf.org/arch/msg/lsr/dqBcKdfJlyZiJ_N0QSxq2fhdLIY/ > > > > https://mailarchive.ietf.org/arch/msg/lsr/BRSv68IUdiN88IVW-9LDDWDWF3g/ > > > > > > > > Despite these objections, there was enough support from other WG members, > > so the chairs think there is rough consensus from the WG and now the WGLC > > is closed. We will continue the publication of > > draft-ietf-lsr-igp-ureach-prefix-announce. > > > > > > > > Thanks to everyone's comments and contribution. > > > > > > > > Thanks, > > > > Yingzhen (LSR Co-Chair) > > > > > > > > On Mon, May 5, 2025 at 3:22 PM Yingzhen Qu <[email protected]> wrote: > > > > Hi Aijun, > > > > > > > > Thank you for your continued engagement in the discussion. > > > > > > > > After reviewing your recent message, we respectfully note that some of the > > language used appears to be inconsistent with the principles outlined in > > RFC 7154 ( IETF Guidelines for Conduct), specifically Section 2: > > > > > > > > " > > > > 2. IETF participants have impersonal discussions. > > > > We dispute ideas by using reasoned argument rather than through > > intimidation or personal attack. Try to provide data and facts for your > > standpoints so the rest of the participants who are sitting on the > > sidelines watching the discussion can form an opinion. The discussion is > > easier when the response to a simple question is a polite answer [SQPA]. > > > > " > > > > > > > > In particular, the following statements raise concern: > > > > > > > > "If you are familiar with the topic, it’s OK. But actually you are not > > familiar with this topic (or you stuck in your attitude/prejudice—this is > > not the right behavior of one WG chair) as the authors and us." > > > > https://mailarchive.ietf.org/arch/msg/lsr/XlM6TAR7tJQ-4eNf7t4_uJe6PBE/ > > > > > > > > "Knowing the above information can authenticate your declaration." > > > > > > https://mailarchive.ietf.org/arch/msg/lsr/ouaSa6V3d6mIP_b_Stbka1cOgXM/ > > > > > > > > The phrasing may be perceived as personal judgment and could discourage > > open, respectful technical exchange — which is essential to the success of > > our Working Groups. > > > > > > > > Also repeating the same questions should be avoided: > > https://datatracker.ietf.org/doc/html/rfc2418#section-3.3 > > > > > > > > Please note that repeated disruptive or inappropriate behavior can result > > in the removal of your posting rights for IETF mailing lists. > > > > > > > > In the interest of maintaining a productive and professional environment, > > we kindly ask that you adhere to the IETF’s conduct guidelines and refrain > > from making personal remarks directed at individuals, including chairs. > > > > > > > > Thank you for your understanding. > > > > > > > > Acee, Chris, Yingzhen > > > > LSR Chairs > > > > > > > > On Sun, May 4, 2025 at 9:24 PM Aijun Wang <[email protected]> wrote: > > > > Hi, Acee: > > > > > > > > When I want to discuss with the authors, you can’t wait to stand out, try > > to represent the authors. > > > > > > > > If you are familiar with the topic, it’s OK. But actually you are not > > familiar with this topic(or you stuck in your attitude/prejudice—-this is > > not the right behavior of one WG chair) as the authors and us. Then please > > let’s wait the authors’ responses. > > > > > > > > I restate them(considering all your responses until now) here, please read > > them carefully before any response: > > > > > > > > 1) The “U/UP flag” used to indicate the reason of the unreachable prefixes > > is: > > > > NOT necessarily(LSInfinity is enough, although I don’t recommended it > > either), > > > > NOT suitable(IGP shouldn’t flood management purposes information) and > > > > NOT enough(There are many reasons for the unreachable prefixes). > > > > > > > > 2) The usage of “U/UP flag” in this document is DIFFERENT from that in > > RFC8706, in which the receiver of such information will do SPF calculations > > based on the related flags. But for “U/UP flag”, they are just trying to > > give the reason of unreachable. > > > > > > > > 3) > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-04#section-5 > > is the the COPYCAT from other proposal. If the WGLC document wants to > > include, please state admirations to the original authors. This is the > > decent IETF behavior. > > > > (The original idea was described in Founder Draft[1], ONE YEAR earlier > > than the first version of the WGLC document) > > > > > > > > 4) The partition possibilities in the network is also first discussed at > > the Founder Draft[1], please remove it because the WGLC document solve > > nothing after the “Garrulous” description. Or, just state simply as “out of > > the scope of this document”. > > > > > > > > There are also other issues on this WGLC document but I must wait first the > > responses from the authors on the above questions. > > > > > > > > [1] Founder Draft: > > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachabl > > e-annoucement-06#section-7 > > > > > > > > Aijun Wang > > > > China Telecom > > > > > > > > On May 1, 2025, at 22:42, Acee Lindem <[email protected]> wrote: > > > > Speaking as WG Co-Chair: > > > > Aijun, > > > > You've raised these concerns before and they were responded to. The fact > > that you are more vehement doesn't make them any more compelling. > > Please keep in mind that many of us are busy and don't wish to engage in > > circular arguments. > > > > Speaking as WG Member: > > > > I'll respond one more time for your inevitable appeals... > > > > On Apr 30, 2025, at 8:53 PM, Aijun Wang <[email protected]> wrote: > > > > > > > > Hi, Peter: > > > > > > > > I must remind you that the following things: > > > > > > > > 1) The newly defined “U/UP flags” MUST be removed, as you declared they are > > trying to “give the reason of unreachable”, which is not suitable for IGP > > protocol, and also not enough to describe various reasons for the > > unreachability. > > > > > > As I stated previously, there is a precedence with signaling whether or not > > the outage is planned in RFC8706. This may determine the reaction to the > > unreachability by other routers in the domain. It need not be specified > > since this is a generalized mechanism. > > > > > > > > 2) Remove the “partition” related description. Current contents doesn’t > > solve the problem, no useful information provided to the reader. > > > > > > This section is useful as it states that the mechanisms do NOT attempt to > > solve the partition problem. > > > > > > > > 3) Remove the control knob considerations on the ABR. Because they are > > first provided by other proposal, and current contents covers only part of > > them. > > > > > > This needs to be configured as well as the ranges of prefixes subject to > > reachability signaling. > > > > > > > > After the above adjustments, there will be nothing needs to be > > standardized, the document should be changed to “Information Track”. > > > > > > You either didn't read or understand the draft. The abstract alone should > > make it obvious that this isn't an informational specification. > > > > > > Acee > > > > > > > > > > > > Aijun Wang > > > > China Telecom > > > > > > > > On Apr 30, 2025, at 23:09, Peter Psenak > > <[email protected]> wrote: > > > > > > > > Robert, > > > > > > > > On 30/04/2025 17:02, Robert Raszuk wrote: > > > > > > > > Indeed we agreed on the list but I never noticed text being added to > > address it into section 4. In -04 it is not there. > > > > we have not added it yet, but we agreed I would. I will do when the next > > version is pushed, but wanted to wait for some more comments to include. > > > > thanks, > > > > Peter > > > > > > > > Thx, > > > > R. > > > > > > > > On Wed, Apr 30, 2025 at 4:59 PM Acee Lindem <[email protected]> wrote: > > > > To cover the make-before-break situation you and Peter discussed in this > > thread. > > > > > > > > > > > > If there are no alternate paths I would rather keep one installed active - > > for example to address the case where one ABR can still reach egress PE and > > the other one generated UPA. > > > > > > > > > > > > Thanks, > > > > Acee > > > > > > > > On Apr 30, 2025, at 10:57 AM, Robert Raszuk <[email protected]> wrote: > > > > > > > > Which text ? > > > > > > > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-igp-ureach-pr > > efix-announce-03&url2=draft-ietf-lsr-igp-ureach-prefix-announce-04&dif > > ftype=--html > > > > > > > > Thx, > > > > R. > > > > > > > > On Wed, Apr 30, 2025 at 4:52 PM Acee Lindem <[email protected]> wrote: > > > > Hi Robert, > > > > > > > > I guess you are now fine with the draft with this text. > > > > > > > > Thanks, > > > > Acee > > > > > > > > On Apr 23, 2025, at 10:51 AM, Robert Raszuk <[email protected]> wrote: > > > > > > > > ok, I'm fine adding some text for your case. > > > > > > > > Thx Peter ! > > > > > > > > It is not "my use case" but ability to trigger UPA for make-before-break > > which I think always is rather a good thing. > > > > > > > > Cheers, > > > > R. > > > > > > > > > > > > On Wed, Apr 23, 2025 at 4:40 PM Peter Psenak <[email protected]> wrote: > > > > Hi Robert, > > > > > > > > On 23/04/2025 16:35, Robert Raszuk wrote: > > > > Hi Peter, > > > > If the egress PE is the only BGP NH, then reacting to max-metric or OL-bit > > set would make some BGP destinations unreachable. > > > > > > > > Well this entirely depends on how one reacts on UPA if UPA is signalling > > the only one left BGP path/NH as down irrespective of the trigger. Does it > > stop the service to the destination or not ... > > > > > > > > If there are alternate paths the best path can install new next hop. > > > > > > > > If there are no alternate paths I would rather keep one installed active - > > for example to address the case where one ABR can still reach egress PE and > > the other one generated UPA. > > > > > > > > So why not trigger UPA in such cases to hint him to switch to alternate > > next hops if available ? > > > > I'm not saying it can not be done. The implementation can chose to > > advertise the UPA for the summary component prefix if the such prefix > > metric in the source area/domain crosses certain value or if the prefix > > originator is overloaded. > > > > But this would make it not compliant with current text in section 4 which > > was the main point of my question. So why not leave the door a bit open for > > it in the spec ? > > > > ok, I'm fine adding some text for your case. > > > > thanks, > > > > Peter > > > > > > > > > > > > Thx, > > > > R. > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
