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

李金铭 <lijinming@chinamobile.com> Wed, 28 February 2024 07:37 UTC

Return-Path: <lijinming@chinamobile.com>
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 9009CC15107C for <grow@ietfa.amsl.com>; Tue, 27 Feb 2024 23:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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 ENomrj6J_TJS for <grow@ietfa.amsl.com>; Tue, 27 Feb 2024 23:37:25 -0800 (PST)
Received: from cmccmta3.chinamobile.com (cmccmta6.chinamobile.com [111.22.67.139]) by ietfa.amsl.com (Postfix) with ESMTP id EE50AC14F5F7 for <grow@ietf.org>; Tue, 27 Feb 2024 23:37:24 -0800 (PST)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[10.188.0.87]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee965dee2b09fc-209ff; Wed, 28 Feb 2024 15:37:20 +0800 (CST)
X-RM-TRANSID: 2ee965dee2b09fc-209ff
X-RM-SPAM-FLAG: 00000000
Received: from lijinming@chinamobile.com ( [10.2.53.178] ) by ajax-webmail-syy-appsvr05-11005 (Richmail) with HTTP; Wed, 28 Feb 2024 15:37:20 +0800 (CST)
Date: Wed, 28 Feb 2024 15:37:20 +0800
From: 李金铭 <lijinming@chinamobile.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: grow <grow@ietf.org>
Message-ID: <2afd65decd0fe29-00020.Richmail.00003052153960353796@chinamobile.com>
References: <2afd65dd38e2d5d-00071.Richmail.00002012857950353736@chinamobile.com>, <C6348885-C8F8-4565-9315-1442F8A63913@pfrc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_146805_1817288585.1709105840515"
X-Priority: 3
X-RM-TRANSID: 2afd65decd0fe29-00020
Encrypt-Channel: web
X-RM-OA-ENC-TYPE: 0
X-RM-FontColor: 0
X-CLIENT-INFO: X-TIMING=0&X-MASSSENT=0&X-SENSITIVE=0
X-Mailer: Richmail_Webapp(V2.4.29)
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/uhdo2QqKLeLLy0j25LL9lK2YNyM>
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 07:37:29 -0000

hi jeff,

    Thank you for the comments on the draft.

    

    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.



    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.



    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.






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