Subject: Re: [rrg] Aggregatable EIDs

From: [email-masked]
Date: Tue, 29 Dec 2009 07:06:24 EST

In einer eMail vom 28.12.2009 19:18:33 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi  Heiner,

Tony wrote:How does routing work entering and within the  geo-patch?  
Traffic 
arriving into the geo-patch must be routed to one  of possibly many local 
ISPs from one of possibly many long-haul transit  ISPs.  For this to 
work, there must be some interconnect between local  and long-haul.  This 
implies that there must be an exchange point, and  that it needs to be 
geo-patch specific.

Tony, each TARA router should  have a (flat) TARA-map which consists of 
TARA-nodes and TARA-links. A TARA-node is a TARA-aware router  which  has 
its TARA-locator (these 5  octets), assigned by GPS if you want. Host-users 
shall have assigned an  IP-address+some TARA-locator of one (in case of 
multihoming severals) TARA-node.  A sending source needs to know not only the 
destination IP address but as well  the respective TARA-locator. Eventually, 
especially during the incremental  deployment phase, some early TARA-router 
has to be proxy i.e. has to look-up by  means of the dest.IP address the 
respective TARA-locator. 
A TARA-router shall stop advertising prefixes wrt its EIDs but should  
advertise prefix of length 0 
(like the LISP default mapper) so that a TARA-router nearest to the  source 
will attract the flow to the “unknown” dest. 
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. 
Each strict/loose TARA-link has a weight value which reflects the  number 
of hops. 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. 
The TARA-router computes a best next hop towards each of the viewed  
TARA-nodes of his map and stores this information such that it can be retrieved  
by either one (if in a different geopatch) or by three table lookups (if 
within  the same geopatch). 

> And my point is that EIDs shouldn't have to be aggregated at  all, 
> neither now nor ever in the future.

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. 
That is all. 

Heiner

---

From: Tony Li <[email-masked]>
Date: Tue, 29 Dec 2009 13:03:48 -0800

Hi Heiner,

> 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.

> of hops. 

Is this updated dynamically?

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

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.

> 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.  [Which geopatch am I in? 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.

Tony