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 protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, January 12, 2010 2:25 PM
To: [email protected]; [email protected]
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 protected]:
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/deering.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 protected]
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
