Face it: Many of today's large web servers will not want to maintain binding caches. Because: - They are clustered (see my previous mail on this thread) - Visits are short and unrelated (the caches are not reused) - RR reduces the throughput and the response time - They may even blindly accept the Home Address option since the AAA takes place at session level anyway using cookies and such.
How much of the global IP traffic does this represent today? What will mobile devices do at least in the short term? We must provide a way for servers to simply and politely decline RO. We may want to permit triangular routing. The minimum we can do to ease IPv6 transition is at least to allow the current v4 applications to run in equivalent conditions. It's a SHOULD. Pascal -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Behcet Sarikaya Sent: Thursday, July 18, 2002 4:26 PM To: Michael Thomas Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated Michael, I do not understand why you are insisting on SHOULD? If IETF is not against having such MUSTs as in this case, let's have it. How can a revolutionary technology such as MIPv6 allow HA reverse tunneling like MIPv4 does? Another benefit will be to mandate HAO in any new implementations. Becasue of all these, I think that we should (or MUST) keep the MUST there, what the heck? Regards, Michael Thomas wrote: >[EMAIL PROTECTED] writes: > > > Given that MIPv6 will interoperate without binding > > > code in CN's, it looks pretty much like a SHOULD > > > to me. Indeed, the protocol would not be robust if > > > it didn't consider the case of a non-conformant CN. > > > > I think we want to ask is, is it the right thing to do? For > > proper protocol functioning, will this lead to the correct > > behavior. If we think it is important, the MUST is OK. The > > spec does contain a mechanism to support existing implementations > > of IPv6, which means the protocol designers are doing their > > jobs. > > I think we're straying into a "good" as in > "good for the overall health of the Internet" > kind of good, rather than a "good" as in will > the protocol operate correctly. For the former, > I think you need to have extremely compelling > motivation, as well as a lot of evidence that > the health of the net will be imperiled if *all* > nodes don't implement a particular function, which > is what is at issue here. > > Frankly, I don't think that there is any evidence > that the net would be substantially harmed if RO > wasn't widely implemented and/or enabled. Indeed, > I think there's good reason to believe that many/most > nodes will not enable RO even if their kernel > implements it. In some cases, it's likely to be > a nice and useful optimization, but I really > don't see it as a "if we don't do this the net > will fall apart". As such, SHOULD seems like it > strikes the right balance. > > Mike > -- Behcet -------------------------------------------------------------------- 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] --------------------------------------------------------------------
