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

["Srivastava, Mukul" <[e-mail]>]

>>>>  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
[MS] I too have suggested that in past. I feel discussions are not converging. I am ok to remove this.


Thanks

Mukul

From: Paolo Lucente <[e-mail]>
Date: Saturday, November 29, 2025 at 12:57 PM
To: Ketan Talaulikar <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/grow/6pqYmYyy2V7eVuNHkERiLd5qnrM/__;!!NpxR!jgm75lbeYnBHk5v45dt23ZCzxjHufZIxAs58VQNxugAThMQIUaTHIHZkoF6L-N2G-GmojqZZI9wXgLs$
. 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NpxR!jgm75lbeYnBHk5v45dt23ZCzxjHufZIxAs58VQNxugAThMQIUaTHIHZkoF6L-N2G-GmojqZZqk7jsQ8$
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-bgp-rib-stats/__;!!NpxR!jgm75lbeYnBHk5v45dt23ZCzxjHufZIxAs58VQNxugAThMQIUaTHIHZkoF6L-N2G-GmojqZZ3suX7LA$
>>
>>
>>
>> ----------------------------------------------------------------------
>> 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]