[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Provider Independent addressing format drafts



I agree. I think this is *very bad* for aggregation, since it won't just
be the IBM's of this world who go for it. If every small company goes
for a PI /48, the BGP table is a lost cause. I don't believe this
is a good idea.

I think the correct solution is PA, with PA /35 (or thereabouts) prefixes 
being used by local neutral exchange points - and policy mechanisms
beyond the scope of the IETF to create those exchange points. I don't believe
there is anything more we can do in this area by writing standards.

   Brian

itojun@iijlab.net wrote:
> 
> >The updates to the provider independent address format & usage drafts
> >are available at:
> >http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-fmt-01.txt
> >http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-01.txt
> 
>         I still don't understand how PI address format can be routed in
>         currently-practiced routing infrastructure.  PI address, based on
>         physical location can behave very poorly against aggregation.
>         example:
>             I'm using 1fff:ffff:ffff::/48 and connected to ISP A, while
>             my neighbor is using 1fff:ffff:fffe::/48 and connected to ISP B.
>             ISP A and B needs to exchange /48 routes to route between us.
>         I believe we end up having 2^44 routes in the routing system with
>         the PI address allocation.  are there any magic I'm missing?
>         examples given in the drafts did not convince me at all.
> 
>         another comment - in the document, it is mentioned that the allocation
>         of a single /48 must be solved by "local jurisdiction".
>         I don't think it workable for highly populated area (think of NY, tokyo,
>         whatever), where skyscrapers make hundreds of companies to share the
>         same geographical location.  it may work for less populated area
>         (imagine any farms in middle-of-nowhere).
> 
> itojun