Dear Mukul and Jinming,
I have reviewed both documents and have a few comments. Speaking as a network operator, first of all I believe as previous stated it is very much valued that you intend not only to update existing BMP statistics but also much needed new statistics. Thank you very much for this. I agree that it would be helpful if both documents could be merged into 1 before the working group adoption. https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-bgp-rib-stats-01#section-2.1 TBD1, TBD2, TBD3 and TBD4: I appreciate that you are changing from counter to gauge, having statistics for pre and post policy in adj-rib as a summary for all address families and for each address family. I value this granularity. TBD5, TBD6 and TBD11: This gives visibility in how many routes have been accepted or dropped by the route policy. I value that you changed from counter to gauge since an operator is typically not interested in the route event count, they are interested in the amount of routes within the rib. TBD7: The term "active route" is not well defined to my understanding. I suggest to align to https://datatracker.ietf.org/doc/html/draft-cppy-grow-bmp-path-marking-tlv-12#section-2.1 and define a gauge for primary and backup path. TBD8: I suggest to use the term " Suppressed" instead of "Dampened" and make a reference to https://www.rfc-editor.org/rfc/rfc2439#section-2.2 to be aligned with https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01#section-2.1 TBD9. I suggest to be more specific with the reference to https://www.rfc-editor.org/rfc/rfc4724.html#section-4.1 to be aligned with https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-path-marking-tlv-01#section-2.1 TBD10: I suggest to reference https://datatracker.ietf.org/doc/html/rfc9494#section-4.3. https://datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00#section-3 I share the comments from Jeff on TBD5 and TBD6 in https://datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00#section-3.1.2. A reference to the specific section of https://datatracker.ietf.org/doc/html/rfc4271 describing this behavior is needed. I share the comments from Jeff on TBD3 and TBD4 in https://datatracker.ietf.org/doc/html/draft-liu-grow-bmp-stats-reports-00#section-3.1.1 since this is vendor specific. Therefore I object. I suggest to use an enterprise specific TLV instead as described https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-ebit-05#section-3.3 Regarding TBD1 and TBD2. I believe the description is ambiguous. Based on my feedback from https://mailarchive.ietf.org/arch/msg/grow/s55XlMStBXpq0BYTAFubg9aOdL8/ I suggest the following: * Stat Type = TBD1: (64-bit Gauge) How many routes left until configured prefix limit threshold as defined in Section 6.7 of RFC 4271 is reached. This value increases or decreases based when prefix limit threshold is being changed. * Stat Type = TBD2: (64-bit Gauge) How many routes in per-AFI/SAFI left until configured prefix limit threshold as defined in Section 6.7 of RFC 4271 is reached. This value increases or decreases based when prefix limit threshold is being changed. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge. Best wishes Thomas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
