Note for the archives: With -17 and stats 24/25 covering primary/backup behavior being removed, and additional clarification on the views for each counter, my comments are resolved.
-- Jeff > On Dec 3, 2025, at 9:44 AM, [email protected] wrote: > > Hi all, > > Thank you all for the constructive discussion. > > The authors will release SOON a new version that offloads these two types to > the marking TLV spec, better clarify the applicability of the other types, > and some other minor edits. > > The other points are beyond the scope of this spec. Specifically, no changes > will be made in this draft to per AFI/SAFI and how we demux stats. > > Cheers, > Med > >> -----Message d'origine----- >> De : Paolo Lucente <[email protected] <mailto:[email protected]>> >> Envoyé : samedi 29 novembre 2025 18:57 >> À : Ketan Talaulikar <[email protected] <mailto:[email protected]>>; >> The IESG >> <[email protected] <mailto:[email protected]>> >> Cc : [email protected] >> <mailto:[email protected]>; grow- >> [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]>; draft-ietf-grow-bmp-path-marking- >> [email protected] <mailto:[email protected]> >> Objet : [GROW] Re: Ketan Talaulikar's Discuss on draft-ietf-grow- >> bmp-bgp-rib-stats-16: (with DISCUSS) >> >> >> >> Hi Ketan, Med, Authors, >> >> Following up on the two open discussion points: >> >> discuss 1) The only two defined stats that touch the concept of >> "primary" and "backup" are types 24 and 25; in draft-ietf-grow- >> bmp-path-marking-tlv path statuses are being defined -- and there >> is more to it than just primary and backup. Evolving from my >> previous email, i propose that these two stat types are removed >> from draft-ietf-grow-bmp-bgp-rib-stats mainly for consistency to >> draft-ietf-grow-bmp-path-marking-tlv and to avoid dependencies >> among the two documents; instead we can define stats for all >> defined path status in the path marking document; this, i guess, >> would also close this discussion point; >> >> discuss 2) On the specific guidance point for future documents, >> please see >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F> >> mailarchive.ietf.org >> <http://mailarchive.ietf.org/>%2Farch%2Fmsg%2Fgrow%2F6pqYmYyy2V7eVuNHkERiLd5 >> qnrM%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com >> <http://40orange.com/>%7Cf83b5eb119 >> cd4e3faf7208de2f70d6d5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0% >> 7C639000358873193586%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd >> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% >> 3D%3D%7C0%7C%7C%7C&sdata=2Wcuk2TYx0ybNZLboIuVjHoMs7uLKyYkF%2Bp4Oa7 >> 5BIM%3D&reserved=0 >> . Away from the greasy technical details, in short, the BMPv4 >> document would be a more suitable place than this document where >> to provide guidance and straighten a few aspects out. >> >> Paolo >> >> >> On 25/11/25 21:52, Paolo Lucente wrote: >>> >>> 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 >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F> >> www >>>> .ietf.org >>>> <http://ietf.org/>%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling- >> ballot-posi >>>> >> tions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com >> <http://40orange.com/>%7Cf83b5eb11 >> 9cd >>>> >> 4e3faf7208de2f70d6d5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C >> 639 >>>> >> 000358873221044%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl >> YiO >>>> >> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C >> 0%7 >>>> >> C%7C%7C&sdata=%2FvsOouJwIl8lBLY1cbMsb%2F%2FwBSzDuG4PUjFPg%2FdnbxM% >> 3D& >>>> reserved=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 >> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F> >> dat >>>> atracker.ietf.org >>>> <http://atracker.ietf.org/>%2Fdoc%2Fdraft-ietf-grow-bmp-bgp-rib- >> stats%2F&data=0 >>>> >> 5%7C02%7Cmohamed.boucadair%40orange.com >> <http://40orange.com/>%7Cf83b5eb119cd4e3faf7208de >> 2f7 >>>> >> 0d6d5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639000358873237 >> 184 >>>> >> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM >> CIs >>>> >> IlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat >> a=F >>>> VkXH0mnULoMHa2xlZeM0dbVvTg%2Fqid%2BQUK5SI5XQIo%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] >> >> _______________________________________________ >> 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] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
