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

Jeffrey Haas <jhaas@pfrc.org> Wed, 28 February 2024 13:39 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B6BC14F60C for <grow@ietfa.amsl.com>; Wed, 28 Feb 2024 05:39:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9T1WOdAbEin for <grow@ietfa.amsl.com>; Wed, 28 Feb 2024 05:39:22 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 26EE3C14F5E6 for <grow@ietf.org>; Wed, 28 Feb 2024 05:39:21 -0800 (PST)
Received: from smtpclient.apple (172-125-100-52.lightspeed.livnmi.sbcglobal.net [172.125.100.52]) by slice.pfrc.org (Postfix) with ESMTPSA id 3B1D81E039; Wed, 28 Feb 2024 08:39:21 -0500 (EST)
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_25EEAE50-13A4-4074-969E-FAC731A31E97"
From: Jeffrey Haas <jhaas@pfrc.org>
X-Priority: 3
In-Reply-To: <2afd65decd0fe29-00020.Richmail.00003052153960353796@chinamobile.com>
Date: Wed, 28 Feb 2024 08:39:20 -0500
Cc: grow <grow@ietf.org>
Message-Id: <F3E0E0B8-5394-44F9-9D9F-3CF93324A5F6@pfrc.org>
References: <2afd65dd38e2d5d-00071.Richmail.00002012857950353736@chinamobile.com> <C6348885-C8F8-4565-9315-1442F8A63913@pfrc.org> <2afd65decd0fe29-00020.Richmail.00003052153960353796@chinamobile.com>
To: 李金铭 <lijinming@chinamobile.com>
X-Mailer: Apple Mail (2.3696.120.41.1.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/CqNaBKN06r2yZ8LrgCEkMZ04S9A>
Subject: Re: [GROW] Internet-Draft draft-liu-grow-bmp-stats-reports-00
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Feb 2024 13:39:24 -0000

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-00
> 
> Jinming 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 <mailto: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/ <https://datatracker.ietf.org/doc/draft-liu-grow-bmp-stats-reports/>
>  
> Best regards,
> 
> Jinming Li
> 
> 
> _______________________________________________
> 
> GROW mailing list
> 
> GROW@ietf.org <mailto:GROW@ietf.org>
> https://www.ietf.org/mailman/listinfo/grow <https://www.ietf.org/mailman/listinfo/grow>
> 
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org <mailto:GROW@ietf.org>
> https://www.ietf.org/mailman/listinfo/grow
> 
>