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 <[email protected]> wrote: > Hi Ketan > > Pls see inline with “MS1>” tag. > > Thanks > Mukul > > *From: *Ketan Talaulikar <[email protected]> > *Date: *Thursday, November 20, 2025 at 5:42 AM > *To: *Srivastava, Mukul <[email protected]> > *Cc: *linchangwang (RD) <[email protected]>, The IESG < > [email protected]>, [email protected] < > [email protected]>, > <[email protected]>, [email protected] [email protected] <[email protected]>, > [email protected] <[email protected]> > *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 < > [email protected]> 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) <[email protected]> > *Date: *Wednesday, November 19, 2025 at 7:53 AM > *To: *Ketan Talaulikar <[email protected]> > *Cc: *[email protected] <[email protected]>, > Srivastava, Mukul <[email protected]> > *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 <[email protected]> > *发送时间:* 2025年11月19日 20:22 > *收件人:* linchangwang (RD) <[email protected]> > *抄送:* [email protected]; Srivastava, Mukul < > [email protected]> > *主题:* 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 <*[email protected] > <[email protected]>*> 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 <*[email protected] <[email protected]>*> > *发送时间:* 2025年11月19日 15:48 > *收件人:* *[email protected] <[email protected]>* > *抄送:* The IESG <*[email protected] <[email protected]>*>; > *[email protected] > <[email protected]>*; *[email protected] > <[email protected]>*; *[email protected] <[email protected]>*; *[email protected] > <[email protected]>* > *主题:* 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 <*[email protected] > <[email protected]>*> 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 <*[email protected] <[email protected]>*> > *Envoyé :* mardi 18 novembre 2025 18:16 > *À :* BOUCADAIR Mohamed INNOV/NET <*[email protected] > <[email protected]>*> > *Cc :* The IESG <*[email protected] <[email protected]>*>; > *[email protected] > <[email protected]>*; *[email protected] > <[email protected]>*; *[email protected] <[email protected]>*; *[email protected] > <[email protected]>* > *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 <*[email protected] > <[email protected]>*> 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 <*[email protected] > <[email protected]>*> > > Envoyé : mardi 18 novembre 2025 17:03 > > À : The IESG <*[email protected] <[email protected]>*> > > Cc : *[email protected] > <[email protected]>*; grow- > > *[email protected] <[email protected]>*; *[email protected] <[email protected]>*; > > *[email protected] > <[email protected]>* > > 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! > >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
