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

[Ketan Talaulikar <[e-mail]>]

Hi All,

I have been following the discussion regarding my DISCUSS points on
draft-ietf-grow-bmp-bgp-rib-stats-16.

Regarding Discuss-1 (Route vs. Path Semantics)

I agree with the suggestion to move types 24 and 25 (Primary/Backup route
counts) from this document to draft-ietf-grow-bmp-path-marking-tlv. This
will allow the Working Group to fully deliberate the semantics of "route"
vs. "path," especially concerning Add-Paths and multipath aspects.

Assuming this is the chosen path:

1. Do Types 26, 27, and 28, which also refer to a path, also need to be
moved to the path-marking document for consistency?
2. For clarity across all BMP stats, does the document confirm that "route"
is functionally equivalent to "prefix/destination"? My interpretation of
existing stats suggests this is the case.

Addressing the removal of 24/25 (and potentially 26-28) would resolve my
discuss-1 ballot point.

Regarding Discuss-2 (Statistic Scope and Clarity)

Regarding discuss-2, I agree that establishing general guidance for BMP
evolution is a broader WG issue. Focusing solely on this document, the
following points need clarification:

a) Statistic View Clarity: Do all statistic descriptions accurately
indicate the view (Adj-RIB-In, Adj-RIB-Out, Loc-RIB)? The document is
sometimes ambiguous. Specifically, Types 22, 23, and 26 through 34 do not
explicitly state Adj-RIB-In, and Types 38, 39, and 40 do not explicitly
state Adj-RIB-Out. The descriptions should reflect the scope since the
Section 4 table is not being registered with IANA.

b) Loc-RIB Scoping: Types 26, 27, 28, 31, and 32 are applicable to the
Loc-RIB. Should new, dedicated stat types be defined for the Loc-RIB view
to maintain consistency with previous RFC conventions, or should the
existing type descriptions be updated to capture the Loc-RIB view as well
explicitly?

c) Global vs. Per-AFI/SAFI Types: Are both global and per-AFI/SAFI types
defined for all applicable statistics? Why are some types (e.g., 26, 27,
28) defined as per-AFI/SAFI only, without an accompanying global type?

Addressing these specific points and making necessary updates would resolve
my discuss-2 ballot point, which, in my view, would make the document ready
for publication.

Thanks,
Ketan

On Sun, Nov 30, 2025 at 12:09 AM Srivastava, Mukul <[e-mail]>
wrote:

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