Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt

From: [email-masked]
Date: Tue, 11 Sep 2007 02:40:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF.

	Title           : Proxy Mobile IPv6
	Author(s)       : S. Gundavelli, et al.
	Filename        : draft-ietf-netlmm-proxymip6-04.txt
	Pages           : 57
	Date            : 2007-09-11

This specification describes a network-based mobility management
protocol.  It is called Proxy Mobile IPv6 and is based on Mobile IPv6
[RFC-3775].  This protocol enables mobility support to a host without
requiring its participation in any mobility related signaling.  The
design principle in the case of network-based mobility management
protocol relies on the network being in control of the mobility
management.  The mobility entities in the network are responsible for
tracking the movements of the host and initiating the required
mobility signaling on its behalf.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-04.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-netlmm-proxymip6-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-netlmm-proxymip6-04.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 11 Sep 2007 16:16:51 +0200

Sri, thank you for the new version of the draft.

Apparently it's insisted that PMIPv6 should rely on timestamps and time 
synchronization.  I oppose this, and I prefer the draft to not 
RECOMMEND, neither SHOULD, nor MAY relying on time synchronization nor 
timestamps.  But relying on sequence numbers, with a method I've already 
posted.

When this gets agreed in the WG I agree.

Until then, I have some nits about how time use is described in the new 
draft-04.

>    For solving this problem, this specification RECOMMENDS the use of
>    Timestamp option [Section 8.4].  The basic principle behind the use
>    of timestamps in binding registration messages is that the node
>    generating the message inserts the current time-of-day, and the node
>    receiving the message checks that this timestamp is greater than all
>    previously accepted timestamps.

(It's section 8.5 actually.)

>    Timestamp
> 
>       A 64-bit unsigned integer field containing a timestamp.  The value
>       indicates the number of seconds since January 1, 1970, 00:00 UTC,
>       by using a fixed point format.  In this format, the integer number
>       of seconds is contained in the first 48 bits of the field, and the
>       remaining 16 bits indicate the number of 1/64K fractions of a
>       second.

I think it should better say 1/65536 fractions of a second, and not 
1/64K fractions.  Let me say why.  64k means 65535 when talking bits and 
bytes.  If we talk anything else then 64k means 64000 (meters, seconds, 
Hertz, Joules, etc.)

I think we should also say in the draft that the timestamp contains the 
number of seconds measured at GMT (or some other place of your choice) 
since Jan 1st, 1970, 00h00 UTC.  Let me say why.  If we don't say where 
this timestamp was measured then there are different timezones on Earth, 
and a MAG in eg New Delhi will have a different timestamp than a LMA in 
Hyderabad, even if they represent the same moment.

Alex

[email-masked] wrote:
> ------------------------------------------------------------------------
> 
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 11 Sep 2007 21:34:16 -0700

Hi Alex,

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 7:17 AM
> To: [email-masked]
> Subject: [netlmm] Re: timestamps description (was: 
> I-DAction:draft-ietf-netlmm-proxymip6-04.txt)
> 

I know, you dont agree with this. Lets see how the thread
closes, based on that I will reflect the consensus.

> (It's section 8.5 actually.)

Ok. Thanks

> Hyderabad, even if they represent the same moment.

Ok. I used the description from 3971. But, this is a very good
comment. This is always relative to UTC. The reference point
for the delay, or the measuring point, have to at UTC. But,
easily implementations can blunder. Please suggest some text.
I'd love to say at Hyderabad, or if it makes you feel better,
we can say its measured at Bucharest or Paris. We can probably
leave GMT there. :)

Thanks
Sri

---

From: Julien Laganier <[email-masked]>
Date: Wed, 12 Sep 2007 15:11:47 +0200

Hi Alex,

I disagree with part of your comment:

On Tuesday 11 September 2007, Alexandru Petrescu wrote:
>
> >    Timestamp
> >
> >       A 64-bit unsigned integer field containing a timestamp.  The
> > value indicates the number of seconds since January 1, 1970, 00:00
> > UTC, by using a fixed point format.  In this format, the integer
> > number of seconds is contained in the first 48 bits of the field,
> > and the remaining 16 bits indicate the number of 1/64K fractions of
> > a second.
>
> 1/64K fractions.  Let me say why.  64k means 65535 when talking bits
> and bytes.  If we talk anything else then 64k means 64000 (meters,
> seconds, Hertz, Joules, etc.)
>
> I think we should also say in the draft that the timestamp contains
> the number of seconds measured at GMT (or some other place of your
> choice) since Jan 1st, 1970, 00h00 UTC.  Let me say why.  If we don't
> say where this timestamp was measured then there are different
> timezones on Earth, and a MAG in eg New Delhi will have a different
> timestamp than a LMA in Hyderabad, even if they represent the same
> moment.

UTC means coordinated universal time and is independent of any location. 
As such, the reference "January 1, 1970, 00:00 UTC" is a universal time 
value that has the same significance everywhere, independent of the 
location you're talking about. What goes in the timestamp in time 
elapsed since that reference (reference is used as an origin) and is 
thus also independent from the location.

Now for PMIPv6 all entities get UTC time and can get appropriate 
timestamps and no problem happens. 

(If you are concerned about a MAG which has only access to a clock that 
gives presentation of time, e.g. the GMT _presentation_, it's up to 
that MAG to translate GMT to UTC.)

In summary there's IMHO no need for additional text in the spec.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 12 Sep 2007 15:41:09 +0200

Julien Laganier wrote:
>>> value indicates the number of seconds since January 1, 1970,
>>> 00:00 UTC, by using a fixed point format.  In this format, the
>>> integer number of seconds is contained in the first 48 bits of
>>> the field, and the remaining 16 bits indicate the number of 1/64K
>>> fractions of a second.
>>  1/64K fractions.  Let me say why.  64k means 65535 when talking
>> bits and bytes.  If we talk anything else then 64k means 64000
>> (meters, seconds, Hertz, Joules, etc.)
>> 
>>  choice) since Jan 1st, 1970, 00h00 UTC.  Let me say why.  If we
>> don't say where this timestamp was measured then there are
>> different timezones on Earth, and a MAG in eg New Delhi will have a
>> different timestamp than a LMA in Hyderabad, even if they represent
>> the same moment.
> 
> UTC means coordinated universal time and is independent of any
> location. As such, the reference "January 1, 1970, 00:00 UTC" is a
> universal time value that has the same significance everywhere,

Right.  In this perspective I think I was wrong.

> independent of the location you're talking about. What goes in the
> timestamp in time elapsed since that reference (reference is used as
> an origin) and is thus also independent from the location.
> 

Are you sure that all entities can get UTC time?  In a reliable manner?

This is actually a requirement you put on these entities: use time in 
this and that manner.

> (If you are concerned about a MAG which has only access to a clock
> that gives presentation of time, e.g. the GMT _presentation_, it's up
> to that MAG to translate GMT to UTC.)

(Isn't GMT and UTC the same?)

I think you rely too much on requirements you can write in a spec. 
"It's up to that MAG to translate X-time to Y-time"?  I don't think we 
can write in a PMIP spec what entities should do with respect to time...

> In summary there's IMHO no need for additional text in the spec.

Err... I think you are right on this.

Alex