Hi Charlie,
TCP flow control was implemented in response to congestion collapse in
the late '80s. If something like that happens as a result of widespread
Mobile IP implementation, you can be sure that it will become a MUST.
:-) But, for now, it is very easy to see the extra amount of work route
optimization would add to implementing an IPv6 stack, but very hard to
see what effect lack of route optimization would have on traffic flow in
the Internet when mobile nodes are widespread (though, of course,
everyone has an opinion). So making it a SHOULD seems like the best
tradeoff.
It is really too bad that there is not some kind of large scale,
supercomputer simulation of the Internet that we could tweak when these
kinds of questions come up. This would allow the IETF to base decisons
on some kind of data (though people do argue about simulations) rather
than just on intuition.
jak
----- Original Message -----
From: "Charlie Perkins" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Tuesday, May 28, 2002 10:53 PM
Subject: Re: Mandating Route Optimization
>
> Hello Hesham and John,
>
> Your analysis about MUST/SHOULD would imply that hosts
> SHOULD implement TCP's particular flow control mechanism,
> whereas in fact they MUST, for the health of the Internet.
> Thus, I do not believe that you have put forward the correct
> basis for making the determination. I think that we can mandate
> this behavior on the basis that the future Internet will suffer to
> the extent that we do not. Maybe we have enough remote
> bandwidth today to place delay bounds that people today
> find acceptable, but there is not any assurance whatsoever
> that this will be the case 10 years from now, nor even 2 years
> from now if we solve the problems of really reliable interactive
> voice and video within the nearer term future. Yet, IPv6 is
> supposed to last for many more years than that.
>
> While I do not think that the case for mandating Route
> Optimization is as strong as for mandating flow control
> under TCP, I think it is very strong nonetheless, exactly
> because noncompliant hosts will have distant and negative
> effects on many other nodes in the Internet. In fact, I would
> say that the problems introduced by failure to implement
> Route Optimization will motivate the introduction of kludgy
> substitutes, much as the lack of address space for IPv4 has
> motivated the introduction of NATs.
>
> We have to do better. I would say that the case for Route
> Optimization is at least as strong as for IPsec and for
> stateless address autoconfiguration, if not as strong as
> the case for TCP. And, none of these four examples
> fit within the guidelines that are suggested by Hesham.
>
> Regards,
> Charlie P.
>
>
> [EMAIL PROTECTED] wrote:
>
> > Hi Hesham,
> >
> > > => Not only, but there are also rules for MUSTs and SHOULDs.
> > > My understanding is that we only mandate things (MUST) if
> > > not doing it will break communication. MIP was designed to
> > > make ensure that it works with or without RO. So according
> > > to my understanding of the use of keywords, it should not
> > > be a must. Of course it is an important feature and therefore
> > > SHOULD is appropriate IMHO.
> >
> > That is my understanding. However, I would like that the SHOULD
> > should have teeth to it. What I mean is that we should make
> > a strong case on how RO will help hosts, lead to better operation,
> > 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 PROTECTED]
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> 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 PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
