Subject: Re: [rrg] Aggregatable EIDs

From: Tony Li <[email-masked]>
Date: Thu, 31 Dec 2009 08:35:09 -0800

Hi Heiner,

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

But that implies that your external routing will be massively suboptimal 
with respect to other proposals where you can tunnel directly to the ETR.

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

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

One of us certainly does.  ;-)  There must be some local interconnect. 
This is where the economic issues come into play.

Tony

---

From: [email-masked]
Date: Thu, 7 Jan 2010 05:26:48 EST

In einer eMail vom 07.01.2010 08:49:46 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi  Heiner,

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

What is the internal topology  of the geopatch?

It is the viewed topology inside a geopatch, acquired by BGP-enhancements,  
consisting of TARA-links i.e. strict links/GRE-tunnels/loose links between  
2 TARA-nodes, whereby the loose links may be built of strict/(less)  
loose/GRE-tunnel links.
 
Heiner

---

From: [email-masked] (Noel Chiappa)
Date: Tue, 12 Jan 2010 16:33:03 -0500 (EST)

> From: Lixia Zhang <[email-masked]>

    > This proposal was considered and debated at the time, but did not
    > fly ... mainly due to the reason that has been articulated in this
    > thread of exchanges: the model does not match the ISP economics.

To expand on this a tiny bit, let me give it to you as Yakov concisely put
it to me:

In routing (i.e. path selection), for the overhead of routing to scale
'reasonably' in large networks, either the 'addressing' (i.e. the names used
by path selection) has to follow the topology, or the topology has to follow
the addressing; i.e. there has to be a certain level of congruence between the
two.

(And by 'topology' I mean actual network connectivity - we're mis-using
the term 'topology', but it's probably too late to fix that now, although
if someone has a better alternative term, I will cheerfully switch to
using it... :-)

Unfortunately for geo-addressing, for economic reasons, topology usually
follows traffic patterns (i.e. you lay/light-up fiber to match traffic flows),
and traffic patterns follow relationships in the real world (e.g.  between
customers and their suppliers/providers). So driving the topology from the
addressing end is not possible.

Instead, the only way that works is relationships -> traffic patterns ->
topology -> addressing.

	Noel

---

From: [email-masked]
Date: Tue, 12 Jan 2010 18:08:03 EST

Darrel,
your question is about "partitioning" and is very important. Although that  
should be interconnectivity inside a geopatch should be the normal case,  
it may happen that there are multiple parts which are not  interconnected by 
intra-geopatch links.
The concept must provide 2 things: 1) The capability to recognize that  
there are partitions, 2) extensions to the concept which handle them. a) by  
making sure to get to the right part (if possible). b) by enabling  detours
from inside via neighboring geopatches to the other inside part. Note,  
there could be a strict link from the other half of the globe into one of  
several partitions of some geopatch.
 
Though it is important, it is yet just one detail. There is more: The  
commonly acquired maps which consisted of differently zoomed/skimmed  parts of 
the surrounding internet might be enhanced by some set of intra-domain  
TARA-links (e.g. of a global operating ISP !).
 
We all shouldn't mind facing new challenges. 
 
Heiner
PS: Good luck to LISP. But isn't one jack-up solution enough to be pursued  
?

 
In einer eMail vom 12.01.2010 23:40:34 Westeuropäische Normalzeit schreibt  
[email-masked]:

Are routers inside a  given geo-patch required to interconnect?  That is, 
will a packet which  is delivered to any given router inside a geopatch be 
guaranteed to be  delivered to some other router in the same geopatch?
 
I believed Tony asked  this question a few times, I've yet to see a clear 
answer.
 
-Darrel

____________________________________
 From: [email-masked]  [mailto:[email-masked]] On Behalf Of  
[email-masked]
Sent: Tuesday, January 12, 2010 2:25  PM
To: [email-masked]; [email-masked]
Subject: Re:  [rrg] Aggregatable EIDs

Lixia,
Once more: My geolocation-based TARA concept is FUNDAMENTALLY  different 
from all three proposals you are mentioning (Steve Deering's  Metro-based..., 
Hain-draft, Giro). If I had no better computational  tools at hand than 
Deering, Hain or the UCLA group, I  would either be absolutely  silent          
- or in the  ILNP camp:-)
 
Lixia, I know, you have a lot of ideas, how to make prefix-handling  more 
sophisticated.
My point however  is: Get rid of any (Unicast) prefix building.  TARA is 
about providing a well-skimmed topological view of the internet  (which 
prevents table size problems as well as update churn). As opposed to  all 
submitted proposals, TARA is the only one which can provide a perfect  
visualization: Use Google to search for a route from NY, Time Square, to  S.F, Lambert 
Street - and play with the different zooms !!!
 
Heiner

In einer eMail vom 12.01.2010 19:39:25 Westeuropäische Normalzeit  schreibt 
[email-masked]:

On Dec 27, 2009, at 7:43  PM, Brian E Carpenter wrote:

> Hi,
>
> On 2009-12-28  14:17, Xu Xiaohu wrote:
> ...
>>> This argument fails  for exactly the same reason that geographically
>>> based BGP  aggregation fails.
>>
>> Brian, who has ever done it  ?
>
> Nobody, as far as I know.
>
>> Why do you  say this and what do you mean by saying this ?
>
> There have  been a lot of geo-based or metro-based proposals over
> the years.  Most recently, draft-hain-ipv6-geo-addr.
> As far as I know, none of  them has ever been deployed, because
> this isn't how Internet  economics works. There is no financial
> incentive to deploy  geographically based exchange points which also
> act as address  delegators to customers. (Note, there is no technical
> argument  against it. But nobody knows how to make money out of it.)

the  above comment seems alluding to the long historical debate in geo-  
based addressing, that the young folks here may not be totally  aware  
(I wish I were one of you people:).  So here are a  few pointers to  
related material.

The concept was a  rather old one, Greg Finn had some related proposal  
back in  early 80s (I didn't bother to hunt down the URL but I believe  
a  long tech report is still on the web).

In the early days of IPv6  design, Steve Deering gave a strong pushing  
in this  direction.  The best ref is probably his plenary talk at July   
1995 IETF meeting:
"Metro-Based  Addressing",
ftp://ftp.ietf.org/ietf-online-proceedings/95jul/presentations/allocation/de
ering.slides.ps

This  proposal was considered and debated at the time, but did not fly   
(though effort in that direction continued on, e.g. the draft-hain-  
ipv6-geo-addr mentioned above), mainly due to the reason that has  been  
articulated in this thread of exchanges: the model does not  match the  
ISP economics.

However as it happens to any  debate, opinions often swing further than  
proper. From time to  time one hears the interpretation from that  
debate as "geo info  cannot be used in routing" which is not the case.
What that debate  taught us (at least me) is that, for routing  
decisions, ISP info  must take the high order bit.
However after that high order bit is  taken into account, geo info can  
be very useful to further  optimize the routing decisions.
as a simple evaluation, we used the BGP  data from Rotueviews and RIPE  
for a measurement study, the  result is reported in a paper a few years   
back:
"Geographically Informed Inter-Domain  Routing"
http://www.cs.ucla.edu/~rveloso/papers/giro.pdf
or if you  just want a quick look of the idea, here is the presentation   
slides:
http://www.cs.ucla.edu/~rveloso/papers/07ICNP_giro.ppt

Lixia

_______________________________________________
rrg  mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg