Hi, Yingzhen:
Thanks for your reminds I will conform to the guidelines and wish all of the LSR members conform to it also Let me point out some response that anger me: “You either didn't read or understand the draft.” By Acee, May 1, 2025 https://mailarchive.ietf.org/arch/msg/lsr/2lYX6OzsVSy6CqeJYdkeunPBwks/ I don’t’ want to find or look back to other offensive arguments along the discussions. Let’s look forward to the progress of conflict. Best Regards Aijun Wang China Telecom 发件人: Yingzhen Qu [mailto:[email protected]] 发送时间: 2025年5月6日 6:22 收件人: 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]> 主题: Re: [Lsr] WG Last Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025) 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] <mailto:[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-unreachable-annoucement-06#section-7 Aijun Wang China Telecom On May 1, 2025, at 22:42, Acee Lindem <[email protected] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]> > wrote: Which text ? https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-igp-ureach-prefix-announce-03 <https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-igp-ureach-prefix-announce-03&url2=draft-ietf-lsr-igp-ureach-prefix-announce-04&difftype=--html> &url2=draft-ietf-lsr-igp-ureach-prefix-announce-04&difftype=--html Thx, R. On Wed, Apr 30, 2025 at 4:52 PM Acee Lindem <[email protected] <mailto:[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] <mailto:[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] <mailto:[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] <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]
