[Lsr] Re: 答复: Re: WG Last Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025)

[Aijun Wang]

Hi, Peter: Several experts have expressed that IGP isn’t the place to advertise the non-topology information.  Then, if “the newly define flag is not to signal unreachability, it is rather to signal a reason for it.”,  it should be clarified as the error report information, which should be in the management plane, not the control plane. What’s the reason that let the nodes within the network know the reason of unreachability? Such information should be known only by the operator, which should be reported directly to the operator via NETCONF/YANG. Even for the ‘reason’, what can you conclude from the ‘U’ Flag to the reason of unreachability? (There may be many reasons for the unreliability, for example, node failure, link failure, area partition, domain partition etc.)  If these flags can’t give enough ‘reason’ information, and are not suitable to be transferred via the IGP protocol, I recommend you remove it, which may keep your proposal more backward as you declared. And, for the overall deployment of such solution, signal the unreliability(via LSinfinity, or prefix originator) is just one small portion of the solution, we should pay more attention to the control knobs of unreachable information flooding in various scenarios. I think this is the reason that Tony Li and Robert try to propose the solutions other than IGP based. Various control knobs are first and already covered by the Founder Draft[1]. [1] https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-14 Aijun Wang China Telecom On Apr 25, 2025, at 15:41, Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> 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.   Section II: Technical Analysis you keep repeating the same arguments over and over. These have been responded to numerous times during the adoption call and during the existence of the draft as a WG document. I'm going to put my responses below just to satisfy the IETF process, but I'm NOT going to continue the discussion any further. 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. the newly define flag is not to signal unreachability, it is rather to signal a reason for it.   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. LSInifinity is something that has been defined in a base protocol specification and is part of the protocol. It's meaning is clearly defined and it's usage is allowed whether you like it or not.   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. Using “Prefix Originator" for signalling unreachability is a completely broken idea and we have pointed that to you many times. You refused to accept it, I can't help you with that.   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. as I mentioned several times before, UPA is not trying to address the area partition. You are free to write a new draft that solves it, but please keep it orthogonal to UPA.   5)    There is no any consideration for the balance of reachable information and unreachable information announcements. It will be disaster in some critical condition. I think the draft is careful in defining how the mechanism should be used so as to avoid scalability issues. Regards, Peter     Best Regards   Aijun Wang China Telecom   发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Aijun Wang 发送时间: 2025年4月22日 0:12 收件人: Yingzhen Qu <yingzhen.i...@gmail.com> 抄送: lsr <lsr@ietf.org>; lsr-chairs <lsr-cha...@ietf.org> 主题: [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 <yingzhen.i...@gmail.com> 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-announce/   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 -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org

_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org