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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 31 Aug 2005 12:03:08 +0200

>-----Original Message-----
>From: Vijay Devarapalli [mailto:[email-masked]]
>Sent: Tuesday, August 30, 2005 8:42 PM
>To: Pascal Thubert (pthubert)
>Cc: [email-masked]; [email-masked]
>Subject: Re: comments on draft-ietf-nemo-prefix-delegation-00.txt
>
>Pascal Thubert (pthubert) wrote:
>> 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.
>
>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?
>
[<PT>] Well, it would be either asking for a new prefix or for the
complete list of all prefixes. There's no concept of partial list in the
draft. 

>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>] Yes, that's how it's proposed...

>>>>   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 ctte 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.
>
>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?
[<PT>] When the MR asks for the list (the bit is set) and the HA
responds with the bit set but nothing listed, the MR knows it needs to
obtain new prefixes. OTOH, if the HA does not set the bit (no list) then
the MR does not know what the HA has for it, which is the current NEMO
support. The MR can try both implicit or explicit modes, but does not
necessarily need a new prefix delegated. You might see that as backward
compatibility.

Pascal

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 31 Aug 2005 10:47:55 -0700

> complete list of all prefixes. There's no concept of partial list in the

I am more confused now. so why do we then need a bit to indicate
"complete set of  prefixes", if the complete list of prefixes is
always returned?

the request for a new prefix is explicit through the inclusion of
the Mobile Network Prefix Request option.

> necessarily need a new prefix delegated. You might see that as backward

forget the bit for now. I would really like to see the bit in
the BU removed. here is one proposal.

we define a new option, "MNP Information", that can be carried
in a BU and BAck.

- the MR wants to know what MNPs are assigned to it

   the MR just sends a BU with the MNP Information option, with a
   bit set to indicate that it is a request, to the HA. if the HA
   implements draft-ietf-nemo-prefix-delegation draft it responds
   with a list of prefixes using the MNP Information option, but
   with a bit set to indicate that it is a response. if there are
   no prefixes assigned to the MR, the HA returns an empty MNP
   Information option. if the HA happens to be a RFC 3963 HA that
   does not implement draft-ietf-nemo-prefix-delegation, it just
   ignores the MNP Information option and includes nothing in the
   Binding Ack. here I have avoided using the Mobile Network
   Prefix option defined in RFC 3963. Mobile Network Prefix option
   was designed to carry just one prefix. it can't carry mutliple
   prefixes. to carry multiple prefixes, RFC 3963 says, multiple
   MNP options have to be included in the BU.

- the MR wants to get a new prefix assigned

   the MR includes the Mobile Network Prefix Request option
   (defined in draft-ietf-nemo-prefix-delegation) in the BU
   and gets the prefix from the HA. if the HA does not implement
   draft-ietf-nemo-prefix-delegation, then the option is ignored.

let me know what you think about this proposal.

Vijay