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://mailarchive.ietf.org/arch/msg/grow/6pqYmYyy2V7eVuNHkERiLd5qnrM/ . 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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-bgp-rib-stats/



----------------------------------------------------------------------
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]

Reply via email to