hi jeff,
Thank you for the comments on the draft.
For
the first comment, our reference to "route threshold" in the draft only
includes routes in RIB-IN that are rejected due to configuration
limitations. Which is the same as the latter you mentioned in your
email.
The "license-customized route threshold" count is
consistent with the above considerations, and vendor licenses are
sometimes updated at the request of network operators, we wanted to
define a counter to monitor such changes.
Therefore, it is reasonable to define a 64-bit counter "gauge" to measure
the above changes.
For
the as-path length threshold, The reference here is intended to clarify
the definition of AS-Path from RFC4271,not threshold lengths. Obviously
there is some ambiguity in the current formulation, and I will update
the description in a later version.
The RPKI counter mentioned in the draft only focuses on ROA query results.
Since the RPKI action changes caused by RFC8893 do not involve query results,
there is no immediate impact on the counter. In any case, we will keep an eye
on it.
Best regards,
Jinming Li
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
----邮件原文----发件人：Jeffrey Haas <[email protected]>收件人："李金铭"
<[email protected]>抄 送: grow <[email protected]>发送时间：2024-02-28
03:30:59主题：Re: [GROW] Internet-Draft draft-liu-grow-bmp-stats-reports-00Jinming
Li,
A few comments on your proposed counters:
Are your "route threshold" counters intended to cover route discards or only
routes that are retained in the adj-ribs-in and automatically rejected because
they exceed a configured limit?
If the case is intended to cover discards as well, a gauge is probably not the
correct type for this. You can only keep a gauge for state that you know comes
and goes. Discards can be counted (counter type), but not tracked on a
per-prefix basis without keeping the prefix.
For your license restriction count, I understand the use case. However, I have
some concerns that the counter is clear in a vendor neutral fashion. And,
similar to the comments above, if this is intended to cover cases where routes
are discarded along with the case for keeping the routes a counter may be a
more appropriate type.
For the as-path length threshold, please restructure the reference to RFC 4271.
As written, it looks like the citation is intending to say such threshold
lengths are a feature of that RFC. They are not.
The RPKI counters will be popular! Please consider socializing these counters
with the sidrops group.
Please also be aware that for adj-ribs-out for rpki that RFC 8893 might change
the behavior somewhat.
-- Jeff
On Feb 26, 2024, at 8:24 PM, 李金铭 <[email protected]> wrote:
Hi all,
We have submitted a new Internet-Draft draft-liu-grow-bmp-stats-reports-00
which is about BMP Statistics Types.
As the BGP protocol continues to expand, more and more functional features are
implemented through the BGP protocol, which adds more event information to
monitor these functional features.This document lists some new statistics types
to update RFC 7854 for growing BGP features.
The New BMP statistics types are used by the monitoring station to observe more
interesting events that occur on the router.
New types Include RIB-IN Statistics Types for Route Threshold, RIB-IN/RIB-OUT
Statistics Types for AS-Path Length Threshold, and RIB-IN/RIB-OUT Statistics
Types for Route Origin Validation.
If you have some comments and suggestions, please provide feedback.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-liu-grow-bmp-stats-reports/
Best regards,
Jinming Li
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________GROW mailing
[email protected]https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
