Tim, Excellent points, especially with regard to non-RM messages. Clarifying the intended behaviors would be good... and will certainly make a number of implementations non-conformant when the -bis is done. The joys of IETF. :-)
> On Sep 22, 2022, at 8:02 PM, Tim Evens (tievens) <[email protected]> wrote: > 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. And for some cases, it's unclear semantically what to do beyond "received". I seem to recall some internal discussion at work about "what do we put here for loc-rib". I can dig out the answers for the Working Group when we get to that part of the process. > 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. We had conversations with a Certain Large Customer not only on not being able to use this for correlation due to state compression and internal timing artifacts as the routes moved through the pipeline. We also had to have the conversation that our implementation only kept second-level granularity for this stuff. Those conversations did eventually cause us to alter our implementation to include effectively an epoch for events occuring in the same second so that timestamps increased. However, that "sub-second" data is a lie. Clock synchronization for this sort of stuff is always a mess, even when NTP is involved. The IEEE high precision time stuff can help in some circumstances, but that plumbing often is one step disconnected from the routing implementations. (Why not just use a more precise timer in our code? The short historical answer is the cost for an additional uint32 vs. memory scale wasn't a win for many customers. The secondary answer is that we already didn't have strong faith in received route timestamps based on TCP artifacts anyway. Who knows how long a given PDU was sitting between the sender and receiver queues before your recv() succeeded and you were able to start parsing the update.) -- Jeff
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
