Subject: Re: [mobile-ip] Sending HOT without route optimization: note or requirement?

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 02 Mar 2003 00:56:38 -0800

here we go again.... we are describing basic protocol behavior.
when sending HoT, existing binding cache entries should be
ignored. MUST and MUST NOT should not be used for describing
protocol behavior.

Ed Remmell wrote:
> Jari -
> 
> Yes, I agree with Bryan, we need a hard requirement for this somewhere
> (otherwise, a future implementor who isn't as familiar with the design might
> get it wrong). Please word it such that it makes it clear that route
> optimization MUST NOT be used in this case. For example:
> 
> "The CN MUST NOT use route optimization when sending a Home Test message."

how about
"The CN ignores existing binding cache entry for the home address
when sending a Home Test message"

avoid using MUST and MUST NOT when not needed.

Vijay

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 3 Mar 2003 08:12:41 -0800

Vijay -

OK, thanks for your response.

The thing that bothers me about this particular non-requirement is that it
is critical that it be implemented correctly on the CN, so that return
routability will be able to secure the binding update that the MN sends.

A CN implementor could decide that it is too slow to go through the home
agent when sending the HoT if it has an existing binding for the MN, and
then just use route optimization to send the HoT to the MN directly in that
case. That kind of defeats a lot of the purpose of using return routability.

I'm just interested in improving the spec, so we can just forget about
making any changes for this if you feel they are not required, that's fine
by me.

Thanks.
- Ed Remmell
Elmic Systems, USA

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Vijay
> Devarapalli
> Sent: Sunday, March 02, 2003 12:57 AM
> To: Ed Remmell
> Cc: Jari Arkko; Bryan Wang; Mobile IP Working Group
> Subject: Re: [mobile-ip] Sending HOT without route optimization: note or
> requirement?
>
>

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 3 Mar 2003 10:23:29 -0800

> case. That kind of defeats a lot of the purpose of using return

Or, more likely, this might not be a conscious choice, but by accident. That
could have been the case with our CN implementation, since we use a host
routing entry in the routing tree to implement the CN binding entry. So, our
CN send logic does a routing tree lookup to find the device/interface to
send the packet on. If there is a binding there for the MN's home address,
we will (by default) use it. We have to include special code in our CN
implementation for sending a HoT when there is an existing binding to avoid
using that binding. Without this being clearly documented in the
specification as a mandatory requirement (i.e. MUST, MUST NOT), it is more
likely that an implementor will miss this.

Thanks.
- Ed Remmell
Elmic Systems, USA

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 3 Mar 2003 11:45:46 -0800

We just took another look at draft 21, and I guess we were sleeping or
something ;-), but we seem to have missed the following requirement in
section 9.4.3:

"The Home Test message MUST be sent to the home address of the mobile node
without route optimization, even when there is an existing binding for the
mobile node."

So, this is a non-issue, thanks for your time.

Thanks.
- Ed Remmell
Elmic Systems, USA

> [mailto:[email-masked]]On Behalf Of Ed Remmell
> Sent: Monday, March 03, 2003 10:23 AM
> To: Vijay Devarapalli
> Subject: RE: [mobile-ip] Sending HOT without route optimization: note or
> requirement?
>
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Mar 2003 10:46:03 +0200

> So, this is a non-issue, thanks for your time.

You were probably looking at the latest draft from the web, where
I had already made the modifications you requested... before Vijay
complained about the keywords. The above text is not in draft 21.

Anyway, I think the change was useful -- even if Section 5 talks about
the same thing. The more exact language we use, the better. I don't
think there's a need to worry about keywords in this text. Even the
requirements for a MUST, as specified by RFC 2119, are fulfilled here.

I have classified this as an editorial modification in issue #267 along
with some other minor edits.

Jari