Hey Henk, The point is that what matters in BGP is reachability and stability // Leave aside all the opaque junk BGP carries today //. Reachability you can pretty much monitor by vanilla IBGP session say with Add-Paths if you want to be fancy. Stability or more importantly filtering the "bad" routes is a bit harder.
So I do not agree that exposing churn is hard. You perhaps think about it in the atomic model where you have to mirror all received messages. Well BMP original idea was about just that. But here we need to decouple discussion about sharing Adj_RIB_In from global bRIB. But here you can just keep local churn counter per NLRI to periodically send it in BMP indicating how many paths for a given b_net was received or withdrawn since your last BMP update. And it does not need to take much space on the sender nor BMP receiver. I would call it smart-compression where you significantly reduce make the bits on the wire or in the ram/ssd yet you do not drop useful information. Many thx, R. On Wed, Sep 21, 2022 at 3:45 PM Henk Smit <[email protected]> wrote: > Hi Robert, > > > But this will hide BGP churn for a given NET to be detectable by BMP > receiver. Is this a good thing ? > > The question is: how expensive is it to report everything bit-for-bit to > the BMP collector? > If you want to report everything, you have to store everything. > Which will require bufferspace. How much? You don't know in advance. Might > be a lot. > > The current way of doing things allows the BMP implementation on a router > to be pretty efficient. > When BGP receives routes, you store them in the BRIB. You don't store > anything special for BMP (expect maybe timestamps, or other meta-data). > When BMP on a router is going to send BMP updates, it just walks the BRIB, > and sees which NLRI/routes have not been sent to the collector yet. > BGP needs only 1 bit of information for that (to be precise: 1 bit per BMP > session per NLRI/route). > > If you want to see all churn, you need loads of buffers. > And BMP stops being an easy and efficient protocol. > So yeah, I am greatly in favor of allowing "compression" (aka skipping > reporting outdated info). > > henk. > > > Op 21-09-2022 07:52 schreef Robert Raszuk <[email protected]>: > > > Hi Paolo, > > A-la: there is multiple updates related to a certain NLRI by when a BMP > message is to be sent out, let's state-compress (ie. not send out) those > that were already obsoleted by a subsequent update. > > > But this will hide BGP churn for a given NET to be detectable by BMP > receiver. Is this a good thing ? I am not sure. It is a loss of information > to me. > > Thx, > R. > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
