headers
Michel Py | 1 Feb 01:17
Picon
Picon
Favicon

RE: Draft: PI addressing derived from AS numbers

Michael,

> Would it make sense to push Pekka's draft along the experimental
> track in the spirit of RFC 1797 (the 39/8 subnet experiment)?
> It may not be an optimal solution, but it would give the
> community some breathing room while better methods are developed.
>  I concur with Pekka that sunset provisions are important.

If a sunset is required, then requesting a "special" 6bone pTLA would be
the way to go. I don't see what that would buy though, and here's the
rationale:

The idea behind Pekka's draft is that deployment of IPv6 is being
hindered because organizations that currently have an ASN are waiting
for some kind of PI to deploy. Why are they waiting? Because they don't
want to renumber. Giving these guys a prefix that sunsets does not do
them any good.

Michel.
Permalink | Reply | 1 comment |
headers
Michel Py | 1 Feb 02:02
Picon
Picon
Favicon

RE: Draft: PI addressing derived from AS numbers

Tim / Pekka,

>>> Tim Chown wrote:
>>> And presumably these are a bigger hit on the DFZ routing
>>> table size than multihomers?

>> Michel Py wrote:
>> I don't think so, it more a matter of creating the precedent
>> then real savings on the routing table size.

> OK, I beleive you, but would be interested in any stats in this area? 

Sure, but keep reading.

> Pekka Savola wrote:
> I'd like to hear a specific definition of this, so we could _have_
> stats. Do you mean announcing a more specific route from different
> origin AS than the aggregate?  Do you you want to restrict that to
> address blocks allocated by RIR's somehow, etc.?
> I've actually done some analysis on a portion of the routing table
> to look for multihoming; extracting this info, if defined, might
> not be a problem.

I don't think that the real number actually matters. Is it 10k? 20k?
30k? nobody cares because in 3 or 4 years if we have 30k routes to deal
with it would not be a problem for any decent router.

The problem is that we would have opened the gates of hell by giving
away PI to a certain category of users and that everyone else and their
dog will want one too and the issue is dealing with a billion routes in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michel Py | 1 Feb 02:13
Picon
Picon
Favicon

RE: Draft: PI addressing derived from AS numbers

> Michael Richardson wrote:
> The AS proposal certainly results in a much smaller DFZ than if
> we handed every holder of PI IPv4 space PI space in IPv6. 

Absolutely, the point I was making is not that it would be bigger, as I
do like the idea, but that it would likely not be possible to stick to
it: If we give PI to ASN holders, you can be sure that the lobbying of
swamp space holders to get the same thing is going to be a freight train
that nobody will be able to stop.

> I would very much like to have given them some kind of
> PI IPv6 space.

I have been finicky lately about the semantics of this: Some kind of PI
other than the one we have could be fine, but certainly not straight PI.

Michel.
Permalink | Reply | 2 comments |
headers
Pekka Savola | 1 Feb 07:44
Picon

RE: Draft: PI addressing derived from AS numbers

On Fri, 31 Jan 2003, Michel Py wrote:
> > Would it make sense to push Pekka's draft along the experimental
> > track in the spirit of RFC 1797 (the 39/8 subnet experiment)?
> > It may not be an optimal solution, but it would give the
> > community some breathing room while better methods are developed.
> >  I concur with Pekka that sunset provisions are important.
> 
> If a sunset is required, then requesting a "special" 6bone pTLA would be
> the way to go. I don't see what that would buy though, and here's the
> rationale:

Tying this to 6bone is an interesting idea, but the death of 6bone may be
too soon..

> The idea behind Pekka's draft is that deployment of IPv6 is being
> hindered because organizations that currently have an ASN are waiting
> for some kind of PI to deploy. Why are they waiting? Because they don't
> want to renumber. Giving these guys a prefix that sunsets does not do
> them any good.

Note that there are other motivations for multihoming than wanting not to 
renumber.

Renumbering _once_, when the mechanism is retired in 5 years (or whatever)  
could be entirely acceptable.

But what they mainly want, as far as I can see is independence and
redundancy; load sharing, performance and policy are just likely secondary
objectives (partially because due to more speficic routes not allowed,
they may be more difficult to do anyway).
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Noel Chiappa | 1 Feb 18:51
Picon

RE: Draft: PI addressing derived from AS numbers

    > From: Pekka Savola <pekkas <at> netcore.fi>

    > But what they mainly want, as far as I can see is independence

If people wanted a namespace that was independent of topology, they should
have put one into the architecture when it was first designed.

Routing-names in a global-scale network will *always* depend on network
location.

The only namespace IPv6 has (other than DNS names) are addresses, which are
routing-names.

If an architecture without a namespace which is independent of topology in
unacceptable, then people have to either i) radically modify IPv6, or ii)
junk it.

Is a namespace with independence really absolutely required? If so, saying
tbat is equivalent to saying you have to either radically modify IPv6 (so
it supports that), or junk it (since it doesn't).

"We are a lighthouse. Your call."

	Noel
Permalink | Reply | 11 comments |
headers
J. Noel Chiappa | 1 Feb 20:39
Picon

RE: Draft: PI addressing derived from AS numbers

    > From: "J. Noel Chiappa" <jnc <at> ginger.lcs.mit.edu>

    > If an architecture without a namespace which is independent of topology
    > is unacceptable, then people have to either i) radically modify IPv6,
    > or ii) junk it. 

Ah, to make it quite plain what I meant here: by "IPv6" I meant the entire
stack, not just the internetwork level protocol; and by "radically modify
IPv6" I mean to include schemes like 8+8, 16+16, HIP, etc - a system using
one of these is not going to interoperate with one which does not have it
(although I dunno about 16+16).

	Noel
Permalink | Reply | 0 comments |
headers
Pekka Savola | 1 Feb 21:24
Picon

RE: Draft: PI addressing derived from AS numbers

On Sat, 1 Feb 2003, J. Noel Chiappa wrote:
>     > From: Pekka Savola <pekkas <at> netcore.fi>
> 
>     > But what they mainly want, as far as I can see is independence
> 
> If people wanted a namespace that was independent of topology, they should
> have put one into the architecture when it was first designed.
> 
> Routing-names in a global-scale network will *always* depend on network
> location.
> 
> The only namespace IPv6 has (other than DNS names) are addresses, which are
> routing-names.
> 
> If an architecture without a namespace which is independent of topology in
> unacceptable, then people have to either i) radically modify IPv6, or ii)
> junk it.
> 
> Is a namespace with independence really absolutely required? If so, saying
> tbat is equivalent to saying you have to either radically modify IPv6 (so
> it supports that), or junk it (since it doesn't).

In the long term, i'm rather convinced that an architectural change will 
be required.  I can't see other scalable alternatives.  

But it's not all-or-nothing.  Current common practises require
independence already -- at "largish ISP" level.  This is deemed
acceptable, in contrast to late aggregatable global unicast addressing
(RFC2374) with hard limits.  So, independence is OK to some degree.. but
we must not get that degree get too far unless we have measures to provide
(Continue reading)

Permalink | Reply | 10 comments |
headers
Randy Bush | 2 Feb 00:59

RE: Draft: PI addressing derived from AS numbers

> In the long term, i'm rather convinced that an architectural change will 
> be required.  I can't see other scalable alternatives.  

this is also what i see, though i am anxiously awaiting enlightenment.

randy
Permalink | Reply | 9 comments |
headers
Pekka Savola | 2 Feb 08:38
Picon

RE: Draft: PI addressing derived from AS numbers

On Sat, 1 Feb 2003, Randy Bush wrote:
> > In the long term, i'm rather convinced that an architectural change will 
> > be required.  I can't see other scalable alternatives.  
> 
> this is also what i see, though i am anxiously awaiting enlightenment.

Well, speaking of enlightenment, I've had a few ideas lately.  I'm pretty 
sure someone has thought along the same lines at some point, but here goes 
anyway.

The current multihoming practises seem to have an impact on the global
routing table on two different axels:

 1) the absolute number of routes
 2) the number of changes in the routing tables due to the large number of 
routes, required processing and update propagation etc.

For example, consider (in future) 10,000 routes coming behind a
next-to-the-origin-AS ISP.   If something bad happens to the ISP, all 
10,000 routes will be withdrawn, and a secondary path will be selected 
(perhaps 3,000 will go to ISP X, 3,000 will go to ISP Y, and 4,000 go 
nowhere, simplifying).

The absolute numbers _might_ be manageable if changes were manageable: I'm
fairly certain of that at least to the degree of O(10^6) -- memory is
cheap.

A way to make changes manageable could be to change how BGP works with
regard to nested routes from multiple sources.  Or really, devise another
protocol.  Here's a raw thought:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Iljitsch van Beijnum | 2 Feb 13:31
Favicon

RE: Draft: PI addressing derived from AS numbers

On Sun, 2 Feb 2003, Pekka Savola wrote:

> For example, consider (in future) 10,000 routes coming behind a
> next-to-the-origin-AS ISP.   If something bad happens to the ISP, all
> 10,000 routes will be withdrawn, and a secondary path will be selected
> (perhaps 3,000 will go to ISP X, 3,000 will go to ISP Y, and 4,000 go
> nowhere, simplifying).

> The absolute numbers _might_ be manageable if changes were manageable: I'm
> fairly certain of that at least to the degree of O(10^6) -- memory is
> cheap.

I assume you mean 10^6 number of routes? Cisco's CEF seems to take
something like 300 bytes for a single route. That makes for 300 MB
worth of fowarding tables, which wouldn't stress current technology too
much.

BGP and routing table entries also seem to be something like 300 bytes
each, so for the main route processor the amount of memory could be
somewhat more problematic. But 4 copies of each route in the BGP table +
1 in the routing table would make for 1500 MB, also still doable.

> A way to make changes manageable could be to change how BGP works with
> regard to nested routes from multiple sources.  Or really, devise another
> protocol.  Here's a raw thought:

> When BGP is used for multihoming, all the paths are advertised throughout,
> not only the current best paths.  There has to be a marking on which ones
> aren't the best paths of course.  When a transit AS becomes unreachable,
> instead of withdrawing the routes and waiting for updates, the only thing
(Continue reading)

Permalink | Reply | 0 comments |

Gmane