Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

[<[e-mail]>]

I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic.

Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone?

Lionel

De : DiME [mailto:[e-mail]] De la part de Steve Donovan
Envoyé : mercredi 5 février 2014 15:34
À : [e-mail]
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.

Steve
On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:

I also agree.



Regards,

Nirav.



-----Original Message-----

From: DiME [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>

Sent: Tuesday, February 04, 2014 11:50 PM

To: [e-mail]<mailto:[e-mail]>

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR



The existing wording seems actually fuzzy.

If it is "like an NTP timestamp", be proud and say it loud!



In summary: ok with the proposal if it clarifies this handling of this sequence-number.



Lionel



-----Message d'origine-----

De : dime issue tracker [mailto:[e-mail]]

Envoyé : mardi 4 février 2014 09:50

À : MORAND Lionel IMT/OLN

Cc : [e-mail]<mailto:[e-mail]>

Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR



#32: Sequence-Number Time-Stamp values within OC-OLR



 The -01 draft says in clause 4.4:

    From the functionality point of view, the OC-Sequence-Number AVP MUST

    be used as a non-volatile increasing counter between two overload

    control endpoints (neglecting the fact that the contents of the AVP

    is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only

    required to be unique between two overload control endpoints.

    Sequence numbers are treated in uni-directional manner, i.e. two

    sequence numbers on each direction between two endpoints are not

    related or correlated.



    When generating sequence numbers, the new sequence number MUST be

    greater than any sequence number previously seen between two

    endpoints within a time window that tolerates the wraparound of the

    NTP timestamp (i.e. approximately 68 years).





 With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).

 It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.




_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.