In einer eMail vom 26.07.2008 16:22:28 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]:
The document it was based on is still at http://www.cs.auckland.ac.nz/~brian/DFZng.pdf. I would probably used different terminology today; it certainly isn't a worked-out proposal. Brian Brian, Your draft reminds me of PNNI although your hierarchy is based on BGP/DV and not OSPF/Dijkstra. PNNI's hierarchy had to be in compliance with some particular AFI, i.e. with prefixes from one of these 4 :Data Country Code, E.164, designated numbering for enterprises, private numbering plan. Concurrently all the remaining 3 AFIs had to be serviced nevertheless as well. Myself, I would have favored the hierarchy of your solution, if I wouldn't have made progress meanwhile with respect to: getting rid of ALL this prefix building stuff, getting rid of the need for configuration (who is border node, who is peer group leader; a router wouldn't even need some configurational data that indicated up to which hierarchical level it has to deal with) - and finally getting rid of a fix hierarchy itself. DV-based versus topology-aware: Not long ago Lixia asked for comments regarding a draft which praised the map-encap's benefits for multipath. There is a proverb: The whole is more than the sum of its parts. Applied: The topology is more than all routes to all destination nodes. By knowing the topology all routes to some destination could be provided (including those which contain some crankback hops). But certainly not, given today's BGP, where a router has no idea what happens (transitively) with an UPDATE message it is forwarding. Also, a router does not inform a neighbor about a worse route, if this neighbor has told him a better route. I.e. distance vector based solutions prevent perfect multipath routing. Heiner
