[rrg] Aggregatable EIDs

[[e-mail]]

 
This is a third attempt to respond to Tony Li via the rrg-mailinglist.  Two 
preceding attempts were neither mirrored back nor included in the  archive.
I also try some rephrasing.
Heiner
 
In einer eMail vom 02.01.2010 20:57:52 Westeuropäische Normalzeit schreibt  
[e-mail]:

Hi  Heiner,
>      > Suppose that a geopatch has only a  single TARA-router in it.  It 
then
>      >  becomes the decapsulator for all TARA traffic arriving into that
>   > geopatch.  Who pays for this router?  Who pays to  deliver traffic
>     from
>       > this router to the destination access ISP?
>       > 
>      > What is precisely the scenario ? You  pressume that the
>     destination EID
>   > has a TARA-locator, being put into the DNS by  some
>     non-TARA-router ????:-(
> 
>  
>     No, again, there's a single TARA-router.  I'm  interested in the
>     topology
>   and routing internal to the geopatch.  This is the  problematic area for
>     all geo-aggregation  proposals.
> 
> Note, this TARA model will yield stretch 1 !!!  Only the process how to 
> acquire the flat TARA-map is somehow  hierarchically organized.
>  
> Whereas hierarchical  topological models a la PNNI are bad   -  the 
>   process itself, as well as  the outcome. The Compact Routing studies  
> have shown how bad. 


I'm still not understanding your  response to this key point.



Indeed, this is a key point, and I hope you see that  my kind of  hierarchy 
is completely different to all the others.
According to TARA there are 64800 hierarchies. On top ( and not at the  
bottom) of each of them, there is one particular geopatch with its internal  
topology. Then, in general, each of them is surrounded by 8  neighboring 
geopatches.  These nine geopatches form  a  geopatch-cluster.  A geopatch at the 
North (rsp. South) pole shall be  part of a geopatch-cluster with  adjacent 
geopatches 1 to the East, 1 to  the West and 3 to the South (rsp. North). We 
may define (n,m) geopatch-clusters  with n rows of m (=column) geopatches. 
Any (1,1)-geopatch might be part of  some (3,3)-, (13,13)-,(37,37)-geopatch 
cluster and of course of the entire  globe. I.e. 5 hierarchical layers might 
do. (and yet these figures are arbitrary  and are for further study).
And of course, these hierarchies do overlap.  It takes a special kind  of 
advertisement protocol to ensure that each with TARA enhanced BGP-router gets 
 the proper (consistent )  set of strict/loose links. In this  way the 
Istanbul effect can be avoided and at the same time we can afford  that the 
protocol  prescribes relatively small scale ratios to be  applied when 
reduced/skimmed larger topologies are to be computed - as there are  only 10 000 
DFZ-routers altogether. Example: A geopatch'es (resp.  geopatch-cluster's) 
topology contains 100 nodes and 250 links. Assume scale  ratio = 1 : 5. Then the 
respectively skimmed network would  comprise precisely 20 nodes and 
approximately 50 links, which will be its  contribution to a (3,3) geopatch cluster. 
A proper advertisement protocol  must take care that this information is 
exchanged across the borders, enabling a  recursion of this process while 
being aware of the overlaps of geopatch  clusters.
Shortest patch computation will guarantee stretch-1 behavior  instead  of 
causing stretch-17 as Compact Routing experts emphasize in order to blame  
hierarchical concepts; well, their hierarchical concepts.
 
Heiner