Totally agree that the original is important, but there are several BGP senders that do not send the original timestamp. How do we know if it’s original or the time when the router/sender sent the BMP message? Right now, we know only based on known implementations that honor the original vs others that do not. RFC7854 defines both sender and receiver. The timestamp issue with TSDB is more on the receiver side. The receiver should likely add a timestamp if using TSDB. This would allow the original to still be recorded but have a current timestamp as well. This is exactly what OpenBMP does and I’m sure other receivers are doing the same by now.
BTW, there is at least one software based BGP stack that sends BMP messages with ZERO value for time. I’ve had to update OpenBMP collector to specifically add a timestamp when this happens. Thanks, Tim On 9/21/22, 7:29 AM, "GROW" <grow-boun...@ietf.org> wrote: 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" <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
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
