Subject: [manet] New Version Notification for draft-ietf-manet-timetlv-03

From: IETF I-D Submission Tool <[email-masked]>
Date: Thu, 15 Nov 2007 11:18:37 -0500

A new version of I-D, draft-ietf-manet-timetlv-03.txt has been successfuly submitted by Thomas Clausen and posted to the IETF repository.

Filename:	 draft-ietf-manet-timetlv
Revision:	 03
Title:		 Representing multi-value time in MANETs
Creation_date:	 2007-11-15
WG ID:		 manet
Number_of_pages: 18

Abstract:
This document describes a general and flexible TLV (type-length-value
structure) for representing time using the generalized MANET packet/
message format.  It defines two message and two address block TLVs
for representing validity and interval times for MANET routing
protocols.

The IETF Secretariat.

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Ian Chakeres" <[email-masked]>
Date: Sun, 18 Nov 2007 15:25:37 +0530

I think it would be useful for TimeTLV to specify a method for
carrying 'C'. I understand that normally nodes (or implementations)
might be configured with 'C' for each TimeTLV type. For cases where C
is either unknown or required, I think we should specify a format for
carrying it. I see carrying C as most important when C
misunderstandings could cause routing to fail.

I believe there are several different options for encoding this
information. What do you think would be the best way?

Ian

---

From: "Teco Boot" <[email-masked]>
Date: Sun, 18 Nov 2007 11:28:33 +0100

I read the NHDP and OLSv2 documents and found out the intention of not
specifying C in timetlv.
C is really a constant and a protocol defines it for a particular usage.
Multiple protocols or different timetlv usages are free to define their own
constant.
But this constant shall be fixed and there is no need for signaling. Nor
configuration. It shall be hard coded.
Maybe adding some text to circumvent any misunderstanding, explaining there
is no need for signaling?

Maybe a protocol has a need for a variable V, replacing the constant C.
Then, that protocol shall implement signaling for V.

Teco.

> -----Oorspronkelijk bericht-----
> Van: Ian Chakeres [mailto:[email-masked]]
> Verzonden: zondag 18 november 2007 10:56
> Aan: [email-masked]
> CC: [email-masked]; [email-masked]
> Onderwerp: Re: [manet] New Version Notification for draft-ietf-manet-
> timetlv-03
> 
> > A new version of I-D, draft-ietf-manet-timetlv-03.txt has been
> successfuly submitted by Thomas Clausen and posted to the IETF
> repository.
> >

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 20 Nov 2007 09:53:14 -0000

I'm in agreement that this is neither intended nor
desirable. Actually I don't think it's ever desirable,
but especially not in timetlv.

Why never desirable? First it isn't usually necessary.
If C = 1 ms you can have times up to 1.5 months at
millisecond resolution. If C = 1 second you can have
times up to over a century, at second resolution.
(Other figures are of course possible.)

Second the point of timetlv is passing an unambiguous
time, often in circumstances where communications has
not yet been established. If you had to negotiate C for
routing (which is after all why we are here) you'd have
to do that before any other form of topology formation
etc. that used C. This would be really bad. So for our
main use cases, negotiating C really doesn't work.

Yes, I can conceive of a protocol that want to negotiate
C (that doesn't however mean I think it's likely - I
think it's very unlikely given my first point). If so
that protocol can define such a process. It's way outside
what timetlv should include, especially given that it's
an obscure case. (And as we have no prior art, defining a
good mechanism would be tricky.)

Realised there's one more point. If you want to define C
in the same message as one of the timetlv TLVs, that
suggests you may not be using the right format in the
first place.

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 18 November 2007 09:56
To: [email-masked]
Cc: [email-masked]; Dearlove, Christopher (UK)
Subject: Re: [manet] New Version Notification for
draft-ietf-manet-timetlv-03

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Ian

> for representing validity and interval times for MANET routing

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 20 Nov 2007 16:28:05 +0530

Comments inline.

> but especially not in timetlv.

I am not concerned about the timetlv format. I am concerned about the
two TLVs specified/allocated in the TimeTLV document. That is VALIDITY
and INTERVAL.

> main use cases, negotiating C really doesn't work.

This fact seems to motivate that C been defined/specified somewhere
for any timetlv instance. Otherwise, misunderstandings could cause
major problems.

I believe this may be one of the reasons that OSPF carries timing
information in its messages.

Ian

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 20 Nov 2007 11:05:17 -0000

> for any timetlv instance. Otherwise, misunderstandings could cause

Quoting timtlv:

"All nodes in the network MUST use the same value of the constant C".

"A protocol using this time representation MUST define the value of C."

That's pretty clear.

The whole purpose of timetlv is to allow sending accurate
enough times in one octet. To do this nodes need to agree
on something, and what they agree on is C. Agreeing on C
is easy with the massive range we now have. Then making
you have to transfer C defeats the whole efficiency point,
and making C variable defeats the whole point entirely.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 12:50:01 +0100

> > (Other figures are of course possible.)

The claim on precision is marketing stuf. On the low end it is correct, on
the high end the resolution is far from seconds or milliseconds.
Seconds: last increment is more than 8,5 years
Milliseconds: last increment is more than 3,5 days

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 13:03:58 +0100

> "All nodes in the network MUST use the same value of the constant C".

This is not exactly true.
The TimeTLV can be used for multiple purposes, and by multiple protocols. In
that case, there are multiple constants C and they may be different. But for
a particular usage, the constant is really constant.

> "A protocol using this time representation MUST define the value of C."
Yes;-)

> and making C variable defeats the whole point entirely.

I agree with Ian that it is not clearly defined what the constant C is, when
using VALIDITY_TIME TLV or INTERVAL_TIME TLV.
Text in sections 7 and 8 could repeat the requirement that the protocol
using this MUST specify the constant C for it.

Thought on defining a default?
We could add the text: 
    
      Unless otherwise specified, the constant C defaults to 0.0625 second
(1/16 second).

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 20 Nov 2007 12:26:52 -0000

You are correct, I should have made a more precise
statement. But it's not marketing.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 20 November 2007 11:50
To: 'Ian Chakeres'; Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]
Subject: RE: [manet] New Version Notification for

               *** WARNING ***

> > (Other figures are of course possible.)

The claim on precision is marketing stuf. On the low end it is correct,
on
the high end the resolution is far from seconds or milliseconds.
Seconds: last increment is more than 8,5 years
Milliseconds: last increment is more than 3,5 days

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 20 Nov 2007 12:32:35 -0000

We did think about a default. However I can see at least
three sensible values for a default (1 ms, 1/16 s, 1 s)
and I'm not sure mandating one would be productive.

I fail to understand in the least how it's not clear when
using those TLVs. They are defined as being time TLVs, using
the specified representation of tiem, in which C is mandated
as being defined as a constant.

I see absolutely no value in using different values of C for
the two TLVs. They clearly must be of the same order of
magnitude or thereabouts, and a factor of 10 is small in the
about 4 million factor range offered.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 20 November 2007 12:04
To: Dearlove, Christopher (UK); 'Ian Chakeres'
Cc: [email-masked]; [email-masked]
Subject: RE: [manet] New Version Notification for

               *** WARNING ***

This is not exactly true.
The TimeTLV can be used for multiple purposes, and by multiple
protocols. In
that case, there are multiple constants C and they may be different. But
for
a particular usage, the constant is really constant.

Yes;-)

> and making C variable defeats the whole point entirely.

I agree with Ian that it is not clearly defined what the constant C is,
when
using VALIDITY_TIME TLV or INTERVAL_TIME TLV.
Text in sections 7 and 8 could repeat the requirement that the protocol
using this MUST specify the constant C for it.

      Unless otherwise specified, the constant C defaults to 0.0625
second
(1/16 second).

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 20 Nov 2007 14:40:56 +0100

On using different C values in the same MANET:
This is for different purposes, e.g. ISO 3166 country names and country IDs
have long expiration dates (5 years). My personal mobile phone number could
change, expiration time would be weeks. A fixed line number expires in
minutes, as I could move from here to there. 
So there are different values for C (I agree on this concept) but for
different purposes there may be different constants, even in the same MANET.

Teco.

> Van: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Verzonden: dinsdag 20 november 2007 13:33
> Aan: Teco Boot; Ian Chakeres
> CC: [email-masked]; [email-masked]
> Onderwerp: RE: [manet] New Version Notification for draft-ietf-manet-
> timetlv-03
> 
>