In einer eMail vom 16.12.2008 20:02:33 Westeuropäische Normalzeit schreibt [email protected]:
I really thought deserved a substantial reply...> > From: "Fleischman, Eric" <[email protected]> > Date: Mon, 1 Dec 2008 10:45:43 -0800 > Map-and-encaps shields the host from knowing the actual network > topology such that an arbitrarily complex network topology can be > created that is transparent to the end user host This is also true of the existing internetwork layer, though... It's an interesting point as to whether this is a correct architectural choice, or whether some applications want/need to be _able_ to see more (i.e. it would not be mandatory, and those applications which didn't need it could/would continue in blissful ignorance, just as most applictions now don't care about virtual memory) - but that's not the main point I want to go over here, so I'll pass on, and leave that for another day/thread. Promise: By TARA each DFZ router would get a view of the entire internet which is a) good enough to determine the best next hop, b) which would hardly encompass more than 2000 links. The amount of the respective data is so little that in case "some applications want/need to be _able_ to see more" the multihomed user might request the respective internet topological view from each of its DFZ routers for being evaluated/compared as to make the right decision from the application's point of view. It is no secret: If your basic architecture needs very little wrt to memory and/or time (like at most 3 table offsets) then more sophisticated applications will only require a multi-fold of just these very small numbers. Concurrently, it becomes easily affordable to provide everything for a 100 % multipath capability (i.e. both from the memory and performance prospective) Heiner
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
