[Speaking as a non-author here...]
Yang,
On 8/4/25 21:15, Yang Yu wrote:
Hi all,
Apologies for the late feedback.
1)
It would be good to clarify a requirement that a TLV can only be sent
if the value is known to be valid. Do not include TLVs with value 0
when the feature is unsupported / disabled (e.g. no TLV 41 / 42 / 43
if RPKI validation state not available in outbound). Do not include a
gauge TLV if it only has partial data.
While that's largely current practice, that's a clarification that
probably belongs more in an update on the core BMP RFC itself.
Although, since this draft is about NOTHING other than statistics, the
chairs might consider that to be in-scope. It's a bit late in the
current process to try to change this to be an "updates RFC 7854" though.
However, as you see in list traffic, there seems to be interest in more
stats, so perhaps next draft? ;-)
2)
On relationship between defined TLVs, particularly being explicit on
whether routes reported by one TLV should be included in other TLVs
Type = 21: (64-bit Gauge) Current number of routes in per-AFI/SAFI
Adj-RIBs-In Post-Policy. The value is structured as: 2-byte AFI,
1-byte SAFI, followed by a 64-bit Gauge.
Type = 23: (64-bit Gauge) Number of routes in per-AFI/SAFI accepted by
inbound policy. The value is structured as: 2-byte AFI, 1-byte SAFI,
followed by a 64-bit Gauge. Some implementations, or configurations in
implementations, MAY discard routes that do not match policy and thus
the accepted count and the Adj-RIB-In counts will be identical in such
cases.
Is this about accounting for default accept / deny at the end of
policy, or routes accepted by policy but still not "valid" (nexthop
resolution failure, or mechanisms not strictly part of import policy
like aspath loop prevention, left most AS not matching peer AS). It is
not clear to me if TLV 23 should always be greater than TLV 21
Providing at least one concrete example of this, in Juniper's
implementation, "keep all" vs. "keep none" can impact whether routes
that are rejected by policy are retained in the rib-in or not.
Similarly, on a PE, VPN routes that don't match a local route target may
be discarded if the device is not a route-reflector or ASBR.
Other implementations may do other things that make sense in their own
context.
I would expect that type 23's value should be >= type 21's value.
Type = 22: (64-bit Gauge) Current number of routes in per-AFI/SAFI rejected by
inbound policy
Should TLV 22 include routes reported by TLV 26/27/28/34/40?
Ideally, type 22 should only include things due to actions by
user-configured policy.
That said, it wouldn't shock me if some implementations may be unable to
distinguish all of the sub-cases distinctly. One thing this draft is
helpful for is defining trackable statistics that might motivate
implementations that lack that clarity to add such tracking. Such
counters and state in the routes to distinguish their behavior has a
cost and thus implementations may make tradeoffs. About the best one
can ask for as an operator under such circumstances is clarity within a
given implementation.
-- Jeff
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
