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-annoucement/. 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 <wangai...@tsinghua.org.cn> 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 <ppse...@cisco.com> 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 > > > > *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org > <forwardingalgori...@ietf.org>] *代表 *Aijun Wang > *发送时间:* 2025年4月22日 0:12 > *收件人:* Yingzhen Qu <yingzhen.i...@gmail.com> <yingzhen.i...@gmail.com> > *抄送:* lsr <lsr@ietf.org> <lsr@ietf.org>; lsr-chairs <lsr-cha...@ietf.org> > <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
