In einer eMail vom 11.11.2008 21:11:03 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]:
Heiner, your proposal is interesting. But I think it is orthogonal to the new network protocol stack proposal that I am making. Agreed. Orthogonal means, they do not substitute each other. And also : they do not harm each other. I don't see how one would enable or improve the other. Enable: My concept (TARA) wouldn't have any problem with any form of receiver's identification. Improving each other's topic: No. Because they are indeed orthogonal. In fact, whereas your proposal changes the routing system, my proposal is fundamentally host-based. The way in which my proposal will benefit the routing system is instead: - by making the use of provider-allocated addressing in edge networks more acceptable, and - by making (unilateral) IP address translation a more acceptable solution for provider-independent addressing in edge networks without compromising global routing scalability. The reason for (1) is that renumbering becomes simpler with the new network protocol stack since it no longer affects applications/host. With TARA there is no reason at all to care for prefix building capability or for renumbering, nor is there any need for caching. Note, LISP promises to reduce the scalability problem. So far I haven't seen a single line from when on the BGP routing table will start to shrink and how this is done so that at some later point in time its size is zero. I have heard that there are already LISP implementations but I can hardly imagine that _www.cisco.com_ (http://www.cisco.com) is already off the BGP table. (I could argue more but this is not your topic :-) The reason for (2) is that the new network protocol stack makes applications immune to unilateral IP address translation. I can imagine that a cleaner split between the layers is an objective by which the upper layers might benefit. This may be an additional problem, and I am sure that TARA would be helpful here too. But first of all, the scalability problem is a networking layer internal problem and I am afraid that the term SPLITTING has lead the RRG onto the wrong track. Instead ADDING l o c a t i on is needed and is concurrently sufficient to get rid of the whole problem. Heiner - Christian On Nov 11, 2008, [EMAIL PROTECTED] wrote: >> are you thinking of forwarding packets based on the destination >> hostname while the packet is within an edge network? That could, of >> course, be an extension to the proposal I am making. > > > Yes. My saying since 45 is of course that there is no reason to route > based on worldwide user reachability information dissemination, > i.e. that this scalability problem can be eliminated completely. > Provided: Each DFZ router has a consistent view of a well-sparsed > internet topology, while knowing the geo-locations of all viewed > nodes, > and the geolocation related to the IP packets' destination which > should > be the geolocation of that router toward which forwarding shall/ > could be > done without looking at the destination IP address. > > That router is - normally - a router of the service provider at the > service provider's site. Behind that point routing could either be > done > traditionally, i.e. based on the destination IPv4 resp. IPv6 address > or > based on something else like: e.g. host name or E.164 without DNS > mapping, or... or...or... And of course also based on geolocation > information of an intra-domain edge network. > >> The proposal >> right now, however, uses IP addresses for routing; the hostnames are >> included only in the first packets of a connection in order to sync >> the two peers. > > I know. > > Heiner
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
