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

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Dec 2006 20:23:14 -0800

Pascal Thubert (pthubert) wrote:
> 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.

Do we still need this work? Perhaps DHCPv6-based
prefix delegation is sufficient for NEMO?

> 
> What was not changed (yet) is:
> 
> 1) addition to DHAAD to located PD compatible HAs (my proposal, need
> feedback)

Not needed as explained below.

> 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?

I still think what I suggested earlier is cleaner
solution. The current draft is way to complicated
for a protocol that is supposed to request for a
prefix and get one assigned. Here is my earlier
proposal again.

>> 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

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 12 Dec 2006 18:10:52 -0800

Vijay,

The draft was intended to be simple, but there is more signaling info 
that is needed other than just "request and assign" a prefix. For 
instance, how long is the prefix supposed to last for? Is it permanent? 
How do I negotiate the length of the prefix? How do I know, if the 
request fails, why it failed and what I should do about it?

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Dec 2006 20:59:49 -0800

I think we can still keep the protocol simple.

> instance, how long is the prefix supposed to last for? Is it permanent? 

Two options.

1. Make it last as long the mobile router has a binding
cache entry at the home agent. The prefix after all was
obtained through a Binding Update/Binding Ack exchange
that created the binding cache entry.

2. Add a lifetime field to the option which carries the
prefix.

> How do I negotiate the length of the prefix? 

There is no negotiation. The Home Agent always tells the
MR what the prefix length is. Anyway if the prefix is
going to be assigned to the subnet which corresponds to
the mobile network, it has to be /64.

> How do I know, if the 
> request fails, 

No response from the HA in the binding ack.

> why it failed 

Does it matter to the mobile router? The mobile router
just needs to know that the HA can't assign it any
prefix.

> and what I should do about it?

Try another Home Agent? If that fails too bail out?

Vijay

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 13 Dec 2006 23:00:38 -0800

Sounds like you want to have a method to assign a very temporary MP.  
We were thinking more about requesting a longer-term MP. I don't  
really have an opinion about whether one or the other should be  
preferred, but usually granting of something like a prefix would be  
more longer-term..

On Dec 12, 2006, at 8:59 PM, Vijay Devarapalli wrote:

>> The draft was intended to be simple, but there is more signaling  
>> info that is needed other than just "request and assign" a prefix.  
>> For instance, how long is the prefix supposed to last for? Is it  
>> permanent?
>
> Two options.
>
>> How do I know, if the request fails,
>

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 13 Dec 2006 23:00:38 -0800

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Dec 2006 23:30:40 -0800

T.J. Kniveton wrote:
> Sounds like you want to have a method to assign a very temporary MP. We 
> were thinking more about requesting a longer-term MP. I don't really 
> have an opinion about whether one or the other should be preferred, but 
> usually granting of something like a prefix would be more longer-term..

Just add a lifetime field to the option. A 32 bit
lifetime field gives you 136 years of lifetime for
the mobile network prefix. That should be long
enough.

This was one of the options I had suggested in my
earlier mail.

Vijay