Hi Luuk,
Thanks for the support. I pretty much echo what Jeff already said: previous attempts (pre REL draft) that tried to to somehow formalize things related to policies and filtering resulted in huge structures without guarantee that anybody other than the proponents would be able to harness them.
So, totally, we can recommend in the document to try to give some useful info (free format) as part of the Table Name TLV - as we are doing right now - but i am unsure we can realistically go much beyond that.
Paolo On 14/10/25 19:50, Luuk Hendriks wrote:
Hi all, One of the motivations for this work is to make the use of BMP possible/easier/feasible in situations where it would otherwise not be because of scale. I'm all for that, so in that sense I'm in favour of adoption, but™: 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? For example, a TLV that lists the address families that will be exported in full. Then at least the station can treat those address families as 'unfiltered' even though they are part of a stream where other things are filtered out. Or, a list of 'session types' to signal that the stream only contains edge peering, as per the example in Sec 3. I realise this is a can of worms, and coming up with the right types and names that allow all the combinations people want to express without becoming ambiguous or turning things into a logical nightmare will be quite an exercise. But I hope there is an interest in finding a way to provide additional information to the station so it can draw more conclusions than just 'the data in this stream _somehow_ is a subset of _something_'. If we can't go beyond that, I'm not sure I see enough benefits, but perhaps I'm missing something. Thanks, luuk On Mon 29 Sep 2025, 13:58, Job Snijders wrote:Dear all, The authors of draft-pcmy-grow-bmp-adj-ribs-filtered requested whether the GROW working group could consider adoption of their internet-draft. This message is a request to the group for feedback on whether this internet-draft should be adopted. Title: Filtering Adj-Rib-In and Adj-Rib-Out to BMP receivers Abstract: """ Filtering RIBs in BMP (BGP Monitoring Protocol) can be desirable for several use-cases like, for example, limiting the amount of data a collector station has to process or allow a sender to export only a certain afi/safi of interest. This document defines a light way to inform a collector station that a Adj-Rib-In / Adj-Rib-Out data feed is being filtered. """ The Internet-Draft can be found here: https://datatracker.ietf.org/doc/draft-pcmy-grow-bmp-adj-ribs-filtered/ Please share with the mailing list if you would like this work to be adopted by GROW, are willing to review and/or otherwise contribute to this draft! WG Adoption call ends October 14th, 2025. Kind regards, Job GROW co-chair _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
