On Tue, Nov 10, 2009 at 2:43 AM, Lixia Zhang <[email protected]> wrote: > personally I share your view that the current text on that page is > inadequate. > I'd also like to suggest that we take constructive actions to help improve > it.
Hi Lixia, Let's start with the definition of "address." Do we know enough at this point to start redefining the concept of a network address in terms of other elements? I'm comfortable saying that we know enough about the overloaded functions on an address to be pretty sure we don't yet know enough to concisely redefine "address" in terms of those functions. We might want to define other elements in terms of the network address but I'd like to see us leave the redefinition of "address" for later researchers who've seen the components in use individually. Next, let's realize that there are THREE categories of information relevant to the RRG that the address interacts with, so as we define elements like locator or identifier, we should expect to find at least three. Not merely two. The categories are: 1. information used directly by the packet forwarding process to move data packets to an endpoint. 2. information used to anchor the relationship between a communications endpoint and a specific set of packet forwarding processes which reach it. 3. information which is entirely unrelated to the packet forwarding process A key observation here is that everything within the scope of our discussion ties back to the packet forwarding process. Not the more abstract notion of network topology and certainly not the vague idea of a network attachment. Any elements we identify in these three categories, then, should be definable in terms of a precise relationship to the packet forwarding process. Examples of network address use in each of the three categories include: 1. The IP destination address looked up the FIB for packet forwarding. 2. The IP source address which specifies an endpoint to which return packets should go. (The packet source address is NOT necessarily a locator!) The DNS A record which maps an endpoint's hostname to a current set of destination IP addresses. 3. The TCP connection ID composed from the source and destination IP address and port numbers, used exclusively to associate individual IP packets with the connection of which they're a part. The difference in the three categories from a routing perspective is: 1. We'd prefer the packet forwarding elements change from moment to moment with the network topology. If they don't, we have to force the topology to fit the forwarding elements, making it very complex. 2. We expect the mapping to change when the forwarding elements change so that whatever it maps from doesn't have to. 3. Elements outside the scope of the packet forwarding process should never be required to change as a result of a change in the packet elements used for forwarding process. Important consequences of this are: a. Locators aren't about network attachments. They're about the packet forwarding process and more abstractly about the network topology. An element that always has exactly one attachment to the network is likely a holy grail. Case and point, the IP address on my BGP router with two upstreams is certainly a locator but it clearly has two points of attachment. b. Identifiers as we're currently discussing them blur the line between information categories 2 and 3. When we correctly understand them, if they're the right conceptual framework in the first place, they'll fall squarely in one category or the other. 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] http://www.irtf.org/mailman/listinfo/rrg
