Paolo,
> On Apr 11, 2025, at 2:25 PM, Paolo Lucente <[email protected]> wrote: > Thanks for confirming the flexible approach of Juniper on the topic of > multiple sessions and features. > > To your point, my personal use-case, for example, would be to gain visibility > in valid non-primary paths. Primary paths i use to correlate IPFIX against > BMP data; valid non-primary paths for what-if analysis, ie. capacity > planning. Personally, i can stay rather flexible on the topic of state > compression in order to reduce churn as the work will be more historical than > real-time. Thanks for that confirmation. As we've been discussing, the format is "fine", but the implications on a streaming feed of the annotated data is what is problematic. Here's a few bits of general pondering about these sort of features for BMP: Right now, BMP stations have limited insight into what views they're going to get when they subscribe. There's no way for a BMP station to request what feeds it may want to get, including filtered feeds. For applications such as path marking that might be useful for a "what if snapshot", there's not a great methodology to do a "dump once". Comparable to gnmi, "poll" rather than "subscribe". And most importantly, "some metadata can happily be defined in a schema, but may be use case specific". This applies to yang and its access protocols as well. One could easily imagine a BMP port that when you connect gives you the path marked dump *once* and then is done. It's just a form of a filtered feed. However, when you consider the varied use cases, this starts to motivate the conversation about whether there should be a command channel for BMP. Perhaps little surprise, one that's useful for BMP would have other uses for existing streaming telemetry mechanisms. No solutions right now. Just discussion of the problem. :-) -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
