Hi, What’s the difference between stats 29 and 31 (also 30 and 32, their per-AFI/SAFI counterparts)?
29: Number of routes currently left before exceeding the received route threshold. 31: Number of routes currently left before exceeding a license-customized route threshold. 29 is marked for Adj-RIB-In and 31 for Adj-RIB-In and Loc-RIB. If 31 applies to Adj-RIB-In, in what way is it different from 29? Is ‘license-customized’ qualifier required at all? The threshold may or may not be governed by a license. — Regards, Dhananjay From: Narasimha Prasad S N (snprasad) <[email protected]> Date: Thursday, 27 November 2025 at 1:40 PM To: [email protected] <[email protected]>, Paolo Lucente <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [GROW] Re: Demux stats (RE: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-16: (with DISCUSS)) Hi Med/Paolo/WG, On the Demux topic, we have a few options when we have stats that could apply to different RIB-views 1- Continue to the existing method as in the earlier RFCs of defining separate 'stats type' for each view (no multiplexing), but when these stats were originally defined, they didn’t know what was coming in future with Multiple RIB-views, so we could improve on this now. 2- If we want to support multiplexing, we have couple of options, NOTE: we need to think about backward compatibility aspect here on older stats, if we as a WG decide to go this route (that consideration is TBD for these options) A- Use per-peer flags for stats type as well making it consistent across msg type, but the con is if we have a stats where the RIB-view doesnot apply, then we would need to ignore the peer flags depending on the stats type B- Continue to ignore peer-flags for stats, but instead leverage the RIB-view TLV for muxing, we originally defined this in https://datatracker.ietf.org/doc/draft-patki-grow-bmp-common-updates/ for Route-Mon message across 4 views and defined stats messages using it as well, also have extended and leveraged this TLV to be used in the GEN message to cover all 5 views https://datatracker.ietf.org/doc/html/draft-sp-grow-bmp-gen-01 This option gives us the max flexibility, where if a RIB-view belongs to In-Pre, In-post, LRIB, Out-pre, Out-post it can be indicated. If it doesnot apply to a certain RIB-view then this TLV need not be included. But yes, it is an additional TLV. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|J|O|P|L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: RIB View value encoding --> I - In-Pre, J - In-post, O-Out-pre, P-Out-post, L-LRIB 3. My preference is not to proceed with the peer-type for demuxing here as it is not extendible to all RIB-views. For the need of this draft peer-type would suffice (as muxing only across LRIB and (In or Out) view is defined), but we as a WG should decide on a more extensible generic option and accordingly adopt that in this draft and future stats types. Thanks /snnp (Prasad) -----Original Message----- From: [email protected] <[email protected]> Sent: 27 November 2025 12:42 To: Paolo Lucente <[email protected]> Cc: [email protected]; [email protected] Subject: [GROW] Demux stats (RE: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-16: (with DISCUSS)) Hi Paolo, all (removing all dst, except grow) I'd like to check this part: > BMP messages include a per-peer header where there are peer flags. > Turning and twisting some of these, one can say whether content of the > BMP message belongs to Adj-Rib-In pre/post policy, Adj-Rib-Out > pre/post policy, Loc-Rib. Of course one can't mix-and-match stats for > different vantage points as part of the same Stats message; one Stats > message per covered vantage point is needed -- sub- optimal but this > is how BMP operates today and, especially for periodic messages, maybe > good enough. As you know the per-peer flags does not apply for stats. Loc-RIB is special as that is handled ta the peer type. When you say "good enough", do you mean that the approach in the draft (assuming restrict type per message) is OK? That is, there is no issue out there and we can park that one? Thank you. Cheers, Med > -----Message d'origine----- > De : Paolo Lucente <[email protected]> > Envoyé : mercredi 26 novembre 2025 01:53 À : Ketan Talaulikar > <[email protected]>; The IESG <[email protected]> Cc : > [email protected]; grow- [email protected]; > [email protected] Objet : Re: [GROW] Ketan Talaulikar's Discuss on > draft-ietf-grow- > bmp-bgp-rib-stats-16: (with DISCUSS) > > Hi Ketan, > > On the two discussion points: > > discuss 1) Complementing answers from Jeff: while it's not the role of > this document or draft-ietf-grow-bmp-path-marking-tlv to make any > definition (ie. route vs path, primary vs backup etc.), we have two > documents that speak about things with a certain degree of affinity: > maybe we can avoid both to use similar terminology independently; we > could explain the terminology in one document (draft-ietf-grow- > bmp-path-marking-tlv would be the place to do that, > IMO) and place a reference in the other and let it re-use the > terminology. > > The immediate con that comes to mind is that we introduce a dependency > among a document already in IESG court over one that has still a bit > of mileage to do in the WG (although i think we are almost done with > it). > > A further idea could be to lock the two documents up by adding a "path > status" field in relevant stats types defined in draft-ietf- > grow-bmp-bgp-rib-stats referencing the path code points defined in > draft-ietf-grow-bmp-path-marking-tlv; the main con i see is that - > guess we would agree on a static format for stats (see next > point) - it would break auto-parsing of stats in a BMP collector. > > discuss 2) There is a couple of points to unpack: > > BMP messages include a per-peer header where there are peer flags. > Turning and twisting some of these, one can say whether content of the > BMP message belongs to Adj-Rib-In pre/post policy, Adj-Rib-Out > pre/post policy, Loc-Rib. Of course one can't mix-and-match stats for > different vantage points as part of the same Stats message; one Stats > message per covered vantage point is needed -- sub- optimal but this > is how BMP operates today and, especially for periodic messages, maybe > good enough. > > On Global vs per-AFI/SAFI messages: where possible i like to favor a > static format, for example every message would be per-AFI/SAFI where > if AFI/SAFI are both set to zero it means it's Global. The pro is that > we would make stats auto-parseable by a collector; the con is that we > would potentially waste 3 bytes per stat TLV -- something we could > further sophisticate, saving auto-parsing, by introducing an innocent > bit saying whether AFI/SAFI will follow or not before the gauge / > value. This would avoid your duplication point, Ketan, and you are > right that currently there is no guidance in this sense -- hence > myself throwing some ideas. > > Paolo > > > On 25/11/25 09:27, Ketan Talaulikar via Datatracker wrote: > > Ketan Talaulikar has entered the following ballot position for > > draft-ietf-grow-bmp-bgp-rib-stats-16: Discuss > > > > When responding, please keep the subject line intact and reply > to all > > email addresses included in the To and CC lines. (Feel free to > cut > > this introductory paragraph, however.) > > > > > > Please refer to > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www. > > ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- > positi > > > ons%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cfc730ee76e6 > 649d > > > 5404d08de2c86221f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638 > 9971 > > > 51780426134%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLj > > > AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% > 7C%7 > > > C&sdata=WLJDaMqIketlbEhWUHoC%2B1dg9L2Yw62DQB5b%2F432tdM%3D&reserve > d=0 > > for more information about how to handle DISCUSS and COMMENT > positions. > > > > > > The document, along with other ballot positions, can be found > here: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > data > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-bmp-bgp-rib- > stats%2F&data=05% > > > 7C02%7Cmohamed.boucadair%40orange.com%7Cfc730ee76e6649d5404d08de2c > 8622 > > > 1f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638997151780455905 > %7CU > > > nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > lAiO > > > iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KkP > gNNy > > XADCI%2F34fK7i9xe%2BL1WNIU0YXK7qZLCCsU4k%3D&reserved=0 > > > > > > > > ---------------------------------------------------------------- > ------ > > DISCUSS: > > ---------------------------------------------------------------- > ------ > > > > Thanks to the authors and the WG for this document. > > > > Note: this ballot has been updated for v16 of the document. The > > previous number of points is retained. Points that have been > addressed are deleted. > > > > Please find below certain points that I would like to discuss. > > > > <discuss-1> Semantics of routes, paths, primary, and backup. > > > > Section 2 of this document says: > > Primary route: A route to a prefix that is considered the best > route > > by the BGP decision process [RFC4271] and actively used for > forwarding > > traffic to that prefix. Backup route: A backup route is eligible > for > > route selection, but it is not selected as the primary route and > is > > also installed in the Loc-RIB. It is not used until all primary > routes > > become unreachable. Backup routes are used for fast convergence > in the event of failures. > > > > Consider an BGP route for destination prefix x/y is a multipath: > > x/y via BGP NH1 (path1) (best) > > via BGP NH2 (path2) (multipath - say ECMP) > > via BGP NH3 (path3) (backup) > > via BGP NH4 (path4) (valid but not best/multipath/backup) > > via BGP NH5 (path5) (invalid - for whatsover reason) > > > > This is a single route. The > best/multipath/backup/valid/invalid/etc > > are qualifiers of its paths. Except for two stats that refer to > paths > > (stale and suppressed), everything is referring to routes. I > would > > like to discuss the semantics of route vs path. It seems to me > like > > some of the stats are for paths and not routes. > > > > In general, I think the use of the terms primary/backup which > are > > related to forwarding plane aspects can be confusing. Instead, > perhaps > > using terms that are more suitable for BGP Loc-RIB would be > better? > > I've suggested some of them above for consideration. Also refer > to > > draft-ietf-grow-bmp-path-marking-tlv - the terms of stats should > be aligned across the BMP documents? > > > > Furthermore, there is a wrong assumption that backup paths are > only > > activated when all primary paths are down. This is very much > implementation dependent. > > Some implementations have a 1:1 provisioning of primary/backup - > where > > the backup would get used when its specific primary goes down - > this > > draws on the FRR notion in the forwarding planes. Refer to the > > definition in draft-ietf-grow-bmp-path-marking-tlv > > > > These clarifications have implications on several of the stats > as they > > are defined currently. > > > > <discuss-2> Section 3 has the following text and Section 4 > introduces > > a table that brings up an interesting aspect. > > > > "This section defines different statistics type for Adj-RIB-In > and > > Adj-RIB-Out monitoring type. Some of these statistics are also > > applicable to Loc-RIB; refer to Section 4 for more details." > > > > For types 24 through 28, they are applicable for both Adj-RIB-In > and Loc-RIB. > > How does one know what is being reported? Can this be clarified? > Seems > > like this is the first document introducing such overloaded > types but > > I don't find the reason why this is being done. There is also a > sort > > of duplication for same stat being both global as well as per > afi/safi > > - is there any guidance on whether only one of them needs to be > > supported (this way avoiding the race conditions and > discrepancies in their totaling)? > > > > It is important to clarify these aspects if this is going to set > a > > precedent/guidance for other similar stats in BMP in future > documents? > > > > > > > > > > > > _______________________________________________ > > 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] _______________________________________________ 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]
