Subject: [Idr] Mail regarding draft-liang-idr-flowspec-v1-time

From: Stewart Bryant <[email-masked]>
Date: Fri, 15 Jul 2016 17:49:05 +0100

Hi

You seem to have specified this using 32bit Unix time.

To quote that well known reference Wikipedia:

  * At 03:14:08 UTC on Tuesday, 19 January 2038,32-bit versions of the
    Unix time stamp will cease to work
    <https://en.wikipedia.org/wiki/Year_2038_problem>, as it will
    overflow the largest value that can be held in a signed 32-bit
    number (7FFFFFFF_16 or2,147,483,647
    <https://en.wikipedia.org/wiki/2147483647>). Before this moment,
    software using 32-bit time stamps will need to adopt a new
    convention for time stamps,^[20]
    <https://en.wikipedia.org/wiki/Unix_time#cite_note-28> and file
    formats using 32-bit time stamps will need to be changed to support
    larger time stamps or a different epoch. If unchanged, the next
    second will be incorrectly interpreted as 20:45:52 Friday
    13 December 1901 UTC.

2038 is not actually that far away, and looks like it will need a 
protocol re-spin to fix.  It would seem to be a good idea to avoid this 
at design time by using a larger field for seconds, or an epoch that is 
less than  46 years old, or include an epoch for the BGP session (which 
allows compact representation and no practical end date)?

Regards

Stewart