Hi Changwang/Mukul/co-authors,
Thanks for posting the updated version 16. It addresses all of my comments
and one of the discussion points. There are two discussion points that
remain open. Let us focus on the first one.
The updated definitions of the terms are not very helpful and seem more
confusing to me.
Let us step back and look at the following example that I've provided in my
ballot (with 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 whatsoever reason)
Lets focus on the LocRIB view for simplicity since the stats type 24 and 25
apply to it. To me, x/y is a route - i.e., above is a single route.
However, it has multiple paths associated with it, each with its
characteristics.
So, my question to the authors and the WG (especially the operators) is
what are the statistics of interest for their monitoring.
a) If counting routes, then x/y will get accounted as 1 against both
primary and backup because it has both those paths.
b) if counting paths, then x/y will count towards 2 primary paths (path1
and path2) and will count 1 towards backup paths (path3).
If the WG is able to agree and converge on the semantics, then we can work
on the text for the terms to be used and their definitions as a follow-on.
The point that I am trying to make is that the definition of terms and the
stats type are clear and cover the scenario of multiple paths.
Thanks,
Ketan
On Tue, Nov 25, 2025 at 5:58 PM Ketan Talaulikar via Datatracker <
[email protected]> 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]
