Re: [GROW] Internet-Draft draft-liu-grow-bmp-stats-reports-00

dear jeff,

Thank you for your comments on the draft, we will update them in the new draft. Includes a more explicit description of the "route threshold", references to RFC4172, and recommendations on the possible impact of RIB-OUT statistics and implementation of RFC8893.

        Jinming Li,

    On Feb 28, 2024, at 2:37 AM, 李金铭 <lijinming@chinamobile.com> wrote:

       For  the first comment, our reference to "route threshold" in the 
draft only  includes routes in RIB-IN that are rejected due to 
configuration  limitations. Which is the same as the latter you 
mentioned in your  email.

        The "license-customized route 
threshold" count is  consistent with the above considerations, and 
vendor licenses are  sometimes updated at the request of network 
operators, we wanted to  define a counter to monitor such changes.

        Therefore, it is reasonable to define a 64-bit counter "gauge" to measure the above changes.

    You
 will want to clarify the text to say "routes that are accepted into the
 rib-in, but not eligible for installation in the loc-rib".

Indeed, the "route threshold" needs further clarification in the draft.

    The RPKI counter mentioned in the draft only 
focuses on ROA query results. Since the RPKI action changes caused by 
RFC8893 do not involve query results, there is no immediate impact on 
the counter. In any case, we will keep an eye on it.

The place this can impact is whether rpki reject procedures are applied on egress or not.

If
 RFC 8893 is not implemented by the router, the counters will typically 
reflect rpki validation applied only at the rib-in level.

If
 RFC 8893 is implemented, the statistics will differ for routes that 
undergo as-path transformations that render them rpki-invalid, or 
potentially change them to valid from invalid.

My recommendation is to omit the rib-out counters unless RFC 8893 is implemented.

-- Jeff

The implementation of RFC8893 does have an impact on the statistics in this case.We should add such a statement in future drafts. like, "This type of statistics is recommended only if the router implement RFC8893."

_______________________________________________

GROW mailing list

GROW@ietf.org

https://www.ietf.org/mailman/listinfo/grow

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Jinming Li,On Feb 28, 2024, at 2:37 AM, 李金铭 <lijinming@chinamobile.com> wrote:
    For  the first comment, our reference to "route threshold" in the draft only  includes routes in RIB-IN that are rejected due to configuration  limitations. Which is the same as the latter you mentioned in your  email.

    The "license-customized route threshold" count is  consistent with the above considerations, and vendor licenses are  sometimes updated at the request of network operators, we wanted to  define a counter to monitor such changes.

    Therefore, it is reasonable to define a 64-bit counter "gauge" to measure the above changes.

You will want to clarify the text to say "routes that are accepted into the rib-in, but not eligible for installation in the loc-rib".
    For  the as-path length threshold, The reference here is intended to clarify  the definition of AS-Path from RFC4271,not threshold lengths. Obviously  there is some ambiguity in the current formulation, and I will update  the description in a later version.

Thanks.
    The RPKI counter mentioned in the draft only focuses on ROA query results. Since the RPKI action changes caused by RFC8893 do not involve query results, there is no immediate impact on the counter. In any case, we will keep an eye on it.

The place this can impact is whether rpki reject procedures are applied on egress or not.

If RFC 8893 is not implemented by the router, the counters will typically reflect rpki validation applied only at the rib-in level.

If RFC 8893 is implemented, the statistics will differ for routes that undergo as-path transformations that render them rpki-invalid, or potentially change them to valid from invalid.

My recommendation is to omit the rib-out counters unless RFC 8893 is implemented.

-- Jeff

Best regards,

Jinming Li

_______________________________________________
GROW mailing list

GROW@ietf.org

https://www.ietf.org/mailman/listinfo/grow

----邮件原文----发件人：Jeffrey Haas  <jhaas@pfrc.org>收件人："李金铭" <lijinming@chinamobile.com>抄　送: grow  <grow@ietf.org>发送时间：2024-02-28 03:30:59主题：Re: [GROW] Internet-Draft draft-liu-grow-bmp-stats-reports-00Jinming Li,
A few comments on your proposed counters:

Are your "route threshold" counters intended to cover route discards or only routes that are retained in the adj-ribs-in and automatically rejected because they exceed a configured limit?

If the case is intended to cover discards as well, a gauge is probably not the correct type for this.  You can only keep a gauge for state that you know comes and goes.  Discards can be counted (counter type), but not tracked on a per-prefix basis without keeping the prefix.

For your license restriction count, I understand the use case.  However, I have some concerns that the counter is clear in a vendor neutral fashion.  And, similar to the comments above, if this is intended to cover cases where routes are discarded along with the case for keeping the routes a counter may be a more appropriate type.

For the as-path length threshold, please restructure the reference to RFC 4271.  As written, it looks like the citation is intending to say such threshold lengths are a feature of that RFC.  They are not.

The RPKI counters will be popular!  Please consider socializing these counters with the sidrops group.

Please also be aware that for adj-ribs-out for rpki that RFC 8893 might change the behavior somewhat.

-- Jeff

On Feb 26, 2024, at 8:24 PM, 李金铭 <lijinming@chinamobile.com> wrote:
Hi all,

We have submitted a new Internet-Draft draft-liu-grow-bmp-stats-reports-00 which is about BMP Statistics Types.

As the BGP protocol continues to expand, more and more functional features are implemented through the BGP protocol, which adds more event information to monitor these functional features.This document lists some new statistics types to update RFC 7854 for growing BGP features.

The New BMP statistics types are used by the monitoring station to observe more interesting events that occur on the router.  

New types Include RIB-IN Statistics Types for Route Threshold, RIB-IN/RIB-OUT Statistics Types for AS-Path Length Threshold, and RIB-IN/RIB-OUT Statistics Types for Route Origin Validation. 

If you have some comments and suggestions, please provide feedback.

The IETF datatracker status page for this Internet-Draft is:

https://datatracker.ietf.org/doc/draft-liu-grow-bmp-stats-reports/

Best regards,

Jinming Li

_______________________________________________

GROW mailing list

GROW@ietf.org

https://www.ietf.org/mailman/listinfo/grow

_______________________________________________GROW mailing listGROW@ietf.orghttps://www.ietf.org/mailman/listinfo/grow