dear jeff,
Thank you for your comments on the draft, we will update them in the new draft.
Includes a more explicit description of the "route threshold", references to
RFC4172, and recommendations on the possible impact of RIB-OUT statistics and
implementation of RFC8893.
Jinming Li,
On Feb 28, 2024, at 2:37 AM, 李金铭 <[email protected]> wrote:
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.
You
will want to clarify the text to say "routes that are accepted into the
rib-in, but not eligible for installation in the loc-rib".
Indeed, the "route threshold" needs further clarification in the draft.
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.
The place this can impact is whether rpki reject procedures are applied on
egress or not.
If
RFC 8893 is not implemented by the router, the counters will typically
reflect rpki validation applied only at the rib-in level.
If
RFC 8893 is implemented, the statistics will differ for routes that
undergo as-path transformations that render them rpki-invalid, or
potentially change them to valid from invalid.
My recommendation is to omit the rib-out counters unless RFC 8893 is
implemented.
-- Jeff
The implementation of RFC8893 does have an impact on the statistics in this
case.We should add such a statement in future drafts. like, "This type of
statistics is recommended only if the router implement RFC8893."
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Jinming Li,On Feb 28, 2024, at 2:37 AM, 李金铭 <[email protected]> wrote:
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.
You will want to clarify the text to say "routes that are accepted into the
rib-in, but not eligible for installation in the loc-rib".
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.
Thanks.
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.
The place this can impact is whether rpki reject procedures are applied on
egress or not.
If RFC 8893 is not implemented by the router, the counters will typically
reflect rpki validation applied only at the rib-in level.
If RFC 8893 is implemented, the statistics will differ for routes that undergo
as-path transformations that render them rpki-invalid, or potentially change
them to valid from invalid.
My recommendation is to omit the rib-out counters unless RFC 8893 is
implemented.
-- Jeff
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
