[GROW] Re: Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-stats-16: (with DISCUSS)

[Jeffrey Haas <[e-mail]>]

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, [e-mail] 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 <[e-mail] <mailto:[e-mail]>>
>> Envoyé : samedi 29 novembre 2025 18:57
>> À : Ketan Talaulikar <[e-mail] <mailto:[e-mail]>>; The IESG
>> <[e-mail] <mailto:[e-mail]>>
>> Cc : [e-mail] <mailto:[e-mail]>; grow-
>> [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; draft-ietf-grow-bmp-path-marking-
>> [e-mail] <mailto:[e-mail]>
>> 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 -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>> 
>> _______________________________________________
>> GROW mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> ____________________________________________________________________________________________________________
> 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 -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>