Timestamp is another item we need to clarify in 7854bis. Some BMP senders send timestamps based on the actual received BGP update. This may be days, weeks, etc. old from the time that the message is sent to BMP receiver. It has been a bit confusing for people to see timestamps that are old when they just received a RIB dump. OpenBMP/PSQL maintains two timestamps, one is the DB insert time and the other is the BMP received timestamp. For folks that are working with time series DBs to track/insert/maintain records using time, they may drop messages because they believe they are too old when in fact they are new. Basically, for those that are using timeseries DBs, they may have to use a new BMP received timestamp instead of the BMP header timestamp.
Thanks, Tim On 9/21/22, 6:44 AM, "GROW" <grow-boun...@ietf.org> wrote: Hi Robert, Yes, but only for the RIB dump (on initial PEER_UP and for each route-refresh) till EoR. Senders shouldn’t state compress after that, especially for Adj-RIB-In Pre-Policy. State compression should be optional. State compression is not required for the RIB dump or at any time, but it does help deal with churn while the RIB dump is in progress. Thanks, Tim On 9/20/22, 10:52 PM, "Robert Raszuk" <rob...@raszuk.net> wrote: 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
