Thanks Tim. Thanks Mukul
From: "Tim Evens (tievens)" <[email protected]> Date: Thursday, June 13, 2019 at 12:01 PM To: Mukul Srivastava <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>, Jeff Haas <[email protected]>, John Scudder <[email protected]> Subject: Re: Value of timestamps in BMP header for rib-out monitoring Thanks Mukul, I'll update that as noted. On 6/13/19, 6:17 AM, "Mukul Srivastava" <[email protected]<mailto:[email protected]>> wrote: Hi All The current BMP Adj-RIB-Out draft doesn’t define what timestamp should be used in Per-Peer header for BMP ADJ-RIB-OUT monitoring. BMP RFC 7854 defines “Timestamp” in Per-Peer header as below: 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. The above timestamp use doesn’t make much sense for Adj-RIB-Out case. A better value for timestamp, would be the time when a prefix was advertised to a peer. Collector can use this time stamp to get some sense of “when a given prefix was advertised to a peer”. Otherwise the definition of “timestamp” would be the same as in RFC 7854. So, something like this should be added in the for BMP ADJ-RIB-OUT draft: o Timestamp: The time when the encapsulated routes were advertised (one may also think of this as the time when they were installed in the Adj-RIB-Out), 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. Thanks Mukul
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
