Subject: RE: [mobile-ip] still more iesg comments on the base

From: "Ed Remmell" <[email-masked]>
Date: Mon, 7 Apr 2003 11:53:04 -0700

(resent because of recent email storm)

Erik has done a fairly thoughtful review of the material.

"Section 9.5.2 talks about the CN reducing the lifetime
of a binding. Given that the MN might continue sending packets with HAO
until the MN thinks the binding times out it seems unwise for the CN
to limit the lifetime unless it explicitly informs the MN by sending a
BAck."

I disagree with this. I believe that the MN will in most scenarios be
pulling large amounts of data from the network/CN, not the other way around.
So, the MN will not be sending a bunch of packets with a stale HAO
back-to-back to the CN, rather it will likely send a couple before it gets
the BE back from the CN (no binding for HAO) that causes the MN to resynch
to the CN's binding (or lack of binding) state. I like the current design.
The current design has the CN deciding the lifetime of the binding that it
created for the MN. The CN makes no specific guarantee when it sends the BA
that it will keep the binding in its binding cache for the Lifetime
indicated in the BA, that is how it should be IMHO. If the CN wants the
binding to be refreshed, it sends a BRR to the MN before the lifetime of the
binding expires, otherwise the binding will expire. The MN is not
responsible for initiating a refresh of this binding, the CN is entirely
responsible. That contrasts with the home registration binding that the MN
creates in the HA - in that case, the HA has guaranteed that the Lifetime
returned in the BA is how long it will maintain the active binding for the
MN. Also, in that case the MN is responsible for refreshing the home
registration binding. I think this is a good design.

Jari responds:
"Finally, we could prohibit lifetime reduction if A=0."

I wouldn't add that complexity. Please just keep it simple. Currently, the
CN makes no guarantee, A=1 or A=0, about the lifetime of the binding that it
creates for the MN. It may delete that binding at any time, before the
lifetime that it communicated to the MN expires. That is the best/most
flexible design, IMHO. Please remember that some CNs will be embedded
systems and not Linux/etc. servers, and embedded systems actually do have
significant RAM memory constraints, so allowing the CN to arbitrarily free
up the memory/resources that a BCE is using when the CN decides that BCE is
no longer needed is a nice feature, I think.

"Section 11.7.2:
   In addition, when a mobile node receives a packet for which the
   mobile node can deduce that the original sender of the packet has a
   stale Binding Cache entry for the mobile node, the mobile node SHOULD
   initiate a correspondent binding procedure.
How does a mobile node tell that the sender has stale info?
By the fact that the packet was not send to the MN?"

I interpreted this as referring to the case when a MN receives a ULP packet
from the CN via the MN-to-HA tunnel, in which case it knows that the CN
doesn't have an active binding anymore since ULP packets would be route
optimized if the binding existed. But, then I agree that "state Binding
Cache entry" isn't the same as no BCE, so then I don't know what this is
trying to say.

Jari responds:
"Perhaps we should just delete this statement."

I agree with Jari.

Thanks.
- Ed Remmell
Elmic Systems, USA

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: Saturday, April 05, 2003 2:26 AM
> To: Mobile IPv6 mailling list
> Subject: [mobile-ip] still more iesg comments on the base
>
>
> For your information: Erik has completed his review and he had a long
> list of comments:
>
>    http://www.piuha.net/~jarkko/publications/mipv6/issues/issue289.txt
>
> I've sent an initial response, and there doesn't seem to be any
> showstoppers. But we need to work on e.g.
>
> - clarifying that mobile node's must use the currently registered care-of
>    address when sending packets
> - the configuration knob for disabling RO (discussed earlier in #236)
> - destination cache - binding cache relationship needs to be
>    worded differently
> - whether text is needed to avoid including RH2 on link-local
>    packets
> - whether hom agents should need to learn information from other
>    home agents for the purpose of prefix distribution
> - etc.
>
> Jari
>
>
>