Re: [rrg] Aggregatable EIDs

[[e-mail]]

Hi Tony
See comments inserted
Heiner
 
In einer eMail vom 29.12.2009 22:04:13 Westeuropäische Normalzeit schreibt  
[e-mail]:

Hi  Heiner,

> A TARA-router will have a TARA-map which consists of  TARA-links each of 
> which is confined by two TARA nodes. A TARA-link  is either strict or 
> loose. A loose TARA-link is the concatenation of  strict and/or other 
> loose TARA-links and/or GRE-tunnels across  non-TARA-aware classical 
> internet.


So, during this  tunneling phase, it seems like the database is O(N^2) in 
the number of  possible links.


No.  Take an OSPF-network with N  nodes and with n  EBGP-TARA-nodes (N>>n) 
being the interfaces to the outside internet. It  will contribute approx. 2n 
to 3n loose links which interconnect these n  EBGP-TARA-nodes(assuming that 
this ISP network doesn't want to disclose any  knowledge about its internal 
topological structure). And this is true in  general:   if there are n 
nodes, the computation of the  interconnecting links will determine about 2n to 
3n links.

> Each strict/loose TARA-link has a weight value which reflects the  number 
> of hops. 


Is this updated dynamically?
 
Yes, it should. However the above computation of the interconnecting  loose 
links also recognizes all those nodes which are closer to some particular  
TARA-link's end node A than to any other such one B-i..
If A dropped out, its surrounding nodes  may still "stick to A" for  some 
time: After all, the advertisement-flooding of A and its adjacent loose  
links into other geopatches is only to attract packets. However, when the  
packets have arrived at this geopatch, the  local TARA-router will have a  
precise map of all strict TARA-links

Admitted, if A were at the rim of the geopatch and dropped out, an  
immediate re-computation would be appropriate.
 
> Hereby some approximation-algorithm is required to determine 
>  the adequate weight value for the inter-domain-GRE-tunnel, somehow 
>  derived from the TARA-locators of its end nodes, or it may be well-known 
 
> from OSPF if the GRE-tunnel is intra-domain. Though normally the viewed  
> strict TARA-links are expected to be from the own geopatch, they may as  
> well, in single cases, cross have of the globe. The big deal is to  
> provide algorithms such that each TARA-router ( particularly a 
>  geopatch-border node) can compute the identical set of (mainly looser) 
>  TARA-links which form a skimmed representation of the geopatch’s 
>  topology and which has to be disseminated in a larger scope i.e. into 
>  the surrounding geopatches. This is not an easy task to do or to 
>  describe by few lines, especially when you envision maybe about 5 
>  recursive repetitions, and that each TARA-router within the same 
>  geopatch shall get the same complete TARA-map with the own geopatch in 
>  the center (no Istanbul effect !). Furthermore, not only remoteness but 
>  also the density of some “area” shall affect the scale ratio to be 
>  applied in order to select a subset of TARA-nodes (partially by 
>  computation) plus the computation of TARA-links which are to 
>  interconnect them. Different from former descriptions: If there is at 
>  least one TARA-router within some geopatch, then there should be at 
>  least one TARA-router thereof be communicated worldwide together with at 
 
> least one TARA-link to it.


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 ????:-( 
 

Again, if the TARA-router is not part of the interconnect and all local  
ISPs do not participate in the interconnect, then you would seem to have  
a connectivity issue.
 
Again, the horse must come before the carriage - or do I misunderstanding  
something?

> Tony wrote:
> 
> Please read Joel's posting  again.  At the very least, ANY large name
> space needs to be  managed, and that management needs to be hierarchical
> to scale.
>  
> 
> No: The geographical coordinates don’t have to be managed. We  may need a 
> very local negotiation protocol in case two TARA-routers are  inside the 
> same square-second. We may of course also add a  height-component (see 
> RFC1712) and/or extent the scheme to consider  fractions of square 
seconds.


Geographical coordinates are already a  natural hierarchy anyway.  They 
will still need to be  managed. 
 
But not the coordinates themselves.
 
 [Which geopatch am I in? 
Answer: By assigning a particular TARA-locator to/by the TARA-router  
itself.
Who manages the 
geopatch?]  More generally, everything in a  network needs _some_ 
management.  We have not yet discovered the  mechanisms for self-assembly 
of networks.
 
This is an understatement :-) For about 10 years BGP supports VPN-site  
discovery for forming a VPN-tunnel network and for the sake of private traffic. 
 Admitted, it sounds weird to build a VPN for the sake of PUBLIC 
traffic.But this  is what we have to do (applies to TARA, applies to LISP, applies to 
lvip,  applies to...)
In case of TARA, multiple, let's say N isolated TARA-parts may  exist:   
single isolated TARA-routers and/ or  clusters  of  strictly  interconnected 
TARA-routers. They need to be  interconnected by GRE-tunnels, and we have to 
find a way to do that by well  determined o(N) many GRE-tunnels
 
 
Heiner
 
 
 
 
 
The TARA-router must know its geographical coordinates (by GPS or by  
looking into some geographical road map). 
Small mistakes and little bit of cheating would not hurt. After all they  
are only to attract traffic from remote places and as soon as packets  
entered the destination geopatch, each TARA-router would see the precise  topology 
recognize thereof the right destination TARA-node (no matter  whether the 
details of the coordinates are 100% correct or not) and can lookup  the next 
hop.
The question is indeed, where should TARA-forwarding end ? 3 Table  lookups 
 inside the destination geopatch, only! This may make TARA  interesting 
even inside some OSPF network. But for sure, where ever a  TARA-router finds 
out that its own TARA-locator matches the one of the  destination, 
TARA-forwarding ends and traditional forwarding starts.