Robert,
> On Jul 11, 2022, at 12:16 PM, Robert Raszuk <rob...@raszuk.net> wrote: > On Mon, Jul 11, 2022 at 6:09 PM Jeffrey Haas <jh...@pfrc.org > <mailto:jh...@pfrc.org>> wrote: > Tianran, > > Please note that nothing prohibits BGP-LS from being distributed over BMP > today aside from implementation support. It's just another AFI/SAFI. > > -- Jeff > > Do you mean to build a dummy Adj_RIB_IN or OUT just to feed BMP with the > BGP-LS formatted data at the IGP node exporting this data ? Do whatever you'd do in your implementation for BMP for the scenario that makes sense for you. If you want to know what an upstream BGP router sent you, look at your rib-in. If you want to know what local state you've got and are intending to disseminate to your downstreams, look at your loc-rib. If you want to know what state you've sent to your downstream, look at your rib-out. None of this is unusual. rib-in and rib-out are clear from a BGP protocol fundamentals perspective. loc-rib has a touch of ambiguity, along with exactly the same dose of ambiguity about "where does locally originated state manifest in implementations" that made for a lot of discussion in GROW "recently" as the loc-rib and rib-out specs were being finished for RFC purposes. In our implementation, where loc-rib tracks the "lsdist.0" table, I'd probably use that for the majority of use cases that I'd want to get a feed for BGP-LS from BMP. Or, I could just do a BGP-LS peering session and get it that way, but the discussion is that BMP works fine. > > If this would avoid BGP to check the syntax of what is send it would work > fine .. but it would not. And BGP has no business on doing that check and to > understand zoo of foreign extensions completely not related to BGP itself. Feel free to speak for your own implementation, but kindly don't assert that others can't do it when it's being done. -- Jeff
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
