Subject: [Dime] Issue#32 status

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 19 Feb 2014 15:33:58 +0000

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

I understand that we agreed the following principles:

Sequence-Number is of type Time, however the value need not correspond to the point in time of generation.

When generated, a new sequence number must be  greater than any sequence number previously generated by the same node (including over a reboot of that node)

When received, a sequence number is used to detect outdates/replays/freshness.

Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.

I did not understand the requirement for globally uniqueness as introduced by Jouni.
Can Jouni please explain.

Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Wed, 19 Feb 2014 14:11:18 -0600

Ulrich,

See comments inline.

Steve

> to the point in time of generation.
SRD> I don't agree that the type should be time.  It should be of type
Unsigned64.  A time stamp can be inserted into it but we should not
prevent simple sequence numbers.  I agree with the remainder of the
statement.
>  
> When generated, a new sequence number must be  greater than any
> sequence number previously generated by the same node (including over
> a reboot of that node)
SRD> Agreed
> outdates/replays/freshness.
SRD> Agreed
> Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.
SRD> Agreed
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 20 Feb 2014 09:00:03 +0000

Steve,

I'm ok with Unsinged64 but then the second principle that says "...must be  greater ..." needs some enhancements to cover the overflow.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Wednesday, February 19, 2014 9:11 PM
To: [email-masked]
Subject: Re: [Dime] Issue#32 status

Ulrich,

See comments inline.

Steve

Sequence-Number is of type Time, however the value need not correspond to the point in time of generation.
SRD> I don't agree that the type should be time.  It should be of type Unsigned64.  A time stamp can be inserted into it but we should not prevent simple sequence numbers.  I agree with the remainder of the statement.

Ulrich

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Feb 2014 16:43:16 -0600

>> SRD> I don't agree that the type should be time.  It should be of type Unsigned64.  A time stamp can be inserted into it but we should not prevent simple sequence numbers.  I agree with the remain…

+1. Making it type Time implies that the recipient can do something time related with the value. That is not the case here.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Feb 2014 09:06:43 +0000

Ben,

my preference for Time was based on the assumtion that it implicitly covers the overflow   (see RFC 6733 clause 4.3.1).

I'm ok with Unsigned64, but then we need to address overflow more precisely, e.g.:

For the reacting node: a newly received sequence number Sn must be considered fresher than a stored sequence number Ss if and only if Ss < Sn < Ss+2^63 or Sn < Ss-2^63.
For the reporting node: when Sl is the last generated sequence number and So is the oldest potentially not yet expired sequence number, a newly generated sequence number Sn must comply with ( Sl < Sn < Sl+2^63 or Sn < sl-2^63 )and( So < Sn < So+2^63 or Sn < So-2^63 ).

Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Feb 2014 14:33:00 -0600

Ulrich,

Would you agree to the following to replace the first two statements:

Sequence number is of type Unsigned64.

When generated, a new sequence number must be greater than the sequence
number contained in the active overload report to which it applies
(including over reboot of that node).  Note: this allows sequence
numbers to start at 1 for any occurrence of overload at a reporting
node.  This, I think, allows us to ignore wraparound issues as
wraparound will never happen.  Unless we are worried about a server
staying in overload for billions of years (assuming reports with a ten
minute validity period refreshed every five minutes).

The other two statements are good.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Mon, 24 Feb 2014 17:00:17 -0600

+ 1, except as noted:

On Feb 24, 2014, at 2:33 PM, Steve Donovan <[email-masked]> wrote:

> When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).  Note: this allows sequence numbers to start at 1 for any occurrence of overload at a reporting node.  This, I think, allows us to ignore wraparound issues as wraparound will never happen.  Unless we are worried about a server staying in overload for billions of years (assuming reports with a ten minute validity period refreshed every five minutes).

s/ any occurrence of overload / the initial occurrence of an overload condition

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Feb 2014 09:02:11 -0600

I agree with the suggested change.

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Feb 2014 16:21:05 +0000

Steve, Ben,

for my clarification, your proposal is to say

***

When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).  Note: this allows sequence numbers to start at 1 for the initial occurrence of an overload condition at a reporting node.
***

If so, what is meant by "initial occurrence of an overload condition"?

I guess it means something like moving from no overload to overload after a sufficiently long periode of no overload

Please clarify

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, February 25, 2014 4:02 PM
To: Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] Issue#32 status

Steve

Ulrich,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Feb 2014 12:42:31 -0600

> I guess it means something like moving from no overload to overload after a sufficiently long periode of no overload

For the purpose of this discussion, yes.

Thanks!

Ben.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Feb 2014 10:36:50 -0600

Ulrich,

Yes, with that period being long enough for the reporting node to be
confident that all previously sent overload reports have expired.

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 Feb 2014 08:24:33 +0000

I agree. It seems we can close issue#32.

I assume editors will convert the agreed principles to propper specification text.

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Tuesday, February 25, 2014 5:37 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: [email-masked] list
Subject: Re: [Dime] Issue#32 status

Ulrich,

Yes, with that period being long enough for the reporting node to be confident that all previously sent overload reports have expired.

Steve

Steve, Ben,

***

***

Please clarify

Ulrich

To: Ben Campbell

Cc: [email-masked]<mailto:[email-masked]> list

Steve

+ 1, except as noted:

On Feb 24, 2014, at 2:33 PM, Steve Donovan <[email-masked]><mailto:[email-masked]> wrote:

Ulrich,

Steve

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 28 Feb 2014 17:30:23 +0200

Going back in history..

> Can Jouni please explain.

Originated from here:
http://www.ietf.org/mail-archive/web/dime/current/msg06600.html

So requiring global uniqueness is not desired anymore? 

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 28 Feb 2014 15:37:12 +0000

I think so; not required, not desired.

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, February 28, 2014 4:30 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] Issue#32 status

Going back in history..

Originated from here:

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 28 Feb 2014 17:44:35 +0200

Ok.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 28 Feb 2014 20:21:41 +0200

A question.. how much is "a sufficiently long period of no overload"?
I'd like to see some guidance or minimum values documented.

- Jouni

On Feb 25, 2014, at 6:36 PM, Steve Donovan <[email-masked]> wrote:

>> From: DiME [
>> mailto:[email-masked]
>> ] On Behalf Of ext Steve Donovan
>> Cc: 
>> [email-masked]
>>  list
>> On Feb 24, 2014, at 2:33 PM, Steve Donovan 
>> <[email-masked]>
>>  wrote:
>> 
>> Ulrich,
>>