Dear GROW,
At the previous IETF in Montreal, we got some feedback about the TLVs defined
in the SNTS draft. Mostly, the feedback was to survey the vendors about the
granularity needed for timestamps in the new Timestamp TLV. Initially, we went
with the same format that has been used since the beginning of BMP: u32 for
seconds + u32 for microseconds. We then asked which format was easier for
vendors to implement.
We learned that "Juniper's implementation only really keeps track of seconds,
everything else is fake(d)". This means they don't really have a use for the
microseconds field.
I checked the FRRouting code and it seems like they keep track of the uptime of
the peers and paths as seconds with a monotonic clock. They then convert that
monotonic time to "real clock time" and get some microseconds value that way.
If I'm correct, I guess this is really only seconds granularity. This looks
similar to what Juniper does.
We would also be interested in knowing whether vendors store different
timestamps before and after inbound/outbound policy application. If they do,
and if operators are interested in that, we can actually make Adj-RIB-In/Out
Pre-policy and Adj-RIB-In/Out Post-policy timestamps, instead of the non
specific Adj-RIB-In/Out timestamps we currently have. This would allow
measuring the duration of policy computation.
tl;dr:
We kindly ask for feedback from vendors on their timestamp granularity. We
would like to know:
- What is the highest granularity of timestamp you can get?
(seconds/ms/ns?)
- What is the highest granularity of timestamp you actually store?
(seconds/ms/ns?)
- Do you store different timestamps for Adj-RIB-In Pre-policy and
post-policy? Same question for Adj-RIB-Out.
Optional questions:
To define precisely what the timestamp types we would also like to know:
- Do timestamps stored in the RIB correspond to the last update on the
route attributes?
- Do they correspond to the time of allocation of the route in the RIB?
- Something else?
Thank you for your help.
Best,
draft-younsi-grow-bmp-snts authors
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
