> On Sep 21, 2022, at 10:29 AM, Maximilian Wilhelm <m...@rfc2324.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.
Also, I had thought the RFC was reasonably clear on this point:
If the implementation is able to provide information about when
routes were received, it MAY provide such information in the BMP
Timestamp field. Otherwise, the BMP Timestamp field MUST be set to
0, indicating that time is not available.
"when routes were received".
But it's also clear about the MAY.
Time highlights below that part of the issue is that with the level of
flexibility the field provides that it can make data from different routers
incomparable.
> 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.
The field in BMP is for the BGP time carried in the BMP protocol. The state
described above is meta-data about a BMP receiver having received a given BGP
route.
>> 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.
For timeseries purposes, it depends on what you're doing timeseries upon.
If you're looking for route stability, the freshness of your BMP message is
less interesting than the sending router's timestamp for when it got the route.
If you're looking for churn at an arbitrary epoch after you've synched your
feeds, then the BMP message receive time may be preferable.
That said, given that the timestamps carried in BMP aren't guaranteed to mean
the same things from implementation to implementation, normalizing the time can
be a challenge.
-- Jeff
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
