-----Message d'origine-----
De : Paolo Lucente <[email protected]>
Envoyé : mercredi 26 novembre 2025 01:53
À : Ketan Talaulikar <[email protected]>; The IESG
<[email protected]>
Cc : [email protected]; grow-
[email protected]; [email protected]
Objet : Re: [GROW] Ketan Talaulikar's Discuss on draft-ietf-grow-
bmp-bgp-rib-stats-16: (with DISCUSS)
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
www.
ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-
positi
ons%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cfc730ee76e6
649d
5404d08de2c86221f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638
9971
51780426134%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi
IwLj
AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%
7C%7
C&sdata=WLJDaMqIketlbEhWUHoC%2B1dg9L2Yw62DQB5b%2F432tdM%3D&reserve
d=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
data
tracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-bmp-bgp-rib-
stats%2F&data=05%
7C02%7Cmohamed.boucadair%40orange.com%7Cfc730ee76e6649d5404d08de2c
8622
1f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638997151780455905
%7CU
nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI
lAiO
iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KkP
gNNy
XADCI%2F34fK7i9xe%2BL1WNIU0YXK7qZLCCsU4k%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]
