Pekka, Just as a comment. I am reading your many new drafts. They are very good reading too. But you seem to be wanting to standardize "implementation" practices often in your drafts and emails. In the IETF we do and should not standardize that which is implementation or usr configurable or usr database etc. Another example was a recent exchange between an AD and another member who is a routing vendor expert. The AD was asking some pretty basic questions about why a routinug table should or should not do something and that we may want to standardize it. My point of relaying this is that we need to build protocol standards our job is not to build standards for implementation.
That being said. When you ask to build a standard for implementation I simply won't respond to so you won't hear from me and I am one of the implementors on this list for much of what you ask that could respond. If you want to discuss implementation we have IPv6 implementation lists that are not part of the IETF. regards, /jim > -----Original Message----- > From: Pekka Savola [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 10, 2002 9:02 AM > To: Erik Nordmark > Cc: [EMAIL PROTECTED] > Subject: Re: Implementation worries about default address selection > > > On Wed, 9 Oct 2002, Erik Nordmark wrote: > > > > > > The thing is, it seems like this (IMO relatively complex) > iterative > > > comparison algorithm must be run for every outbound > packet (one might be > > > able to optimize a bit with connection-oriented protocols). > > > > I think connection oriented protocols effectively require that > > the source address (or addresses in the case of SCTP) be selected > > when the connection is created. Thus trying to do this for > every packet > > would be the wrong thing in that case. > > Agreed. > > [...] > > > > An alternative seems to be to implement some form of > (unspecified -- > > > caching is only discussed in the context of dst address selection) > > > optimizations. One example of optimization could be putting the > > > to-be-used source address in the routing table, and > refresh it always when > > > rtable or any address of the node changes or changes state > > > (deprecated/preferred, home address etc.), but these > might have their own > > > problems. > > > > > > My worry is, is it useful to specify a mechanism for > selection default > > > addresses that can't really be used without critical > optimizations? > > > > I'm not worried about this. We have exactly the same issue > for routing table > > lookup in hosts and routers; there is no specification that > states how > > to implement caching schemes. > > We haven't really specified the source address selection like > this for > IPv4 either, I believe. Have I missed something? > > Routing table lookup is very simple compared to this I think. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > 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] --------------------------------------------------------------------
