Subject: Re: Mandating Route Optimization

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Mon, 03 Jun 2002 14:03:03 +0900 (JST)

Hi,

From: Vijay Devarapalli <[email-masked]>

> sorry about the earlier mail. I realised it was rude and not 
> called for. 

No.  Never mind.  (I'm afraid my poor wording may make people feel
uncomfortable...)

> I will try to rephrase what I said. the CN implementation as it
> is described in draft-17 is quite simple (IMO). a lot of care was
> taken to make the CN as stateless as possible (at the cost of
> extra work by the MN).

(As I said in a private email,) The stability is a problem for the
implementors.

Please note, I'm not saying that the current RO/RR is bad.  I like RO
and the current draft seems OK but should we have more time to check
it?

If we find a new method for RO and obsolete RR, how do we handle
already shipped RR based implementation?  There may be a problem.  For
example, we had (unverified) HAO in old drafts.  Some implementation
support us and implement it.  But it (unverified HAO) is now
obsoleted.

I think it is too early to make it MUST.  It is not too late after all
of MIP6 vendors implement the draft and experient several interop
tests and all of us are convinced it is OK to go.

Best Regards,

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>
--------------------------------------------------------------------
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: Charlie Perkins <[email-masked]>
Date: Sun, 02 Jun 2002 22:35:32 -0700

Hello,

> and the current draft seems OK but should we have more time to check

Return routability, in general, has been under discussion for well
over a year.  I think the basic idea came up over 18 months ago.
Then there was BAKE and several other drafts.  Then there was
bu3way.  Some of these have been implemented.  The basic
ideas are pretty well understood, and as with any protocol more
experience will further improve our knowledge.

> support us and implement it.  But it (unverified HAO) is now

This is a very long story.  Until a protocol specification reaches
proposed standard, implementations are at risk of becoming
obsolete -- even after that.  This has happened with practically
every protocol I can think of, to some degree or another.
For instance, even with IPv6, the planned TLA and SLA bits
are now obsolete, even though they were planned out for a long
time.

To make an analogy, if you wait for the fastest processor technology
before buying, you will never buy, because there is always something
better on the horizon.  At least we can make for compatibility, though.

In this circumstance, it is a lot easier to _not use_ return routability
if something else turns up, than it is to _use_ return routability, if it
is not mandated.  I have made several arguments why it should be
mandated, and as best I can tell the strongest counterargument is that
it's not standard yet, so how can we mandate it?  I believe this to be
a circular argument.

> tests and all of us are convinced it is OK to go.

If the behavior is mandated, and something goes wrong, I reckon
we'll have to revise our understanding in the future.  As it is now,
it's the best we know, and it's pretty well understood.  Everyone
believes we will have something better in the future, and so I am
trying my best to make sure the protocol is extensible for that future
optimization.

Regards,
Charlie P.

---

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Tue, 04 Jun 2002 14:41:45 +0900 (JST)

Hello Charlie,

From: Charlie Perkins <[email-masked]>

> experience will further improve our knowledge.

Yes.  It has been discussed for over a year, but none of us has not
made it work.  As an implementor, I think it is dangerous to make such
a specification mandate for all IPv6 nodes.

It is too late if we find any problems after we have mandated it.  But
it is not too late to decide whether we make it mandate or not after
all of (or most of) us are convinced it must be.  Before the decision,
we should experience more.  Fortunately, the latest MIP6 works with
IPv6 nodes which do not support even HAO.  There is no impact against
the current Internet.  After this experience, if people think RO must
be MUST, lets' revise the node requirement draft.  I think it is
better to move gradually (and we can with the latest draft).

I don't understand why you are in so haste.  There are already many
IPv6 nodes shipped in the world.  All of them do not support MIP6.  We
can live with them using MIP6.  Also, we can move gradually to the
RO'ed world.

> it's not standard yet, so how can we mandate it?  I believe this to be

I think most of the vendors will choose what their customers want.  If
many people want RO, the vendors are going to ship their products with
RO support.  I beleive the vendors never discard the SHOULD spec just
because it is easy way.  They don't implement the specs because it is
not what people want.

> trying my best to make sure the protocol is extensible for that future

Needless to say, RO is better than not RO.  I think the point is how
to deploy RO.  I don't think it good idea to make it mandate now
because the reasons described above.

Best Regards,

---
Keiichi SHIMA