Hi Med, Paolo, Great, will work on an initial write up to cover the various aspects around this. Will collaborate with you on this Paolo, which we can share with WG afterwards.
We can find the right home for it afterwards based on where we land (separate draft, part of bmpv4 draft if version bump is needed etc) Regards, /snnp (Prasad) -----Original Message----- From: Paolo Lucente <[email protected]> Sent: 04 December 2025 08:30 To: [email protected]; Narasimha Prasad S N (snprasad) <[email protected]>; [email protected] Cc: [email protected] Subject: Re: RIB-view applicability for stats (Was: [GROW] I-D Action: draft-ietf-grow-bmp-bgp-rib-stats-16.txt) Hi Prasad, Agree myself too. Some additional thoughts: As it emerged from the conversation around draft-ietf-grow-bmp-bgp-rib-stats, a relevant point is how to express applicability across RIB-views: using Peer Type/Peer Flag as in rfc7854 and rfc9096 or straightening it all out using the Stats Type, as in rfc8671. Some reconciliation needs to be done there. Including perhaps, as hinted by Jeff in one of his messages, determining how to best retire stale stats types: guess we uniform all to rfc8671 model (what draft-ietf-grow-bmp-bgp-rib-stats does), then we may have to re-define/retire some stats types from rfc7854 and/or rfc9096. I was tending to do the design / guidance as part of draft-ietf-grow-bmp-tlv. But if we determine we ultimately don't depend on a protocol version bump, for example for backward compatibility, we could do this restructuring of Stats as part of a separate document. Paolo On 1/12/25 04:50, [email protected] wrote: > Hi Prasad, all, > >> Stats applicability across RIB-views (Y/N + which RIB-views if Y) is >> another point we should recommend all stats type to include as a >> guideline for better clarity / consistency > > I agree this is worth considering. > > I suggest to decorrelate it from this specific draft as that is beyond the > initial scope set for this draft. > > A more practical approach would be that a volunteer (you :-)) edit a short > draft that covers that point and probably suggest updating the structure of > the registry to include the RIB applicability view: > https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml#s > tatistics-types > > The draft can go through normal WG process to gauge interest and tweak as > appropriate. > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Narasimha Prasad S N (snprasad) <[email protected]> Envoyé : >> vendredi 28 novembre 2025 09:05 À : [email protected] Cc : Paolo Lucente >> <[email protected]>; BOUCADAIR Mohamed INNOV/NET >> <[email protected]>; draft-ietf-grow-bmp-bgp-rib- >> [email protected] Objet : RIB-view applicability for stats (Was: [GROW] >> I-D Action: >> draft-ietf-grow-bmp-bgp-rib-stats-16.txt) >> >> >> Added another topic for discussion for the WG (following Med, to >> start a new thread with a different subject line to facilitate >> focussed discussion 😊) >> >> Hi Paolo/Med/WG, >> >> Stats applicability across RIB-views (Y/N + which RIB-views if Y) is >> another point we should recommend all stats type to include as a >> guideline for better clarity / consistency >> >> Thanks >> /snnp >> (Prasad) >> >> -----Original Message----- >> From: Narasimha Prasad S N (snprasad) >> Sent: 28 November 2025 13:30 >> To: [email protected] >> Cc: [email protected]; Paolo Lucente <[email protected]>; >> [email protected] >> Subject: RE: [GROW] I-D Action: draft-ietf-grow-bmp-bgp-rib-stats- >> 16.txt >> >> Hi Changwang, Authors, >> >> Went thru the latest revision 16 >> >> 1. Addition of a RIB-view scope table is the newer version is >> helpful. We seem to have picked only Adj-RIB-In, Adj-RIB-Out and LRIB >> only, but instead can we please include all 5 variants of RIB-views >> (In-Pre/Post, LRIB, Out-pre/post) and clarify in table and stats type >> of which of the RIB-views do the stats apply to. >> >> 2. Looking at the stats defined as applicable across Adj-RIB-In and >> LRIB, if the answer to 'point C' below is 'Adj-RIB-In' only, then it >> seems to me like, we don’t have a need for muxing of stats in this >> draft. >> >> | 24 | Y | N | Y | >> | 25 | Y | N | Y | >> | 26 | Y | N | Y | >> | 27 | Y | N | Y | >> | 28 | Y | N | Y | >> | 31 | Y | N | Y | >> | 32 | Y | N | Y | >> >> A. These stats would only be applicable after bgp best-path is run >> only in the LRIB view, but it is marked as multiplexed across In- pre >> and lrib >> - Type = 24: (64-bit Gauge) Current Number of routes in per- AFI/SAFI >> selected as primary route. >> - Type = 25: (64-bit Gauge) Current Number of routes in per- AFI/SAFI >> selected as a backup route. >> >> B. Following stats are Adj-RIB-In only (not LRIB) // In-Pre would >> have routes suppressed, not showing up in In-Post >> - Type = 26: (64-bit Gauge) Current Number of routes in per- AFI/SAFI >> suppressed by configured route damping policy. >> >> // In-post, GR event marks them stale (do we want In-pre also here >> ?) >> - Type = 27: (64-bit Gauge) Current Number of routes in per- AFI/SAFI >> marked as stale by Graceful Restart (GR) events. >> - Type = 28: (64-bit Gauge) Current Number of routes in per- AFI/SAFI >> marked as stale by Long-Lived Graceful Restart (LLGR). >> >> C. Stats 29/30 are defined as Adj-RIB-In only, but Stats 31/32 their >> license counterparts are defined to be across LRIB and Adj- RIB-In. >> Do you see the license thresholds being defined for both >> Adj-RIB-In/LRIB ? Dhananjay has asked for more clarity on license >> thresholds in the other thread, u could clarify these points together >> - Type = 31: (64-bit Gauge) Current Number of routes left before >> exceeding a license-customized route threshold. >> - Type = 32: (64-bit Gauge) Current Number of routes in per- AFI/SAFI >> left before exceeding a license-customized route threshold. >> >> 3. Given the recent discussion on the WG mailer about routes/paths, >> multi-path scenario, primary/backup + the latest version updates >> clarifies a few things to avoid different interpretations, but also >> makes some areas more confusing to me, mentioning a few below >> >> - it may be helpful to add a section on multi-path consideration and >> provide more clarity on the definitions around this. We can polish >> this a bit more in the draft across stats types (Eg: For stats 24, >> for ECMP case, we can have multiple paths eligible to be downloaded >> to system RIB - say if this count is 4 for a given prefix, do we >> expect this count to be 1 or 4) >> >> - The term route, path seem to be used interchangeably, sometimes >> route refers to path as well - for example in Type 26, Type 27, Type >> 28, we start the defn with routes but talk about paths later. >> The definition of Primary and Backup route also uses route/path >> interchangeably whilst stats type refers to routes. >> >> - Add-path as in RFC7911 is towards BGP peers, this would be >> independent of multi-path towards RIB. We could have one of these >> enabled without the other (Eg: best-path in HW + add-path towards >> peers) >> >> Thanks >> /snnp >> (Prasad) >> >> >> -----Original Message----- >> From: [email protected] <[email protected]> >> Sent: 25 November 2025 08:52 >> To: [email protected] >> Cc: [email protected] >> Subject: [GROW] I-D Action: draft-ietf-grow-bmp-bgp-rib-stats- >> 16.txt >> >> Internet-Draft draft-ietf-grow-bmp-bgp-rib-stats-16.txt is now >> available. It is a work item of the Global Routing Operations >> (GROW) WG of the IETF. >> >> Title: Advanced BGP Monitoring Protocol (BMP) Statistics >> Types >> Authors: Mukul Srivastava >> Yisong Liu >> Changwang Lin >> Jinming Li >> Name: draft-ietf-grow-bmp-bgp-rib-stats-16.txt >> Pages: 18 >> Dates: 2025-11-24 >> >> 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). >> >> The IETF datatracker status page for this Internet-Draft is: >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> datatracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-bmp-bgp-rib- >> stats%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C71f31632c >> df44acf3e2108de2e54f60f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0 >> %7C638999139617621498%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy >> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ >> %3D%3D%7C0%7C%7C%7C&sdata=GKPEdBK20wBr2xm7oi%2BufNQU4niKuHOthdXOGd >> hEUsU%3D&reserved=0 >> >> There is also an HTMLized version available at: >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-bmp-bgp-rib- >> stats- >> 16&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C71f31632cdf44ac >> f3e2108de2e54f60f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638 >> 999139617666522%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl >> YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D >> %7C0%7C%7C%7C&sdata=MbCKNfr6jj2a6Swk%2BbcMtsJsoa%2FLNK36y1l%2BG5UU >> 4QA%3D&reserved=0 >> >> A diff from the previous version is available at: >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> author-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-grow-bmp-bgp- >> rib-stats- >> 16&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C71f31632cdf44ac >> f3e2108de2e54f60f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638 >> 999139617701427%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl >> YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D >> %7C0%7C%7C%7C&sdata=OX5RiSp3NdF2C89UAHXrJ5BnW4KrnQnwprALWrGrDXA%3D >> &reserved=0 >> >> Internet-Drafts are also available by rsync at: >> rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> GROW mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > ______________________________________________________________________ > ______________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
