Subject: RE: Mandating Route Optimization

From: [email-masked]
Date: Fri, 31 May 2002 19:32:12 +0300

Hi Michael,

> I don't know if this has been mentioned, but
> regardless of whether implementation of RO for
> CN's is a MUST/SHOULD, there should be text in the
> draft that "RO MUST have a means to be
> administratively disabled on the CN."

I agree with you.  I do think that additional work
will be needed to detail how RO is used, if there
is a need for protocol negotiation, etc. I think
that the important thing is to have a strong
statement of support for implementing RO.  How
RO is used probably needs some real deployment
experience, etc.  I think that RO needs to be
implemented, but its use is probably still open
to local control, etc.

John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 31 May 2002 09:49:35 -0700

Hello John,

[email-masked] wrote:

>                   I do think that additional work

If there is any issue here, it is mainly a matter
of allowing mobile nodes to hide their location.
That's simple -- the node should simply do reverse
tunneling, and not issue HoTI and CoTI.

I can't imagine a reason why a correspondent node
would prefer to have traffic going through the
home network rather than directly to its mobile
communications partner, but if there is a reason,
then certainly the correspondent node can simply
avoid sending HoT and CoT.

Even with HoTI, CoTI, HoT, CoT, and BU mandated
for implementation, the mobile nodes still have
to correctly and courteously handle the cases
where HoT and CoT and even Binding Error messages
are never received.

I hope these matters will be viewed as specified
clearly.  Anywhere they are not, we should fix.

Regards,
Charlie P.