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
