If these flags are optional, and the receiver can ignore them, what’s the reason to standardize them?
It will be more efficient, and more reasonable, for the ABR to report the unreachable reason directly to the operator via YANG Notification mechanism. To keep the standard concise and decrease the interoperability issues(not all of nodes within the IGP domain support the unnecessary announcement----there will be no nodes to support the unnecessary feature): https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-04#section-5 and https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-ureach-prefix-announce-04#section-8 Should be removed. Best Regards Aijun Wang China Telecom 发件人: [email protected] [mailto:[email protected]] 代表 Peter Psenak 发送时间: 2025年5月6日 16:53 收件人: linchangwang <[email protected]>; 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) Changwang, please see inline: On 06/05/2025 10:12, linchangwang wrote: Hi WG, As a vendor, this feature has been successfully integrated with multiple vendors in the EANTC tests for 2024 and 2025. The EANTC test link for 2025 is as follows: https://wiki.eantc.de/wiki/publicreports/view/Main/Multi-Vendor%20MPLS%20%26%20SDN%20Interoperability%20Test%20Report%202025/SRv6/SRv6%20Unreachable%20Prefix%20Announcement In the specific implementation, the following two issues were encountered: 1. The implementation MUST or SHOULD include the U or UP flag? 2. >From an implementation perspective, would basic interoperability be achieved by just implementing Sections 2, 3, and 4 of the document? Specifically: On the sender side: Advertising unreachability via max-cost On the receiver side: Controlling fast max-cost processing through configuration The U/UP flags in Chapter 5 (including Section 5.3 descriptions) appear non-essential for interoperability, as they merely indicate unreachability reasons. When advertising unreachable prefixes from the sender side, is it necessary to include the U or UP Flag? the notion of prefix unreachable metric does not require these new flags. They are indicating the reason for unreachability. An implementation can use the advertisement with the unreachable metric as UPA even without these flags. 2．Configuration Management Considerations: Should the sender-side U/UP flag settings also be configuration-controlled? that is an implementation choice and should not be specified in the RFC thanks, Peter Recommendation: Add a configuration management section specifying implementation guidance, for example, consider configuration management similar to the following command line: prefix-unreachable { advertise-lifetime <value> | advertise-metric <value> | advertise-flags-enable | advertise-maximum <value> | receive-process-enable } Implement configurable controls for: • Unreachable prefix generation parameters (metric, timers, U/UP flag) • Unreachable prefix processing policies Thanks, Changwang 发件人: Yingzhen Qu <mailto:[email protected]> <[email protected]> 发送时间: 2025年4月18日 2:13 收件人: lsr <mailto:[email protected]> <[email protected]>; lsr-chairs <mailto:[email protected]> <[email protected]> 主题: [Lsr] WG Last Call for draft-ietf-lsr-igp-ureach-prefix-announce (4/17/2025 - 5/2/2025) 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/> 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 ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
