> On Jun 13, 2019, at 12:02 PM, Tim Evens (tievens) <[email protected]> wrote: > > Thanks Mukul. I'll also update this one as noted.
Tim, Sorry, are you saying you’re updating it to proposal #1 or #2 ? (I would want #2) - Jared > > On 6/13/19, 8:16 AM, "GROW on behalf of Mukul Srivastava" > <[email protected] on behalf of [email protected]> wrote: > > Hi All > > The current BMP Local-RIb draft doesn’t define what timestamp should be used > in Per-Peer header for BMP local RIB 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 local RIB monitoring > case. > > Proposal: > 1. Since local RIB is not specific to a peer, the time stamp could be > the time when BMP RM message was created or sent to BMP collector. > 2. Another option would be that the timestamp value be the time when > this prefix was installed in local RIB. > > Otherwise the definition of “timestamp” would be the same as in RFC 7854. So, > something like this: > > o Timestamp: The time when the encapsulated routes were installed in > The Loc-RIB, 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
