> but kindly don't assert that others can't do it when it's being done.

I did not assert that it can not be done as it is done today.

But not everything which is done today should be kept that way for an
endless future.

Many thx,
R.


On Mon, Jul 11, 2022 at 8:18 PM Jeffrey Haas <jh...@pfrc.org> wrote:

> 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> 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

Reply via email to