Subject: [nemo] Comments on draft-kniveton-nemo-prefix-delegation-00

From: Romain KUNTZ <[email-masked]>
Date: Mon, 13 Dec 2004 18:04:32 +0900

Hello,

Thank you for this draft. I have some questions and comments about it.

 > 6.3  Mobile Network Prefix option

After a Prefix Delegation procedure, the MR will send periodically a BU 
to its HA. I guess it sends each time the MNP options with the 
appropriate new bit set (P, I or D) ?
How does the HA handle the MNP options' new bits? I mean, if the P, I or 
D bit does not fit with what the HA expects, what should happen?

 > 6.4  Mobile Network Prefix Request option

What is a "Private" Prefix Type?
Why this type does not appear in the prefix type in the Mobile Network 
Prefix Confirmation option (section 6.5)?

When this option is present, the R bit must be set in the BU (same for 
Mobile Network Prefix Confirmation option).

 > 7.  Mobile Router Operation

Some status are missing (8 to 10). Is it because the expected behaviour 
is unknown yet?

How does MR should act when it receives an BAck with the S bit (Prefix 
status) set? I guess it should check each prefixes included in the BA 
with its prefixes, but what happens if some are missing in the BA or 
others are not registered on the MR?

Where does MR saves the corID? and the others new bits (if needed to be 
saved)?

It is written that "the Mobile Router will add either a MNP Option, or a 
MNPReq Option, or both". I guess that the MR can send a BU with a MNPReq 
Option (and without MNP option) if the MR first want to ask for a 
prefix, am I right?  If yes I think there is some conflict with 
draft-ietf-nemo-basic-support-03, section 5.3, where it is said:
"The Mobile Router does not include prefix information in the Binding 
Update in the implicit mode or when it runs a dynamic routing protocol 
with its Home Agent.". Then there may be some cases where you can not 
omit the MNP option in the BU.

 > 8.  Home Agent Operation

Is this section complete?

If the HA receives a BU with S bit set, I guess it includes as many MNPC 
options in the BAck as there are prefixes for the MR that sent the BU?

About step 4, shall the HA include the MNPC options in same order as 
MNPR options? I think this is easier from an implementation point of 
view, and this may avoid some interoperability issues.

Regards,

-- 
Romain KUNTZ
[email-masked]

---

From: "T.J.Kniveton" <[email-masked]>
Date: Tue, 21 Dec 2004 12:39:42 -0800

Thanks for your comments Romain.

On Dec 13, 2004, at 1:04 AM, Romain KUNTZ wrote:

> After a Prefix Delegation procedure, the MR will send periodically a 
> BU to its HA. I guess it sends each time the MNP options with the 
> How does the HA handle the MNP options' new bits? I mean, if the P, I 
> or D bit does not fit with what the HA expects, what should happen?

Well, the MR will not use an I flag in a BU.. that would kind of kill 
the whole point of implicit prefixes.

The P flag doesn't have much bearing, so it wouldn't cause much of a 
problem if the HA got something it didn't expect. The D flag is really 
used to communicate info from the HA to the MR, so again it doesn't 
really matter if the HA gets something it doesn't expect - it just 
means the MR has a bug.
> Prefix Confirmation option (section 6.5)?

You're right - that was removed, but it should be there.

> Some status are missing (8 to 10). Is it because the expected 
> behaviour is unknown yet?

It might have been an oversight -- but it is also somewhat 
implementation/deployment dependent what to do when a requested feature 
is unsupported.
> others are not registered on the MR?

Well, it could register those prefixes, depending on what type of 
prefixes they are and whether they had been attempted registered 
before. Do you think we should include complete information on how to 
deal with all possible error conditions? We could do it but it would 
make a BIG document.
>
> Where does MR saves the corID? and the others new bits (if needed to 
> be saved)?

Implementation detail. Probably in dynamic RAM, or possibly in 
non-volatile RAM for more robustness.

>
> It is written that "the Mobile Router will add either a MNP Option, or 
> a MNPReq Option, or both". I guess that the MR can send a BU with a 
> MNPReq Option (and without MNP option) if the MR first want to ask for 
> a prefix, am I right?  If yes I think there is some

Yes, that's right.

> conflict with draft-ietf-nemo-basic-support-03, section 5.3, where it 
> is said:

Well, if implicit mode is being used and the MR believes a prefix is 
already registered, it just sends a BU. If the MR doesn't believe a 
prefix is registered, it uses an MNReq to get one. If it doesn't know, 
it can send a BU with the S bit set, to get the status.

> If the HA receives a BU with S bit set, I guess it includes as many 
> MNPC options in the BAck as there are prefixes for the MR that sent 
> the BU?

That's correct. You're right, it should be listed in the HA operation. 
This still leaves an open question -- what if the HA sees prefixes 
assigned to the MR, but they are not currently in use. I.e. the MR has 
3 prefixes, but only 1 was included in explicit mode with the BU. But 
the BU had the S bit set.

> view, and this may avoid some interoperability issues.

I think that requiring this would go against precedent. But you're 
right, it would be easier from an interoperability point of view.

Thanks for your detailed reading.

TJ

---

From: Romain KUNTZ <[email-masked]>
Date: Tue, 28 Dec 2004 20:33:43 +0900

Hi TJ,

Thanks for your answer. Few comments inline...

T.J.Kniveton wrote:
> prefixes they are and whether they had been attempted registered before. 
> Do you think we should include complete information on how to deal with 
> all possible error conditions? We could do it but it would make a BIG 
> document.

As long as it would not create some possible interoperability problems 
between different implementations of the draft, I think it's ok.

> non-volatile RAM for more robustness.

Actually, what I meant is if it could be interesting to extend the 
binding cache/binding update list to store these datas. But as you said, 
it is implementation detail and does not need to be described in the draft.

Regards,

-- 
Romain KUNTZ
[email-masked]