[ppml] 2005-1 or its logical successor

[cja@daydream.com]

Tony,

As much as I think that geographical addressing could be a good idea,
networks aren't routed geographically. The interconnections aren't there to
make aggregation per your RFC feasible. I believe that currently there is as
much geography taken into account as can be. The RIRs get blocks for their
regions. Some aggregation could be done at that level depending on how
things are connected together. I do not believe that assigning PI space per
your rfc will gain us anything that assigning PI blocks per region out of a
known PI block won't do. You refer in your note to aggregating the further
from the source. Unfortunately "distance" is assessed on how far
topologically in a provider network the traffic travels, not necessariliy on
how far it goes geographically.

---Cathy

On 10/29/05, Tony Hain <alh-ietf at tndh.net> wrote:
>
> For the purposes of discussion, one approach would be to define the PI
> space
> in a way that could be aggregated the further it went from the source. A
> sequential assignment scheme creates a swamp that is hard to manage over
> time. An approach like:
> http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-08.txt
> would allow for aggregation at distance, while still allowing those that
> want to have a route carried globally to enter into a direct business
> relationship with each carrier for that routing slot. This would seem to
> align the burden with the financial model.
>
> Even if you started with the assumption that there was no aggregation in
> the
> geo based PI approach, as it became popular in each region a business case
> for exchange based aggregation would emerge. I know that 'topology does
> not
> match geography', but this approach would act to constrain topology in a
> way
> that would force alignment of the finances with the exceptions.
>
> Tony
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20051030/5405fc43/attachment.htm>