>> “Also, I had thought the RFC was reasonably clear on this point:“
That’s under route monitoring. Time is part of the common header.
Timestamp: The time when the encapsulated routes were received
(one may also think of this as the time when they were installed
in the Adj-RIB-In), expressed in seconds and microseconds since
midnight (zero hour), January 1, 1970 (UTC). If zero, the time is
unavailable. Precision of the timestamp is implementation-
dependent.
Problem is that the RFC didn’t really clarify the other messages well for time.
If the sender is going to send timestamps based on received updates, then it
MUST honor that for all messages, such as PEER_UP, PEER_DOWN, route mirroning,
etc.
State-compression is effected by BMP header timestamp with packed NRLIs. They
will need to be broken out due to timestamp of when last changed.
Not all BMP senders are not respecting the statement about “received time” and
instead are sending timestamps based on the BMP send time of the message.
The other problem that we are running into is the BMP sender clock is not in
sync with the BMP receivers. Either it’s a different clock source or something
else. Regardless, it causes things to be out of sync, especially when
monitoring BGP churn/excessive updates/bad neighbors/etc. Might be good to
clarify a bit more that the time transmitted in BMP header shouldn’t really be
used for churn/update floods/… Instead, BMP receiver should be expected to add
a timestamp that can be used for that.
--Tim
On 9/22/22, 11:19 AM, "GROW" <[email protected]> wrote:
> On Sep 21, 2022, at 10:29 AM, Maximilian Wilhelm <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
