Re: [Dime] OVLI: comments to 4.3

Ulrich,

> it is also an important part that the reacting node calculates the expiry time of an OLR based on the included timestamp and duration and not based on the reception time and the included duration.
I do not agree that this is important.
I do not see any issue if the reacting node starts the timer equal to Validity-Period on reception of the message containing a fresh OC-OLR.
I agree that this means each reacting node will run this timer for different duration since each of them will start the timer of the same value but starting from the time when they received OC-OLR. But this is not an issue since Validity-Period is anyway a guestimate and it would provide a natural ramp up effect (to avoid message storm at the reporting node) if each of the reacting node stops the throttling at different time.

> It is much simpler for reporting nodes to include a pre-calculated OLR into the answer rather than  to adjust the validity-duration in the OLR in dependency of the time when the OLR is included into the answer.
I agree. The reporting node should not be required to adjust Validity-Period while sending OC-OLR to different reacting nodes. I do not see any need to do so based on my explanation above.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Sent: Monday, December 09, 2013 4:25 PM
To: Nirav Salot (nsalot); Ben Campbell
Cc: dime@ietf.org
Subject: RE: [Dime] OVLI: comments to 4.3

Nirav,

it is also an important part that the reacting node calculates the expiry time of an OLR based on the included timestamp and duration and not based on the reception time and the included duration. It is much simpler for reporting nodes to include a pre-calculated OLR into the answer rather than  to adjust the validity-duration in the OLR in dependency of the time when the OLR is included into the answer. The reporting node may want the OLR to be valid starting from creation time (t0) for the validity-duration (d), i.e. until t0+d independent from the point in time (t0, t0+1,...,t0+d-1) when the OLR is sent.

Ulrich  

-----Original Message-----
From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] 
Sent: Saturday, December 07, 2013 9:27 AM
To: Ben Campbell; Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: RE: [Dime] OVLI: comments to 4.3

In my view, from the reacting point of view, Timestamp and Sequence-Number are both the same since it is just a number defining the uniqueness/version-Id of the OC-OLR.
e.g. we can define Sequence-Number and the reporting node can use Timestamp to populate the same. 

The most important part is that the reacting node is not supposed to use this parameter for anything but finding out the newness/version-ID of the report.
Beyond that, from the reporting node's point of view, I am fine to use Sequence-Number or Timestamp.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Saturday, December 07, 2013 3:20 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.3

On Dec 6, 2013, at 7:39 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

>> 
>> 2. TimeStamp has been replaced with Sequence-Number. This has the negative impact that reacting nodes must calculate the expiration time base on OLR-reception time. OLR reception time and OLR creation time  may be significantly different.
>> I don't see any reason in favour of Sequence-Number. Proposal is to replace Sequence-Number with TimeStamp.
> 
> I agree but you need to convince the others as well who favoured sequence number.

I don't think it was so much that we didn't want it to be a timestamp as we didn't want to mandate the implementation. We need to make sure the number changes between different versions. A time stamp is one way to do that. A sequence number (or version number) is another.

As I mentioned in a separate thread, we at list need to describe the expected properties. For example, the scope-of-uniqueness, whether we expect the number to always increase or just be different, etc. It's not clear to me that any association with wall clock time is one of those needed properties, even though a time stamp might be a perfectly reasonable way to achieve the other needed properties.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime