[rrg] Embedding geo info in PA addresses=>A compromise between geo-aggregatable and provider-aggregetable address//re: Aggregatable EIDs

[Xu Xiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表 Lixia
Zhang
> 发送时间: 2010年1月13日 2:39
> 收件人: [e-mail]
> 主题: Re: [rrg] Aggregatable EIDs
> 
> 
> 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.

I like this idea. Embedding GEO info in the PA (Provider-Aggregatable)
addresses will not conflict with the ISP economics. Besides, it can be used
to facilitate location-awareness based services, e.g., achieving traffic
(especially P2P traffic) localization by allowing hosts to obtain
information from the nearest ones of all available peers. This not only
improves the user experience, but also saves the providers' bandwidth
resource. Imagine the future Internet will be information centric, rather
than node centric, the location-awareness services will become much more
popular. The IPv6 address provides us a possibility of embedding GEO info in
it since it has enough bits.

In fact, the IPv6 PA address with GEO info embedded is used as locator in
the initial version of my RANGI proposal. For more details, please see the
following discuss thread:
http://www.ietf.org/mail-archive/web/rrg/current/msg05590.html

Best wishes,
Xiaohu

> 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
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg