This is non-trivial since it needs to be understood from the peer's capabilities message, and thus needs to be set per-<peer, AFI, SAFI>.
I don't know of any MRT data that uses https://tools.ietf.org/html/draft-ietf-grow-mrt-add-paths-03 to include ADD-PATH data, but this would be simple to support since each MRT record effectively indicates whether or not ADD-PATH is in use.
BMP is trickier however. We need to watch for the OPEN message and then build a map where the key is <peer, AFI, SAFI> (this is what openbmp currently does i think). Since our parser is stateless this is (currently) impossible. We could make use of the options structure (as we currently do to indicate AS4 support), but we'd need to somehow allow the user to pass in the lookup table.
As far as I can tell, the best option would be to make the parser stateful (maybe by allowing the parser to populate the opts structure), and then the BMP parser could populate a capabilities lookup table.
This is non-trivial since it needs to be understood from the peer's capabilities message, and thus needs to be set per-<peer, AFI, SAFI>.
I don't know of any MRT data that uses https://tools.ietf.org/html/draft-ietf-grow-mrt-add-paths-03 to include ADD-PATH data, but this would be simple to support since each MRT record effectively indicates whether or not ADD-PATH is in use.
BMP is trickier however. We need to watch for the OPEN message and then build a map where the key is <peer, AFI, SAFI> (this is what openbmp currently does i think). Since our parser is stateless this is (currently) impossible. We could make use of the options structure (as we currently do to indicate AS4 support), but we'd need to somehow allow the user to pass in the lookup table.
As far as I can tell, the best option would be to make the parser stateful (maybe by allowing the parser to populate the opts structure), and then the BMP parser could populate a capabilities lookup table.