Hi,

Have the following feedback / comments, please review and accommodate them 
(apologies for joining the conversation late) 

1.      Statistics dependant on Monitored RIB-View(s): 
        •       Operators can enable or disable RIB-view modes on the routers 
to manage monitoring.
        •       Please clarify that statistics will only be transmitted if the 
corresponding RIB-views are actively monitored, and not all statistics will be 
sent always.
        •       Please map these statistics to the more specific RIB-views - to 
include the Pre and Post modes on top of Adj-RIB-In/Out. Some statistics seem 
relevant for the Local-RIB view as well.

2.      Statistics dependant on feature Configuration: 
        •       Many of the statistics are available and would make sense only 
when the corresponding configurations are enabled (eg: GR, LLGR, RPKI etc)
        •       Please add text to clarify that statistics only for 
configurated features would be sent

3.      Statistics Type 27 / 28 clarifications – 
        •       "Number of routes in per-AFI/SAFI marked as stale by any 
configuration"
                •       I think is meant to be specific to Graceful Restart 
(GR) and does not include Long-Lived Graceful Restart (LLGR), as there is a 
separate statistic defined for LLGR.
                •       The text could be "marked as stale by GR events" 
instead of "any configuration” perhaps, as it is the GR events in the presence 
of GR configuration that would lead to marking of stale routes. 
        •       The stale routes are transient, I guess it is the stale route 
count when the GR event occurs, and the corresponding routes get marked stale 
before the replay happens from peer.  
        •       The text from the draft after RFC4724 text below could be 
deleted, it is a bit confusing in this context: 
                •       "Stale refers to a path which has been declared stale 
by the BGP Graceful Restart mechanism as described in Section 4.1 of [RFC4724], 
such as the routes filtered by a remote peer through application of policies 
during a graceful restart."
        •       Please consider making the updates to both GR/LLGR text (stats 
28) per above

4.      Statistics updating the previous RFC stats
        •       For any stat types updating the previously defined stat types 
(Eg: stat 7 with stat 18), please add text that only the updated stats type 
defined in this draft needs to be sent and not both

5.      Additional Statistics:
        Consider including the following four statistics for completeness, as 
they were defined in the other draft that was merged with this one (unless 
authors decided to remove it for a specific reason):

        •       Routes rejected due to reaching the Received-Route Threshold
        •       Routes rejected due to reaching the Received-Route Threshold 
per AFI-SAFI
        •       Routes rejected due to reaching the license-customized 
Received-Route Threshold
        •       Routes rejected due to reaching the license-customized 
Received-Route Threshold per AFI-SAFI

6.      Use Cases: Please consider adding use cases for these statistics, 
briefly describing how network operators plan to utilize them?

        We have the following broad categories of statistics, and it might be 
beneficial to cover how each category is used:

        •       Per RIB-view table route sizes
        •       Accepted/Rejected/Selected route counts
        •       Different route-selection-type counts (stale, primary, backup, 
etc.)
        •       RPKI-related statistics (validated, invalidated, not found)
        •       Threshold-related statistics and others

        Additionally, how often would the operators prefer to receive these 
statistics (e.g., every three minutes)? Please consider making some 
recommendations here, that will be beneficial for scale deployments. 

7.      Implementation Notes: Are there specific insights that implementers can 
share from their experience?
        •       What scale/functional profile was tested? 
                •       Was memory and CPU monitored with and without 
statistics?
                •       Did you observe any impact of statistics at higher 
scale?
        •       What was the frequency of the statistics updates?
        •       Any other relevant information that could be shared ?

Thank you
/snnp
(Prasad)

-----Original Message-----
From: Paolo Lucente <[email protected]> 
Sent: 18 May 2025 23:21
To: [email protected] [email protected] <[email protected]>
Subject: [GROW] Working Group Last Call (WGLC) for 
draft-ietf-grow-bmp-bgp-rib-stats (start 18/May/2025 end 1/Jun/2025)


This email begins a two-week WGLC on:

     Definition For New BGP Monitoring Protocol (BMP) Statistics Types
     https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-bgp-rib-stats/08/

Abstract:

    """
    RFC 7854 defines different BGP Monitoring Protocol (BMP) statistics
    message types to observe events that occur on a monitored router.
    This document defines new statistics type to monitor BMP Adj-RIB-In
    and Adj-RIB-Out Routing Information Bases (RIBs).
    """

Please take time to review this draft and post comments by Jun 1st 2025.

Questions, suggestions, supportive comments, and objections are welcomed.

In parallel there will be another email shortly for the IPR poll.

Paolo
GROW co-chair

_______________________________________________
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]

Reply via email to