Hi,
I don´t see number 2 as completely orthogonal, this is why: since the IP is used as part of the session identifier it becomes a requirement for it to don´t change, then when you implement mobility or multihoming you end up with schemes that impact routing (inject prefixes). This is from a message from Robin Whittle a couple of days ago that explains it better than I could: If the Internet had been designed so the hosts were somewhat smarter - so they could operate perfectly well despite their IP address changing at any time - then we probably wouldn't have a routing scaling problem. We would already have something like SHIM6 or ILNP. Regards, Damian From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: November-21-08 2:59 PM To: [EMAIL PROTECTED]; [email protected] Subject: Re: [rrg] Summary of architectural solution space The root cause of the routing table growth problem is that we're using the same element (IP address) to express three distinct concepts: 1. the globally unique identity (GUID) needed by the originating client system to find the destination server, 2. a component of the session identity (SID) used by the layer 4 and higher protocols to keep track of communications with other hosts, and 3. the node's present location or locations (LOC) within the network topography. I would put it a little bit differently: The root cause is that, by the current routing architecture, just a globally unique identity (GUID) is used for finding both the egress router as well as the destination server. And also: Point 2, although true, is a different topic, but is orthogonal to this problem. Heiner In einer eMail vom 21.11.2008 21:43:32 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]: On Fri, Nov 14, 2008 at 4:58 PM, William Herrin <[EMAIL PROTECTED]> wrote: > http://bill.herrin.us/network/rrgarchitectures.html Hi Folks, The third draft is now available at http://bill.herrin.us/network/rrgarchitectures.html . It adds a strategies D, E and F to the solution universe and moves the major criticisms of each strategy to a separate subheading so that the criticisms don't clutter the description of the approach. The second draft is archived at http://bill.herrin.us/network/rrgarchitectures2.html For the folks who offered suggestions on the earlier drafts: Thank you. Have I addressed the issues you brought up? How can I further improve the document? For everyone: I'd like to close this document after this draft. If you have any additional comments or criticism, now's the time. Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
