Luuk,
> On Oct 14, 2025, at 1:50 PM, Luuk Hendriks <[email protected]> wrote: > It would be useful if a router could provide more detailed, structured > info on the filtering. The Table Name TLV can be used to annotate things > on the receiving station, but you can't use it in any logic. > > Can we come up with e.g. a TLV that describes, in some structured way, > what exactly is filtered out (or the other way around, what is included) > in the BMP stream for this particular peer? [and then you illustrate why this is a messy "but..."] Simple filtering on an AFI/SAFI basis could certainly be represented in a simple and standardized basis. However, that's effectively a form of what you'd get in your Peer Up message anyway from the capabilities that are exchanged. For anything more subtle than this, which is generally a filtered view of a given table, it's possibly impractical to signal the policy in question. In some circumstances, it might also be undesirable to make fully visible what is - or is not - being filtered. An example of this might be for security purposes. It's quite likely that filtering is done in a subset of that implementation's route policy filtering language. Such things have been resistant to standardization. For these reasons, it seems likely that what can be reported on a per-BMP session, per-monitored table, from a given monitored entity (what we exchange in Peer Up) is a local string that provides at least a summarization of the filtering. I wouldn't discourage the WG from trying to do something better than this. However, since anything more clever could go into a different TLV, I wouldn't necessarily suggest entwining the progression of something like the original proposal to the more clever filter encoding. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
