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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 17 Nov 2006 18:00:41 +0100

Hi:

I performed some clean up and republished the draft, mostly as it was,
in order to restart the work on this dormant WG doc.

What was not changed (yet) is:

1) addition to DHAAD to located PD compatible HAs (my proposal, need
feedback)

2) Vijay's suggestion to get rid of the new bit to signal a full list is
required (see down this mail). Vijay proposes that the HA send back at
least one MNP option where the prefix is reset if there is no prefix
listed for that MR. We could also have a "full list" option with the
number of prefixes and then the prefixes one by one. We need to discuss
that...

What do you think?

Pascal

>-----Original Message-----
>From: Vijay Devarapalli [mailto:[email-masked]]
>Sent: Wednesday, August 31, 2005 7:48 PM
>To: Pascal Thubert (pthubert)
>Cc: [email-masked]; [email-masked]
>Subject: Re: [nemo] RE: comments on
draft-ietf-nemo-prefix-delegation-00.txt
>
>Pascal Thubert (pthubert) wrote:
>
>>>>>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.
>
>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.
>
>>>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.
>
>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