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