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

[Ketan Talaulikar <[e-mail]>]

Hi Mukul,

Yes, I also think that the first DISCUSS point is the major one left and I
get the impression that we are talking past each other on that one. The
second DISCUSS point is also open but that is broader and beyond just this
document - I'd like to see the WG discuss that.

In the meantime, I'll take a pause on this until an update with all the
other changes discussed is posted. We can then resume the discussion
therefrom.

Thanks,
Ketan


On Sat, Nov 22, 2025 at 3:53 AM Srivastava, Mukul <[e-mail]>
wrote:

> Hi Ketan
>
> Yes, it would be better if you make a list of things that you feel are
> blocking and pending from our end.
> I feel the main discussion point that is pending is about the
> Primary/Backup path. Rest all are kind of settled.
>
> Pls see my response below.
>
> KT2> Types 24 and 25 are also applicable to the Loc-RIB per the table in
> section 4. This is a side-track - but this demonstrates the challenges with
> the current approach of defining the same stat type across multiple views.
> Back to the point - how does one know at Adj-RIB-in whether a path is
> primary or backup? Does that determination not take place during best-path
> computation? To be, these stats are really most applicable and valuable at
> Loc-RIB after best-path is done.
> MS>> For Adj-RIB-in view, paths are routes. How a router knows in
> Adj-RIB-in whether a route is primary or backup, is implementation detail.
> Yes that determination takes plan during path computation, but an
> implementation, can keep a record/mark in its rib-in view which can help it
> to determine if that route is primary or backup.
>
> KT2> For the Adj-RIB-in/out, I see why one may look at them as simply as
> "routes". How does that work when doing ADD-PATHS? What are the consumers
> (operators) looking for in the case of ADD-PATHS? Route counts or path
> counts or both?
>
> MS>> We are  talking Adj-RIB-in only (no Adj-RIB-out for Primary/backup
> case in this draft). Again the how part is implementation detail. For
> Adj-RIB-in, the router will receive those routes with different path-id
> from a specific BGP peer. If any of those routes are selected for data
> forwarding, the implementation has to keep track to find such route in
> adj-rib-in view for this specific peer. All such routes from this peer will
> be reported in stats count for this peer.
>
>
> KT2> I guess for session-restarts, there would be an up/down message so
> that should not be an issue. For others, I haven't looked myself and so be
> it. The thing to clarify here is that you are looking for both producer and
> collector to log these anomalies (btw, I like the term anomaly in this
> context) - can you please update accordingly?
>
> MS>> Ok we will add this for producer and collectors.
>
>
> Thanks
> Mukul
>
> *From: *Ketan Talaulikar <[e-mail]>
> *Date: *Friday, November 21, 2025 at 8:05 AM
> *To: *Srivastava, Mukul <[e-mail]>
> *Cc: *linchangwang (RD) <[e-mail]>, The IESG <
> [e-mail]>, [e-mail] <
> [e-mail]>,
> <[e-mail]>, [e-mail] [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> *Subject: *Re: Ketan Talaulikar's Discuss on
> draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)
>
> Hi Mukul,
>
> Please check inline below for responses with KT2.
>
> I see that some of the previous conservations are not responded to, which
> leaves them in a hung state where I don't know if we converged or they are
> still open. Can you please clarify? I would like to snip out points where
> we have converged as this discussion progresses (if that works for you).
>
>
> On Fri, Nov 21, 2025 at 3:47 AM Srivastava, Mukul <
> [e-mail]> wrote:
>
> Hi Ketan
>
> Pls see inline with “MS1>” tag.
>
> Thanks
> Mukul
>
> *From: *Ketan Talaulikar <[e-mail]>
> *Date: *Thursday, November 20, 2025 at 5:42 AM
> *To: *Srivastava, Mukul <[e-mail]>
> *Cc: *linchangwang (RD) <[e-mail]>, The IESG <
> [e-mail]>, [e-mail] <
> [e-mail]>,
> <[e-mail]>, [e-mail] [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> *Subject: *Re: Ketan Talaulikar's Discuss on
> draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)
>
> Hi Mukul/Changwang,
>
> Thanks for your responses. Please check in line below for my follow-up and
> clarifications.
>
> I am also top-posting one point related to the new text updates. Sec 3.1 "The
> AFI/SAFI are used to identify network layer protocols and associated
> routing information. " ... not sure what network layer protocols are
> identified here. I would suggest just deleting that sentence since it is
> not necessary.
> MS1> Sure that looks extra and can be removed.
>
> Please also include the clarification text from Jeff Haas indicating that
> only those AFI/SAFIs that have something to report need be included in the
> BMP messages. That may be important for collector implementations.
> MS1> Yes that will be added.
>
>
> KT2> Thanks. Please let me know once those 2 updates are posted.
>
>
>
> On Thu, Nov 20, 2025 at 5:09 AM Srivastava, Mukul <
> [e-mail]> wrote:
>
> Forwarding changwang response to wider audience for visibility.
>
> Ketan,
>
> Please review -15 version published and see if some of the comments has
> been addressed.
>
> My response [MS] in inline.
>
> Thanks
> Mukul
>
> *From: *linchangwang (RD) <[e-mail]>
> *Date: *Wednesday, November 19, 2025 at 7:53 AM
> *To: *Ketan Talaulikar <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> Srivastava, Mukul <[e-mail]>
> *Subject: *Re: OFFLIST Re: Ketan Talaulikar's Discuss on
> draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)
>
> Hi Ketan,
>
>
>
> See the reply from [Changwang] below.
>
>
>
> ----------------------------------------------------------------------
>
> DISCUSS:
>
> ----------------------------------------------------------------------
>
>
>
> Thanks to the authors and the WG for this document.
>
>
>
> 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.
>
> [MS] My understanding is all the stats is for routes and noth paths. Pls
> point out which stats you think is for the paths .
>
>
> KT> To start with, primary/backup are characteristics of 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?
>
>  [MS] I agree that the primary and backup are confusing and no matter how
> much we want to clarify in this document, it may still be confusion. Also
> this is not the right document to define such terms.
>
> If you know any standard which clarifies these terms (Primary/Backup), we
> can open to reference it and update our document accordingly.  I would
> propose to define these stats as active/inactive route stats. Primary route
> —> Active route. Backup route —> Inactive route stats. I feel active and
> inactive routes may be less confusion to most people. I am also open to
> move this out of the spec for future work.
>
>
> KT> It is a problem if this spec is published without the semantics being
> specified correctly and clearly. It affects interoperability and in some
> ways defeats the purpose. It is a question for the WG whether it wants to
> clarify/correct the stats defined in previous RFCs and whether they refer
> to paths or routes (I haven't reviewed them closely - but many of them
> indeed refer to routes). And these terms are not very complex and are well
> understood. I have already pointed to
> https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-path-marking-tlv/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-path-marking-tlv/__;!!NpxR!g2eKFrptmi7HMbQIAAkZ_fyBTgiW1UjzkyAV_-FwXEI1ZNn4Glwr6dRvAK4AcPymBLlELavb-JAq5fhmNCirU2zR$> which
> is a WG document. Use/leverage that. I will argue that this aspect needs to
> be clarified in this document to apply to the stats in it and also to guide
> future stats. I can see things falling apart the moment there is a request
> for getting stats for multipath, ADD-PATHS, etc. Let us clarify it in this
> document.
>
> MS1>I looked at the path-marking TLV draft and feel that we can’t use
> “Paths” concept in this draft. We have to stick at the “Route” level.
> BMP statistics is for a BGP peer and each stats type provides a rib-view
> of that one peer.
> BMP stats type 24 and 25 are for Adj-rib-in.
>
>
> KT2> Types 24 and 25 are also applicable to the Loc-RIB per the table in
> section 4. This is a side-track - but this demonstrates the challenges with
> the current approach of defining the same stat type across multiple views.
> Back to the point - how does one know at Adj-RIB-in whether a path is
> primary or backup? Does that determination not take place during best-path
> computation? To be, these stats are really most applicable and valuable at
> Loc-RIB after best-path is done.
>
>
>
> This means this stats is for all the routes received from a specific BGP
> peer. In the ECMP/multipath case, the route from other BGP peers might be
> contributing as other legs/paths for data forwarding. We don’t want to
> count those  paths which  come from any other BGP peer for this BGP peer
> for which stats is being reported.
>
>
> KT2> For the Adj-RIB-in/out, I see why one may look at them as simply as
> "routes". How does that work when doing ADD-PATHS? What are the consumers
> (operators) looking for in the case of ADD-PATHS? Route counts or path
> counts or both?
>
>
>
>
> 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.
>
>
>
> [Changwang] Please review the modifications to the document attached
> earlier. For "prefix," "router," and "path," no clear references are
> currently available. When a prefix has multiple paths, each path is
> considered a route.
>
>
> KT> Where is that stated? And the context (or view) is also important.
> Consider the example that I gave above for Loc-RIB and also consider
> ADD-PATHS with Adj-RIB-In/Out.
>
>
> As defined in RFC 9069, Stat Type = 8: (64-bit Gauge) Number of routes in
> Loc-RIB. In the Loc-RIB, multiple equivalent next hops from multiple
> neighbors may exist for routes. In this context, the description refers to
> "routes," and under multipath conditions, multiple paths should also be
> counted.
>
>
> KT> I am missing something here. The following is what I see in RFC9069 -
> https://www.rfc-editor.org/rfc/rfc9069.html#section-5.6
> <https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9069.html*section-5.6__;Iw!!NpxR!g2eKFrptmi7HMbQIAAkZ_fyBTgiW1UjzkyAV_-FwXEI1ZNn4Glwr6dRvAK4AcPymBLlELavb-JAq5fhmNMsWRBOG$> ...
> I read that stat to indicate the number of prefixes with at least one valid
> path (which is what is called routes).
>
>
>    - Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB.
>    - Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The value
>    is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gauge.
>
>
>
> Therefore, the statistics for the "primary route" in this document
> correspond to the statistics of the "selected path" you listed.
>
> Regarding the "backup path," it is not the case that it only becomes
> active after all primary paths fail. Inappropriate descriptions have been
> removed.
>
> Please review the current modifications to see if there are any issues. If
> you have better suggestions, I would appreciate them. Thank you.
>
>
> KT> First, primary/backup is about path attributes and not routes. Please
> look at
> https://www.ietf.org/archive/id/draft-ietf-grow-bmp-path-marking-tlv-04.html#section-3.1
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-grow-bmp-path-marking-tlv-04.html*section-3.1__;Iw!!NpxR!g2eKFrptmi7HMbQIAAkZ_fyBTgiW1UjzkyAV_-FwXEI1ZNn4Glwr6dRvAK4AcPymBLlELavb-JAq5fhmNCFMO4xK$> -
> can you use that? I find those definitions much better. Sadly, they are
> placed in the IANA considerations section which is not appropriate and they
> should be in the normative text of the draft.
>
>
>
>
>
>
> <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?
>
>
>
> [Changwang] Section 3.1 adds a description of the statistics format and
> explains how the LOC-RIB is encapsulated. Additionally, Section 5.1
> includes: "When these statistics apply to the Loc-RIB view, the Peer Type
> in the Per-Peer Header of the corresponding BMP Statistics Report Message
> MUST be set to 3."
>
>
>
> [MS] As Changwang mentioned above, I hope how this stats would be reported
> for Loc-RIB peer is clear in our latest document.
>
> I don’t see any issue with duplication for same stat being used for both
> global as well as per afi/safi. This spec defines the stats which if
> implemented, will provide a total count (sum across afi/safi) and
> individual afi/safi count view to the collector. Vendors can chose what
> they want to implement. I don’t think we can provide any guidance what
> should be implemented. That is vender’s implementation detail.
>
>
> KT> Thank you for the new section 3.1 - it partially addresses my comment.
> You have clarified about the demuxing based on the Peer Type for Loc-RIB.
> However, there is nothing like that available for Adj-RIB-In/Adj-RIB-Out
> and their variants (pre/post policy). This results in a large
> multiplication of essentially the same stat type for all those views - only
> the Loc-RIB stands out as a sore exception with its own unique "peer-type"
> context at the top-level header. Is this the design blueprint that the WG
> wants to follow for defining BMP Stats? That is the larger question that I
> am asking the WG to discuss. There is no issue with the global and
> per-afi/safi definitions (the recent clarifications are welcome) - the
> point is whether this is another guidance now for all stat types to be now
> of two variants - global and per-afi/safi?
> MS1> Refer to my other email. We can clarify which stats is for what
> monitoring type.
>
>
> KT2> Ack - I've responded to it.
>
>
>
> KT> I am basically looking for some design, guidance and consistency in
> how stats are being introduced in BMP. Bringing this up in the context of
> this document for this set of authors is perhaps unfortunate - this
> question is really to the WG as a whole. And a follow-up question is where
> would the WG like to document this guidance/design approach - this document
> or somewhere else?
>
>
>
> <discuss-3> Section 5 - Operational considerations - is not entirely
> operational considerations. There is reference to "implementations" in
> several places and it is not clear if this is on the router side or the
> collector/monitoring side - this needs to be clarified so that expectations
> on either side implementations are clear.
>
>
>
> As an example: "Implementations MUST track discontinuities and log this
> information." - which side is this for?
>
> [MS] The latest version address this.
>
>
> KT> I find the use of the term "operators" strange. How about BMP Stats
> producer and collector? They are both implementations. It is not so that
> operators have to build their own collectors - they may be using some off
> the shelf or open source collector implementations as well? To me, the
> split into sections 5.1 and 5.2 are strange and not what I was asking for.
> My point was that several of these were implementation considerations -
> some on the producer and some on the collector side.
> MS1> Yes this can be updated to use producer and collector.
>
>
> KT2> Thanks. Please let me know once that is posted.
>
>
>
> KT> The latest version puts the onus on the routers producing BMP Stats - "Implementations
> MUST track discontinuities and log this information." OK. So routers will
> generate syslogs. How easy would it be for the collectors to retrieve this
> information via syslogs and correlate with what they are getting from the
> BMP feed. I would have expected this to get signaled or indicated within
> the BMP feed itself? I haven't checked myself but I would expect there to
> be something already within BMP for such situations?
>  MS1> I am not aware if there is currently any provision to do so via BMP
> message. There are some work-in-progress  which may provide such
> signaling. For now, I think it is ok for producer and collector to log such
> anomaly for manual inspection.
>
>
> KT2> I guess for session-restarts, there would be an up/down message so
> that should not be an issue. For others, I haven't looked myself and so be
> it. The thing to clarify here is that you are looking for both producer and
> collector to log these anomalies (btw, I like the term anomaly in this
> context) - can you please update accordingly?
>
>
>
> Several aspects are not really operational consideration but
> implementation considerations. Please consider a "Procedures" section for
> documenting some of those aspects.
>
>
>
> As an example, how is this text an operational consideration "Some
> statistics are dependent on feature configurations, such as GR, LLGR, and
> RPKI, so the corresponding statistics are only sent when these features are
> enabled. This statistics include Type 24, 25, 26, 27, 28, 29, 30, 31, 32,
> 33, 34, 35, 36, 37, 39, 40, 41, 42, and 43."
>
>  [MS] I see this as an operation consideration for implementing this stats
> at producer side.
>
>
> KT> They seem more like protocol procedures and implementation
> considerations to me.
>  MS1> We can create a separate section for implementation consideration
> if that seems appropriate.
>
>
> KT2> Yes please. I see operational considerations mainly tailored towards
> operators - users of producer and collector implementations. And
> implementation considerations mainly tailored towards developers of routers
> and collectors. The two sets can and do overlap.
>
>
>
>
> Another example is "A BMP implementation MUST ignore unrecognized
> stat types upon receipt and MUST exclude unsupported stat types upon
> transmission." ...
>
> this is a normative protocol behavior that is burried in the Operational
> Considerations section.
>
>  [MS] I agree and we can remove this statement.
>
>
> KT> I didn't ask for the removal of the statement and I am glad that it
> has been moved into the new section 3.1 where it is more apt. Just one part
> - excluding the unsupported stat types upon transmission - is obvious (what
> else can it do). Perhaps remove that part? But otherwise good with this.
> Thanks.
>  MS1> ok we can remove that.
>
>
> KT2> Thanks.
>
> Thanks,
> Ketan
>
>
>
>
> "Operators MAY consider rate-limiting statistic updates to minimize
> performance impact on control-plane processes." - why is this not at least
> a SHOULD and perhaps even a MUST?
>
> [MS] This can be updated to “should"
>
>
>
> [Changwang] Divide Chapter 5 into 5.1 and 5.2, where 5.1 corresponds to
> the generation and processing of statistics, and 5.2 corresponds to the
> implementation.
>
>
> KT> Please see my previous comments. This is not what I had asked for and
> is more confusing at least for me.
>
>
>
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
>
> COMMENT:
>
> ----------------------------------------------------------------------
>
>
>
> I note that the WGLC for this document was not cross-posted to the IDR WG
> for soliciting review as required by the GROW WG charter. I hope this can
> be avoided going forward.
>
>
>
> I support the DISCUSS positions of both Eric and Gunter. Some of their
> points are related to the points that I have raised in my ballot as well.
>
>
>
> I also have some comments/suggestions that I hope will help improve the
> document.
>
>
>
> 1) Type = 37: (64-bit Gauge) Current number of routes in per-AFI/SAFI
> post-policy Adj-RIB-In not found by verifying route origin AS number
> through the ROA of RPKI [RFC6811]. The value is structured as: 2-byte AFI,
> 1-byte SAFI, followed by a 64-bit Gauge.
>
>
>
> The phrase 'not found by verifying ...' is confusing. I assume this refers
> to routes that didn't find any match in the RPKI cache? If so, please
> clarify.
>
> This also applies to type 43.
>
>
>
> 2) Type = 39: (64-bit Gauge) Current number of routes refused to be sent
> by exceeding the maximum AS_PATH length supported by the local
> configuration.
>
>
>
> The phrase 'refused to be sent ...' is confusing. Perhaps you mean routes
> that were not sent because ... This also applies to type 40.
>
>
>
> [Changwang] Modified in the new version..
>
>
> KT> Thank you. All good here.
>
> Thanks,
> Ketan
>
>
>
>
>
>
>
>
>
> Thanks,
>
> Changwang
>
>
>
>
>
> *发件人:* Ketan Talaulikar <[e-mail]>
> *发送时间:* 2025年11月19日 20:22
> *收件人:* linchangwang (RD) <[e-mail]>
> *抄送:* [e-mail]; Srivastava, Mukul <
> [e-mail]>
> *主题:* Re: OFFLIST Re: Ketan Talaulikar's Discuss on
> draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)
>
>
>
> *温馨提示：* 此邮件来自公司外部，请核实发件人信息，慎点链接与附件。This is an external email. Please
> verify the sender's information and proceed with caution when clicking
> links or downloading attachments.
>
>
>
> Hi Changwang,
>
>
>
> This is hard for me to check/review without a discussion as I don't
> understand the authors' position on the points that I've raised. I can take
> a look at the changes as we conclude our discussions on the individual
> points.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Wed, Nov 19, 2025 at 5:32 PM linchangwang <*[e-mail]
> <[e-mail]>*> wrote:
>
> Hi Ketan,
>
>
>
>
>
> Thank you for your prompt and insightful review and suggestions.
>
>
>
> Mukul and I have revised the document according to your feedback. Please
> refer to the attached file for details.
>
>
>
> The document has not been submitted yet.
>
>
>
> Could you please review it in advance to see if there are any additional
> comments? Thank you.
>
>
>
>
>
> Thanks,
>
> Changwang
>
>
>
>
>
> *发件人:* Ketan Talaulikar <*[e-mail] <[e-mail]>*>
> *发送时间:* 2025年11月19日 15:48
> *收件人:* *[e-mail] <[e-mail]>*
> *抄送:* The IESG <*[e-mail] <[e-mail]>*>; *[e-mail]
> <[e-mail]>*; *[e-mail]
> <[e-mail]>*; *[e-mail] <[e-mail]>*; *[e-mail]
> <[e-mail]>*
> *主题:* Re: Ketan Talaulikar's Discuss on
> draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)
>
>
>
>
>
> Thanks Med.
>
>
>
> Hi Authors/WG,
>
>
>
> Right now, we have duplication of stat types for global and per afi/safi.
> We also have the same stat being duplicated for different "views" in some
> cases and in other cases the same stat being demuxed based on the mode. All
> of this is happening in this document.
>
>
>
> The part about guidance for further stats is for the WG to document its
> design practice/approach that can guide further stats. This way, there is a
> consistent approach (keeping the existing/old stats aside perhaps). Unlike
> other documents, this one is very much focussed on stats and seemed to me
> like a good place for the WG to put in place guidance.
>
>
>
> And this is just me asking the authors and WG to discuss if these aspects
> have been considered and if not, then should they be as part of this
> document?
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Wed, Nov 19, 2025 at 12:34 PM <*[e-mail]
> <[e-mail]>*> wrote:
>
> Hi Ketan,
>
>
>
> My comment was to clarify that there is no demuxing issue with using the
> same type as we do have a new peer type defined for Loc-RIB in RFC9069
> (under the per peer header). I agree that it would be helpful to include a
> brief reminder of how this is expected to work, though.
>
>
>
> The other points you mentioned are good ones to discuss. Thanks.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Ketan Talaulikar <*[e-mail] <[e-mail]>*>
> *Envoyé :* mardi 18 novembre 2025 18:16
> *À :* BOUCADAIR Mohamed INNOV/NET <*[e-mail]
> <[e-mail]>*>
> *Cc :* The IESG <*[e-mail] <[e-mail]>*>; *[e-mail]
> <[e-mail]>*; *[e-mail]
> <[e-mail]>*; *[e-mail] <[e-mail]>*; *[e-mail]
> <[e-mail]>*
> *Objet :* Re: Ketan Talaulikar's Discuss on
> draft-ietf-grow-bmp-bgp-rib-stats-14: (with DISCUSS and COMMENT)
>
>
>
>
>
> Hi Med,
>
>
>
> By setting precedent, I was referring to the same stat type being used in
> different modes/views. RFC9069#section-5.6 does define stat types only for
> Loc-RIB? So, looking for some clarification on how the same type can be
> used for different views and if this was the recommended approach going
> forward instead of having different stat types for the same thing in
> different views.
>
>
>
> You have also misread or misunderstood what I have said about the per
> afi/safi thing.
>
>
>
> I'll wait for the authors to respond.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> On Tue, Nov 18, 2025 at 10:13 PM <*[e-mail]
> <[e-mail]>*> wrote:
>
> Hi Ketan,
>
> I trust the authors will follow soon.
>
> One quick comment on your second discuss point: this is does not set a
> precedent. Please refer to rfc9069#section-5.6 and more generally to that
> RFC for Loc-RIB matters.
>
> Also, per per-AFI/SAFI is not specific to this spec (see the base spec).
> The Ops section includes some aspects to control which stats to send, but I
> think that can me tweaked for better clariy.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Ketan Talaulikar via Datatracker <*[e-mail]
> <[e-mail]>*>
> > Envoyé : mardi 18 novembre 2025 17:03
> > À : The IESG <*[e-mail] <[e-mail]>*>
> > Cc : *[e-mail]
> <[e-mail]>*; grow-
> > *[e-mail] <[e-mail]>*; *[e-mail] <[e-mail]>*; *[e-mail]
> <[e-mail]>*
> > Objet : Ketan Talaulikar's Discuss on draft-ietf-grow-bmp-bgp-rib-
> > stats-14: (with DISCUSS and COMMENT)
> >
> >
> > Ketan Talaulikar has entered the following ballot position for
> > draft-ietf-grow-bmp-bgp-rib-stats-14: 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.)
> >
> >
> > ------------------------------------------------------------------
> > DISCUSS:
> > ------------------------------------------------------------------
> >
> > Thanks to the authors and the WG for this document.
> >
> > 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?
> >
> > <discuss-3> Section 5 - Operational considerations - is not
> > entirely
> > operational considerations. There is reference to
> > "implementations" in several
> > places and it is not clear if this is on the router side or the
> > collector/monitoring side - this needs to be clarified so that
> > expectations on
> > either side implementations are clear.
> >
> > As an example: "Implementations MUST track discontinuities and log
> > this
> > information." - which side is this for?
> >
> > Several aspects are not really operational consideration but
> > implementation
> > considerations. Please consider a "Procedures" section for
> > documenting some of
> > those aspects.
> >
> > As an example, how is this text an operational consideration "Some
> > statistics
> > are dependent on feature configurations, such as GR, LLGR, and
> > RPKI, so the
> > corresponding statistics are only sent when these features are
> > enabled. This
> > statistics include Type 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
> > 34, 35, 36, 37,
> > 39, 40, 41, 42, and 43."
> >
> > Another example is "A BMP implementation MUST ignore unrecognized
> > stat types
> > upon receipt and MUST exclude unsupported stat types upon
> > transmission." ...
> > this is a normative protocol behavior that is burried in the
> > Operational
> > Considerations section.
> >
> > "Operators MAY consider rate-limiting statistic updates to
> > minimize performance
> > impact on control-plane processes." - why is this not at least a
> > SHOULD and
> > perhaps even a MUST?
> >
> >
> > ------------------------------------------------------------------
> > ----
> > COMMENT:
> > ------------------------------------------------------------------
> > ----
> >
> > I note that the WGLC for this document was not cross-posted to the
> > IDR WG for
> > soliciting review as required by the GROW WG charter. I hope this
> > can be
> > avoided going forward.
> >
> > I support the DISCUSS positions of both Eric and Gunter. Some of
> > their points
> > are related to the points that I have raised in my ballot as well.
> >
> > I also have some comments/suggestions that I hope will help
> > improve the
> > document.
> >
> > 1) Type = 37: (64-bit Gauge) Current number of routes in per-
> > AFI/SAFI
> > post-policy Adj-RIB-In not found by verifying route origin AS
> > number through
> > the ROA of RPKI [RFC6811]. The value is structured as: 2-byte AFI,
> > 1-byte SAFI,
> > followed by a 64-bit Gauge.
> >
> > The phrase 'not found by verifying ...' is confusing. I assume
> > this refers to
> > routes that didn't find any match in the RPKI cache? If so, please
> > clarify.
> > This also applies to type 43.
> >
> > 2) Type = 39: (64-bit Gauge) Current number of routes refused to
> > be sent by
> > exceeding the maximum AS_PATH length supported by the local
> > configuration.
> >
> > The phrase 'refused to be sent ...' is confusing. Perhaps you mean
> > routes that
> > were not sent because ... This also applies to type 40.
> >
> >
>
>
> ____________________________________________________________________________________________________________
> 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.
>
> ____________________________________________________________________________________________________________
>
> 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.
>
>
> -------------------------------------------------------------------------------------------------------------------------------------
> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> 邮件！
> This e-mail and its attachments contain confidential information from New
> H3C, which is
> intended only for the person or entity whose address is listed above. Any
> use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender
> by phone or email immediately and delete it!
>
>