Hey Aijun, I'm not going to engage in a protracted argument on the novelty of scoping a routing feature to specific features. Having said that...
> On Apr 24, 2025, at 4:40 PM, Aijun Wang <[email protected]> wrote: > > Hi, Acee: > > Firstly, you have some stubborn prejudices—-what I call the copycat behavior > was the description of the configuration control at the ABRs for the > announcement of prefix unreachable announcements—-I have given the > evidence(section link) of such behavior. > > If you call “it’s certainly isn’t a novel concept”, please give the original > idea link that before us. > > After it is described after our initial statement, it is not a novel concept. > > Even for this novel concept, the WGLC document gives only the partial > solution, there is also other configuration knob you can learn from the > Founder Draft[1] The OSPF implementation we developed at Redback networks allowed configuration of more-specific area ranges (both advertise and no-advertise) that would be advertised or suppressed separately and not considered as criteria for any less-specific subsuming ranges for the same area. As to limiting a feature to a set of prefixes, this is a common technique which is commonly satisfied with a prefix-list. Here is one example for prefix prioritization, https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/concept/prefix-prioritization-overview.html > > I can give you also another copycat behavior of the WGLC document——the > partition issue—-which is also first discussed at the Founder Draft. The WGLC > document mentions the issue, but failed to give the correct solution, because > there is no other alternative way, other than the knob described in the > Founder Draft. I guess if this knob is only in your draft, you can hardly claim that it has been copied. Acee > > Secondly, if you think the section 2.1 describes already the backward > compatibility of the solution, why define the U flag again in the “Prefix > Attributes Flag” sub-TLV, which is obviously not backwards compatibility? > > And to Yingzhen, I am not arguing the past WG adoption process, I am arguing > that current WGLC document doesn’t meet the threshold to pass the WGLC——there > are still several unsolved challenges, similar with the MP-TLV document, > should be addressed before forwarding it. > > I have given the Technical Analysis list in previous mail. > > [1] Founder Draft: > https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ > > > Aijun Wang > China Telecom > >> On Apr 25, 2025, at 01:20, Acee Lindem <[email protected]> wrote: >> >> Speaking as WG member: >> >>> On Apr 24, 2025, at 7:57 AM, Aijun Wang <[email protected]> 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. >> >> >> Specifically what are you claiming ownership of here? Configuration of >> prefixes to protect - >> This certainly isn’t a novel concept. The application of signaling >> unreachability without >> modifying the RIB/FIB directly was discussed on the list prior to you saying >> you could do that too in your draft. So, perhaps you’re looking in the wrong >> place for >> copycats. >> >> >> >>> >>> 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”? >> >> >> See section 2.1, first paragraph. >> >> Thanks, >> Acee >> >> >> >> >>> >>> 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 <[email protected]> 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 >>>>> 发件人: [email protected] [mailto:[email protected]] >>>>> 代表 Aijun Wang >>>>> 发送时间: 2025年4月22日 0:12 >>>>> 收件人: Yingzhen Qu <[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) >>>>> I object its forwarding, from the beginning of its WG adoption. >>>>> Aijun Wang >>>>> China Telecom >>>>> >>>>> >>>>> On Apr 18, 2025, at 02:13, Yingzhen Qu <[email protected]> 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 -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>> >>>> >>>> _______________________________________________ >>>> 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] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
