I support the adoption of this draft by the WG. It is a useful functionality.
I also think that the additional context would be helpful, so will be good for us to explore what can be conveyed in a simplistic way. Maybe we keep it coarse to strike that balance of this not getting too complex (eg: Reason code with basic optional context like table name, afi-safi etc). One other reason/use-case for filtered view to be sent is the router lacking the support for that RIB-view/AFI-SAFI in BMP though BGP may support it (as reported in their Peer-Up capabilities). Best Regards /snnp (Prasad) -----Original Message----- From: Paolo Lucente <[email protected]> Sent: 17 October 2025 02:18 To: Luuk Hendriks <[email protected]>; Job Snijders <[email protected]> Cc: [email protected] Subject: [GROW] Re: Working Group Call for Adoption for draft-pcmy-grow-bmp-adj-ribs-filtered (start 29/Sep/2025 end 14/Oct/2025) 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-filtere >> d/ >> >> 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] _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
