Hey folks, I think having the original timestamp of when a route was learned is valueable, even if theP BM session is set up later, or has flapped and is reestablished etc. This was it's always possible to determine when a given prefix/path was learned. If you want to have the time the informatione was learned via BMP it's also possible to use the current time then to store it into a TSDB. So following the principle of always keeping the most options I think we should make sure the timestamp always represents the one where the BGP UPDATE happened. As most (if not all?) routers already store that time / a route age, that information should already be available.
Cheers, Max Anno domini 2022 Tim Evens (tievens) scripsit: > 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" <[email protected]> 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" <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
