Paolo, See the implementation report in section 9. Renumbering would be harmful at this point.
The main consideration for 24/25 is that since this is coming from a standards action range IANA will want a reference for the two code points that are being omitted from the upcoming RFC from this document. I had suggested privately to Med that the last version containing those numbers be that reference and otherwise let the usual early assignment timers at IANA run. If the next document covering those code points does indeed happen "soon", the references will be updated to the new document. -- Jeff > On Dec 3, 2025, at 9:10 PM, Paolo Lucente <[email protected]> wrote: > > > Hi Med, Authors, > > Minor feedback: as part of -17 we are defining all metrics except 24-25. The > metrics > 25 were not renumbered; it makes sense not to have such a hole and > renumber all metrics > 25 as N-2. > > Paolo > > > On 3/12/25 14:34, [email protected] > <mailto:[email protected]> wrote: >> Hi all, >> Thank you Jeff for confirming and also for the great help/inputs to clarify >> various points. >> @all: All DISCUSSes are now cleared for the document. I will wait till mid >> next week to see to let the WG check the latest version. If I don’t hear any >> concern by then, I will send the doc to the RFC Editor. >> Cheers, >> Med >> *De :*Jeffrey Haas <[email protected]> >> *Envoyé :* mercredi 3 décembre 2025 18:21 >> *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> >> *Cc :* Paolo Lucente <[email protected]>; Ketan Talaulikar >> <[email protected]>; The IESG <[email protected]>; >> [email protected]; [email protected]; >> [email protected]; [email protected] >> *Objet :* Re: [GROW] Ketan Talaulikar's Discuss on >> draft-ietf-grow-bmp-bgp-rib-stats-16: (with DISCUSS) >> 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] >> <mailto:[email protected] >> <mailto:[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]> >> <mailto:[email protected] <mailto:[email protected]>>> >> Envoyé : samedi 29 novembre 2025 18:57 >> À : Ketan Talaulikar <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>; The >> IESG >> <[email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>> >> Cc :[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>; grow- >> [email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>;[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>; >> draft-ietf-grow-bmp-path-marking- >> [email protected] <mailto:[email protected]> <mailto:[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> >> <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/> >> <http://mailarchive.ietf.org/ >> <http://mailarchive.ietf.org/>>%2Farch%2Fmsg%2Fgrow%2F6pqYmYyy2V7eVuNHkERiLd5 >> qnrM%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com >> <http://40orange.com/> >> <http://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> >> <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/> >> <http://ietf.org/ >> <http://ietf.org/>>%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling- >> ballot-posi >> tions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com >> <http://40orange.com/> >> <http://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> >> <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/> >> <http://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/> >> <http://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] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> _______________________________________________ >> GROW mailing list -- [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> >> <mailto:[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]> >> <mailto:[email protected] <mailto:[email protected]>> >> To unsubscribe send an email [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[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]
