Hello Charlie, From: Charlie Perkins <[EMAIL PROTECTED]>
> > 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? > > 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. 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. > > 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. > > 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. 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. > > 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. > > 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. 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 IIJ Research Laboratory <[EMAIL PROTECTED]> KAME Project <[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] --------------------------------------------------------------------
