Agree with Changwang’s response. Thanks Mukul
Juniper Business Use Only From: linchangwang <[email protected]> Date: Tuesday, August 5, 2025 at 8:51 AM To: Yang Yu <[email protected]>, Job Snijders <[email protected]> Cc: [email protected] <[email protected]> Subject: [GROW] Re: WGLC RESTART - draft-ietf-grow-bmp-bgp-rib-stats (ends 01/Aug/2025) [External Email. Be cautious of content] Hi Yang， Thanks for your comments. My responses are inline below with [Changwang]. Thanks, Changwang -----邮件原件----- 发件人: Yang Yu <[email protected]> 发送时间: 2025年8月5日 9:16 收件人: Job Snijders <[email protected]> 抄送: [email protected] 主题: [GROW] Re: WGLC RESTART - draft-ietf-grow-bmp-bgp-rib-stats (ends 01/Aug/2025) Hi all, Apologies for the late feedback. 1) It would be good to clarify a requirement that a TLV can only be sent if the value is known to be valid. Do not include TLVs with value 0 when the feature is unsupported / disabled (e.g. no TLV 41 / 42 / 43 if RPKI validation state not available in outbound). Do not include a gauge TLV if it only has partial data. [Changwang] This document only defines new gauges for the BMP statistics message. The specific TLVs to be reported depend on the specific implementation, and this document does not impose any restrictions. RFC7854 also does not specify that TLV with a value of 0 can be omitted. It is recommended to maintain consistency with RFC7854 and not impose specific restrictions. 2) On relationship between defined TLVs, particularly being explicit on whether routes reported by one TLV should be included in other TLVs > Type = 21: (64-bit Gauge) Current number of routes in per-AFI/SAFI Adj-RIBs-In Post-Policy. The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge. Type = 23: (64-bit Gauge) Number of routes in per-AFI/SAFI accepted by inbound policy. The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge. Some implementations, or configurations in implementations, MAY discard routes that do not match policy and thus the accepted count and the Adj-RIB-In counts will be identical in such cases. Is this about accounting for default accept / deny at the end of policy, or routes accepted by policy but still not "valid" (nexthop resolution failure, or mechanisms not strictly part of import policy like aspath loop prevention, left most AS not matching peer AS). It is not clear to me if TLV 23 should always be greater than TLV 21 [Changwang] Type 23 is the number of routes that pass through the policy, and Type 21 is the number of routes after the current policy. If routes that do not pass through the policy are not discarded (for example, if the device is configured with the keep-all-route function), the value of Type 21 will be greater than Type 23. >Type = 22: (64-bit Gauge) Current number of routes in per-AFI/SAFI >rejected by inbound policy Should TLV 22 include routes reported by TLV 26/27/28/34/40? [Changwang] Type 22 is a count that does not pass through inbound policy, and is unrelated to 26/27/28/34/40. 3) On license-customized TLVs, > Type = 31: (64-bit Gauge) Number of routes left until reaching a license-customized route threshold. This value is affected by whether a customized license exists for the relevant address family, and when the customized license is installed. Type = 32: (64-bit Gauge) Number of routes in per-AFI/SAFI left until reaching a license-customized route threshold. This value is affected by whether a customized license exists for the relevant address family, and when the customized license is installed. The value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge. Is there an expectation that the configured prefix limit (used for TLV 29/30) is not subject to license-customized limit? [Changwang] Type 29/30 is defined in section 6.7 of RFC4271. It is usually configurable and differs from the license-customized limit. Should it use enterprise-specific TLV as discussed in https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/grow/w85iHqlOgRejTSdFaoDG3pmwJ7A/__;!!NEt6yMaO-gk!D0BXJX9fuUB7qHMtr9KxeKjeAzB7oKHXlwzkx9JF2Atfg8ioJ9pb9gbSg_J7pgtCrqgbZYwYsPIcAdudTBenFl4$<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/grow/w85iHqlOgRejTSdFaoDG3pmwJ7A/__;!!NEt6yMaO-gk!D0BXJX9fuUB7qHMtr9KxeKjeAzB7oKHXlwzkx9JF2Atfg8ioJ9pb9gbSg_J7pgtCrqgbZYwYsPIcAdudTBenFl4$> ? [Changwang] During the previous discussion in the maillist the initially enterprise-specific TLV definitions were changed to the current type 31 and type 32. Therefore, it is recommended to maintain the existing definitions for type 29 and type 30. Cheers, Yang _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected] ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ 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! _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
