Subject: [nemo] RE: comments on draft-ietf-nemo-prefix-delegation-00.txt

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 29 Aug 2005 09:42:07 +0200

Thanks for this, Vijay :)

Comments inline:

>-----Original Message-----
>From: Vijay Devarapalli [mailto:[email-masked]]
>Sent: Saturday, August 27, 2005 1:11 AM
>To: [email-masked]; Pascal Thubert (pthubert)
>Cc: [email-masked]
>Subject: comments on draft-ietf-nemo-prefix-delegation-00.txt
>
>I quickly glanced through this draft and have one concern.
>
>>    Prefix Status (S) The Prefix Status (S) bit is set by a MR to request
>>    the full list of all prefixes that are already assigned to it
>
>I dont like the new 'S' bit in the Binding Update and Binding
>Acknowledgement. bits are scarce, especially in the Binding
>Ack. instead why dont we introduce a bit in the Mobile Network
>Prefix Request option (section 6.4), which when set means the
>MR wants to know all the prefixes assigned to it and when not
>set, means the MR wishes to a get a new prefix assigned to it
>as a MNP? I am assuming the MR includes the Mobile Network
>Prefix Request option in both cases (getting the list of
>MNPs or a new MNP). and for the response the HA could set a
>bit in the prefix option (that carries the prefixes) to
>indicate the response contains the complete list of prefixes.

[<PT>] Hum... The MNPR and the full status requests have different semantics. I believe mixing would be confusing. We had the same concerns as you have here, but the alternate we considered to the bit was a specific option, which seemed less overloading and confusing. There was not much to say in the option so we went for a bit, thinking that the list would decide. 

>section 3.3 does not seem to justify the new bit in the BU.
>maybe I am missing something?
>
>>    It is important that the HA set that bit in its full list of prefixes
>>    in order to differentiate between an empty list (there is no prefix
>>    for that MR) and no list (HA is not providing a list in that BA).
>
>what is the difference between an empty list and a no list?
>
[<PT>] What is the difference between an empty glass of côte du Rhone and no glass at all? Maybe a good memory, or great hopes?

I guess you're right, we need to make it a bit clearer.

If the HA does not send a list, the MR does not know what the HA thinks the MR owns (no list)
If the HA sends an empty list, it means that the MR owns nothing, as far as the HA knows (empty list). So there's a huge semantics difference and we need to be very clear on that.

>a minor comment
>
>>    The reader of that document is expected to be familiar with both the
>>    Mobile IPv6 [8] and NEMO Basic Support [10] documents.  As such, it
>>    is well understood that neither protocol provides the means for
>>    provisioning the Mobile Nodes and Routers with essential parameters
>>    such as Home Address and Home Network.
>
>we do have a bootstrapping solution for MIP6 now. :)
>draft-ietf-mip6-bootstrapping-split-00.txt.
>
>Vijay
>
>
>[email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Network Mobility Working Group of the IETF.
>>
>> 	Title		: Mobile Network Prefix Delegation
>> 	Author(s)	: T. Kniveton, P. Thubert
>> 	Filename	: draft-ietf-nemo-prefix-delegation-00.txt
>> 	Pages		: 27
>> 	Date		: 2005-8-22
>>
>>    This paper extends the Nemo Basic Support [10] for a Mobile Router to
>>    synchronize its Mobile Network Prefixes with its Home Agents and
>>    obtain new ones dynamically.  The proposed prefix delegation
>>    mechanism is agnostic to the way the prefixes are managed and
>>    provisioned at the Home Agent; it might be used for bootstrapping,
>>    resynchronization at binding creation or after a loss of states (eg
>>    MR reboot), MNP Renumbering, and configuration checking for loop
>>    avoidance.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-nemo-prefix-delegation-00.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-nemo-prefix-delegation-00.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-nemo-prefix-delegation-00.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.
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 30 Aug 2005 11:42:29 -0700

> [<PT>] Hum... The MNPR and the full status requests have different semantics. I believe mixing would be confusing. We had the same concerns as you have here, but the alternate we considered to the…

I would prefer a new option instead of the bit, if the mobile
network prefix request option can't be used. another question,
why does the MR care if the list contains the complete set of
MNPs or not? can't we have something like, if the MR requests
for information about the current set of prefixes assigned to
it, the HA responds with the complete set of prefixes assigned
to the MR. when would returning a partial list be useful? if
you think a partial list is useful, how does the HA decide
which set of MNPs to return?

if the MR wants a new MNP assigned to it, it includes the
Mobile Network Prefix Request option in the Binding Update and
gets a new prefix assigned.

> [<PT>] What is the difference between an empty glass of ctte du Rhone and no glass at all? Maybe a good memory, or great hopes?
> 

isn't the MR response same in both cases? if the MR does not
get a list or gets an empty list, it has to request for a new
MNP to be assigned. so why bother?

Vijay