Mailing List Archive

> Despite the weather forecast, I'm sure you'll warm to RIPE, its
> members and even its "bureaucracy", and perhaps revise your
> opinion in the light of an enjoyable experience.
>
> Looking forward to meeting you in Amsterdam.

Me too. See you all there...

--
Peter Galbavy peter@demon.net
@ Demon Internet phone://44/181/371_3700
http://www.wonderland.org/~peter/
snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/

> I think the hierarchical routeing is one step *worse* than the above.
> The address *defines* the route the packets take ? What about the real,
> live multi-interconnect, multi-homed Internet we use ? Maybe I have
> misunderstood the way IPv6 addressing works.

HR sure does sound real bad, just for grins what is your plan to keep
the routing table size within the constraints of the routers without it?

Scott

You're trying to achieve a perfect policy that will work for all time
when what we need is something to eke out IPv4 for the rest of its
natural life. By the time enough of your postulated ISPs have grown big
enough AND THEN shrunk enough for this to matter in any practical sense,
IPv4 will have become mostly static, and all of us here will have retired
from active Internet Politics. I hope.

On Jan 26, 12:59pm, Daniel Karrenberg wrote:
} Subject: Policy Statement on Address Space Allocations
}
} > Ronald Khoo <ronald@office.demon.net> writes:
}
} > Here's a suggestion for one simple rule. "Where delegating address space
} > to a provider registry, a) never delegate a block smaller than any
} > existing PA block already delegated, and b) once 3 such blocks are
} > delegated, always delegate a block at least 4 times bigger".
}
} While sounding fine in general, this assumes ever increasing growth
} of ISPs. An assumption easily proven invalid by counterexample.
}
} Daniel
}-- End of excerpt from Daniel Karrenberg



--
Ronald Khoo <ronald@demon.net> +44-181-371-1000 FAX +44-181-371-3750

| > We just have some differences of philosophy -- you think
| > that RIPE really can persuade people into having only
| > 1024 announements (preferably far fewer) in 195/8, and
| > I don't. That's all.
|
| OK. I call this a challenge but you won't let me try ;-).

You and Randy Bush seem to be reading each other's minds.

He has proposed this in a way that is very interesting,
and which I will think about.

There is a bad failure mode to consider that even a badge
afterwards won't make any more attractive.

Mostly it's "what on earth do we do if we cross the
threshold of 1024 prefixes in 195/8?" to which I see no easy
answer that doesn't involve inflict enormous pain on people
with old, established long prefixes in 195/8.

If you could help more there, then yes, you can think of it
as a big challenge. The rest of your message is a good
start, and has me thinking, as I've just told Randy in
private email.

The only other detail is that the consequences of making an
exception in one piece of unallocated-from address-space
because of the involvement of a single particular
organization may have some side-effects beyond engineering
that will have to be pondered by some other of my colleagues.

This is also something you could help think about, as we
will need an answer for "well, you gave *RIPE* a break, why
not us?".

Sean.

Daniel,

> If you insist on prefix-length filtering I have proposed a soloution
> for future address space allocated via the RIPE NCC several times:
>
> - set your inbound prefix length filter to /19.
>
> - The RIPE NCC will *guarantee* that we will not make more than
> 1024 non-aggregateable allocations from each /8.

Would the RIPE NCC provide such non-aggregatable allocations
irrespective of how many hosts would be covered by such an
allocation ?

Yakov.

>It's the other way round: SPRINT should tell his customers he can't
>guarantee 100% global Internet connectivity because he disagrees with
>the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC.
>They might want to look for a different transit provider...
>
>Regards,
>
>Miguel

say what you will about this policy, but someone (sean?) thought
long and hard about it's implications. i didn't like the abrupt
manner in which it was implemented, but it does take guts and it
is pretty elegant:

it's everyone else's 206 customers who can't
reach sprint's customers. even though it's the packets from sprint's
customer's that can't make it back to everyone else. that's the
beauty of it. sprint announces networks in the 206 space to us
and to everyone else. we accept the announcements if they are larger
than /24:

*> 206.12.94.0 192.41.177.241 128 80 0 1239 3602 ?
*> 206.12.187.0 192.41.177.241 128 80 0 1239 1794 ?
*> 206.13.159.0 192.41.177.241 128 80 0 1239 1791 3064 i
* 206.24.100.0/23 192.41.177.241 128 80 0 1239 1792 3563 i
*> 206.40.99.0 192.41.177.241 128 80 0 1239 3663 i
*> 206.40.100.0 192.41.177.241 128 80 0 1239 3663 i
*> 206.40.101.0 192.41.177.241 128 80 0 1239 3663 i
*> 206.40.102.0 192.41.177.241 128 80 0 1239 3663 i
*> 206.40.103.0 192.41.177.241 128 80 0 1239 3663 i
* 206.40.128.0/19 192.41.177.241 128 80 0 1239 4534 i

so if i'm a customer of sprint in a 206+ network that is announced as a
/24, i have a route to the world.

the real message is if you have a 206+ address, make sure that your
provider can put it into an aggregation block for you (or go to sprint).

nobody said it would be boring. :-)

Jeff Young
young@mci.net

> Ronald Khoo <ronald@office.demon.net> writes:
> You're trying to achieve a perfect policy that will work for all time
> when what we need is something to eke out IPv4 for the rest of its
> natural life.

I am not trying to achieve a perfect policy. I am an engineer both
by training and preference, not a policymaker.

What I am trying to do is to discuss proposals for policies which look
simple but break badly on already existing cases.

> By the time enough of your postulated ISPs have grown big
> enough AND THEN shrunk enough for this to matter in any practical sense,
> IPv4 will have become mostly static, and all of us here will have retired
> from active Internet Politics. I hope.

We are talking about real ISPs. If you check the address space usage
history of European local IRs, you will see that the growth in address
space usage of some has flattened a lot (I was not talking about
shrinking yet). Look in the area of national academic research
networks. Your simplistic scheme, if cast in stone, would do the very
wrong things for those.

Try again

Daniel

Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:

> If you insist on prefix-length filtering I have proposed a soloution
> for future address space allocated via the RIPE NCC several times:
>
> - set your inbound prefix length filter to /19.
>
> - The RIPE NCC will *guarantee* that we will not make more than
> 1024 non-aggregateable allocations from each /8.
>
> - The RIPE NCC will continue to work with the providers to
> maximise aggregation. Our goal is a maximum of 1024 routes
> per /8 visible at major exchange points. Incidentally this
> is the same goal that you seem to have.

You are not distinguishing (initial) allocation from announcement.

Your guarantee is worthless in the sense that it only gurantees that
the announcements (as opposed to allocations) can be aggregated if
each window allocation is tied to a single AS, and thus, for instance that
none of the allocation is for PI space, or for allocation to customers
who aren't local-IRs but have their own AS etc. etc. You also have the problem
that currently it is impossible for local-IRs to allocate blocks
of IP numbers that wouldn't be filtered out to multihomed customers
(with their own AS - thus almost inevitably requiring a separate
announcement) where that customer under the RIPE rules isn't 'justified'
in getting a /19 (too small, for instance). Conservation vs. aggregation
again. What is your recommendation on this?

Alex Bligh
Xara Networks

PS: Here's Sprint's sister company's current announcement of routes
*originating* in its AS as I see them - I do hope Sprint takes the honest
path if it does refuse to carry short announcements and not route all bar
4 of these nets, as well as a similar long list from AS1239 :-) I'm
not convinced Sprint has the moral highground here....

Network Next Hop Metric LocPrf Weight Path
*> 160.214.0.0 194.68.130.50 0 4000 ?
*> 163.164.0.0 194.68.130.50 0 4000 ?
*> 194.41.63.0 194.68.130.50 0 4000 ?
*> 194.106.0.0/19 194.68.130.50 0 4000 ?
*> 194.106.32.0 194.68.130.50 0 4000 ?
*> 194.106.33.0 194.68.130.50 0 4000 ?
*> 194.106.34.0 194.68.130.50 0 4000 ?
*> 194.126.64.0/19 194.68.130.50 0 4000 ?
*> 194.133.0.0/19 194.68.130.50 0 4000 i
*> 194.133.4.0/23 194.68.130.50 0 4000 ?
*> 194.133.6.0 194.68.130.50 0 4000 ?
*> 194.133.7.0 194.68.130.50 0 4000 ?
*> 194.133.8.0 194.68.130.50 0 4000 ?
*> 194.133.15.0 194.68.130.50 0 4000 ?
*> 194.133.24.0 194.68.130.50 0 4000 ?
*> 194.133.28.0 194.68.130.50 0 4000 ?
*> 194.140.128.0/19 194.68.130.50 0 4000 ?
*> 194.140.224.0/21 194.68.130.50 0 4000 ?
*> 194.149.192.0/18 194.68.130.50 0 4000 ?
*> 194.158.0.0/20 194.68.130.50 0 4000 ?
*> 194.176.96.0/19 194.68.130.50 0 4000 ?
*> 194.204.96.0/23 194.68.130.50 0 4000 ?
*> 196.27.0.0 194.68.130.50 0 4000 ?
*> 196.27.1.0 194.68.130.50 0 4000 ?
*> 198.169.26.0 194.68.130.50 0 4000 ?
*> 204.59.0.0/16 194.68.130.50 0 4000 i
*> 204.83.37.0 194.68.130.50 0 4000 ?
*> 204.83.237.0 194.68.130.50 0 4000 ?
*> 204.83.254.0 194.68.130.50 0 4000 ?
*> 206.49.64.0/18 194.68.130.50 0 4000 i
*> 206.49.65.0 194.68.130.50 0 4000 ?

Dennis said:
>>[192 et al] look like swamps that are ripe for the picking.

Bill said:
>Already underway as part of PIER

Yay. I'm looking forward to the updates. I'm even more
looking forward to technology that makes renumbering
tractable, because that will end this entire line of
discussion pretty much forever.

Sean.

| Now can we try to make things work rather than point fingers!

Yes, indeed; that is the ultimate goal we share.

We just have some differences of philosophy -- you think
that RIPE really can persuade people into having only
1024 announements (preferably far fewer) in 195/8, and
I don't. That's all.

The compromise we could find would involve a practicable
method by which we don't have to put a prefix-length-floor
in place, but at the same time don't have to spend enormous
amounts of (unavailable) CPU time filtering based on what's
in the RIPE database.

Avoiding large amounts of (largely unavailable) staff time
at Sprint and RIPE to chase down offenders and try to figure
out how to stop them from ignoring their contribution to
melting routers is also something I'd like to avoid.

I don't love my solution either, but it does have the
advantages of being CPU inexpensive, does a reasonable job
of guaranteeing an absolute maximum number of prefixes in
195/8 (the sum of the /18s, /17s, /16s ... /7s and the /8
itself) even in the worst case, and provides what has
already proven in practice to be a tractable enforcement
mechanism.

I regret the renumberings which have happened as a result,
but unfortunately people are still being hooked up to the
network with freshly-allocated PI /23s and /21s, and only
after they actually try to use them does it click that they
really won't work.

Moreover, when these people try to find out why things
aren't working, (and sometimes after trying various so-far
unsuccessful means to have an exception made), they often
understand what's happening in core routers and from then on
have tended to do a good job of not introducing new prefixes
into the core.

I am aware of various disclaimers and warnings the
registries issue and I'm grateful for them, actually.
They've been helpful. Some folks at a couple of our
peers/competitors have also been good at protecting their
customers by telling them a great deal about CIDR and PI vs
PA space.

The large failing of CIDRD and the CIDR effort is one of
being unable to communicate things to precisely these people
receiving new allocations, which in large part is due to the
inability to get any documents published.

So, as a consequence of some parties being religiously
opposed to issuing documents emanating from a part of the
IETF that describe what really is happening now -- in order
to save newcomers and folks who haven't followed CIDRD a
great deal of confusion and effort -- on the grounds that
any such publication would look like the IETF "endorsing"
some evil greedy bastards who are out to rape and screw
small providers, people in small countries, small animals,
or whatever the cause celebre of this type of zealot happens
to be today.

The people being screwed are those who have no information
about how busy routers are and how untenable lots of
addresses of any nature are, and how important aggregation
is, and therefore how good PA addresses are to them *until*
they run right smack into my filters.

The campaign of "keep them ignorant to force providers to
abandon this silly notion that currently available routers
are too busy to deal with as many unaggregated addresses as
people want to present to them" only succeeds in *hurting*
small providers and startup providers.

And those small providers are who pay my salary, and you
better believe that my colleagues and I are very keen on
keeping them in business and seeing their customer base and
income grow substantially, so that they end up buying more
and bigger circuits -- both Internet connections and raw
private lines and international private lines -- and keep
being able to pay for them for a very very very long time.

Sean.

Daniel,

> > Would the RIPE NCC provide such non-aggregatable allocations
> > irrespective of how many hosts would be covered by such an
> > allocation ?
>
> Sorry, lack of clarity because of failing neurons.
> What I meant to say was "1024 CIDRable allocations".
> Or simply "allocations".
>
> The point is that we will guarantee that our allocation policy will
> create no more than 1024 allocations per /8 and therefore not
> necessitate by itself more routes than that. Currently our allocation
> sizes are /19 - /16. If you think about it a little you will see that
> it is easy to achieve.
>
> And just in case: Yes the minimum allocation is /19 irrespective
> of the number of hosts covered. Note: allocation != assignment.

OK, so just to make it clear, if a customer would come to the RIPE NCC
and the customer has just 1 host you would still allocated him /19 block.
Correct ?

Yakov.

| PS: Here's Sprint's sister company's current announcement of routes
| *originating* in its AS as I see them - I do hope Sprint takes the honest
| path if it does refuse to carry short announcements and not route all bar
| 4 of these nets, as well as a similar long list from AS1239 :-) I'm
| not convinced Sprint has the moral highground here....

Moral high ground does not interest me. Working networks
interest me.

I have to carry the ^1239_ routes internally anyway to get my
customers able to talk to each other. I don't need to carry
your routes at all, unless one of my customers wants to talk
to you. It's a simple thing, elegantly described by Jeff Young
earlier today. It was also elegantly described by Yakov
Rekhter in his CIDRD presentation of the concepts of Push and Pull.

Ordinarily I would answer "filter away; we've been prepared
for this kind of filter being applied against us since day
#1 (although admittedly it's not going to be too pretty if
someone wants to talk to you and suddenly can't. been there,
done that)". As a mechanism for motivating our customers to
aggregate better than they could, an important provider doing a
similar sort of inbound filtering likely would be much more
widely effective than the occasional Seanogram to various
customers warning of doom and the possibilities of being
filtered, which sometimes seem to be completely ignored.

This filtering is analagous to how ANS is able to get people
to register their prefixes in the RADB or run into inbound
announcement filters that will stop you from talking with
AOL and other ANS customers.

As you note, AS 4000 is run by a different company, and you
shouldn't punish them just because I'm an arrogant asshole,
as I have no control over or involvement with their routing
strategies.

(I'm not even sure that I'm entirely popular over there. ;-) )

However, yes, they are not aggregating as well as they could
be, and are announcing more-specific-routes that are
completely subsumed by aggregates.

Some of those folks are here and should feel free to speak
for themselves. Hi guys! :)

Sean.

| Network Next Hop Metric LocPrf Weight Path
| *> 160.214.0.0 194.68.130.50 0 4000 ?
| *> 163.164.0.0 194.68.130.50 0 4000 ?
| *> 194.41.63.0 194.68.130.50 0 4000 ?
| *> 194.106.0.0/19 194.68.130.50 0 4000 ?
| *> 194.106.32.0 194.68.130.50 0 4000 ?
| *> 194.106.33.0 194.68.130.50 0 4000 ?
| *> 194.106.34.0 194.68.130.50 0 4000 ?
| *> 194.126.64.0/19 194.68.130.50 0 4000 ?
| *> 194.133.0.0/19 194.68.130.50 0 4000 i
| *> 194.133.4.0/23 194.68.130.50 0 4000 ?
| *> 194.133.6.0 194.68.130.50 0 4000 ?
| *> 194.133.7.0 194.68.130.50 0 4000 ?
| *> 194.133.8.0 194.68.130.50 0 4000 ?
| *> 194.133.15.0 194.68.130.50 0 4000 ?
| *> 194.133.24.0 194.68.130.50 0 4000 ?
| *> 194.133.28.0 194.68.130.50 0 4000 ?
| *> 194.140.128.0/19 194.68.130.50 0 4000 ?
| *> 194.140.224.0/21 194.68.130.50 0 4000 ?
| *> 194.149.192.0/18 194.68.130.50 0 4000 ?
| *> 194.158.0.0/20 194.68.130.50 0 4000 ?
| *> 194.176.96.0/19 194.68.130.50 0 4000 ?
| *> 194.204.96.0/23 194.68.130.50 0 4000 ?
| *> 196.27.0.0 194.68.130.50 0 4000 ?
| *> 196.27.1.0 194.68.130.50 0 4000 ?
| *> 198.169.26.0 194.68.130.50 0 4000 ?
| *> 204.59.0.0/16 194.68.130.50 0 4000 i
| *> 204.83.37.0 194.68.130.50 0 4000 ?
| *> 204.83.237.0 194.68.130.50 0 4000 ?
| *> 204.83.254.0 194.68.130.50 0 4000 ?
| *> 206.49.64.0/18 194.68.130.50 0 4000 i
| *> 206.49.65.0 194.68.130.50 0 4000 ?

> Peter Galbavy <peter@demon.net> writes:
> > Thanks for amitting at least that much ;-).
> > Would you care to share your thoughts on less flawed paradigms
> > that will work with current or near-future kit ({hard,firm,soft}ware for
> > the non-british)?
>
> I wish I knew. In this I am the worst type of couch potato. ....

So stop critising "paradigms" without proposing better ones or at least
research the rationales and history behind them.

> > Yes, CIDR works if addresses are allocated *somewhat* topologically.
>
> And in the case of (I am guessing) > 70% of RIPE NCC allocated addresses
> are not.

First you missed the emphasis on *somewhat*. Second you are guessing wrong.

From both of the above it seems that you only know of and are only concerned
with your own particular situation.

> This is no ones "fault", just the way the policy is. Therefore
> I say the policy is WRONG.

What is the better policy?

> > The continental component in address space allocation is pure policy and
> > has little to do with CIDR. The policy only seems unreasonable when
> > considering only the issue you raise.
>
> But it is the *primary* issue. What else is there that influences how
> addresses are allocated in a CIDR or hierarchical way ?

More local topology than continental one is *very* important.

> We have e-mail for admin - it is timezone orthoganal. The existance
> of the RIPE NCC should just be remote, local staff for the InterNIC.

Fine with me. Do RIEP and theother contributors agree?
We can re-organise starting next week.

> If the RIPE NCC applies a "local model" then it is not conforming
> to the policies of IANA and the IAB that you keep referring to.

The RIPE NCC applies local policies within the boundaries of the global
policies.

> > Personally I believe that even this issue is irrelevant for providers of
> > the size of Demon. It makes no difference where you get a /16 from.
>
> Except you will not, even with correct justifications, give us one for
> our dial up services.
>
> To wash some dirty laundry here ...

I could help you washing in detail but I do not think this is appropriate
in all these fora. For the record I will summarise:

Demon is statically assigning IP addresses to dialup customers on a
large scale. This results in adresses being used per customer and not
per dial-in port. Obviously then number of customers is less limited
than that of dial in ports. There is concern about the wastefulness of
this practise on a large scale and the non-linear effects it could have
on address space usage. Hence it is *global*, read IANA, policy to
strongly discourage this practise and not to allocate more addresses
than three months worth of usage. This is not just an NCC policy!

Indeed we have allocated you a /19 to start with in addition to the
address space you have been allocated for other purposes than dial up IP.
Of course you will receive further allocations within the range of the
above policy whenever you need them. Of course we will do our best to
make the further allocations aggregateable with previous ones.

Assignments of address space by local IRs to customers have to be
registered in the RIPE (whois) database. You have raised that your
commercial interest of keeping your customer list confidential should
outweigh this registration requirement in the case of individuals
because of the special characterisitcs of the (consumer) market you
operate in. We have recognised that the tradeoff between the benefit of
registration and the commercial interests of individual dialup providers
is indeed special and consequently have worked with you(!), IANA and the
other regional registries to establish a global policy for this special
case. This policy has to take into account the need for verification of
assignments since the registration requirement has been dropped and the
database is not available for verification.

We have worked with you in this matter, you have agreed to the result.
I think it is *very* inappropriate to publicly abuse those who have
worked with you and to throw polemics at compromises some of which you
have even suggested and all of which you have agreed to. I will leave
the polemics for what they are.

> I wish I had the time, but it appears that we will have to make the
> time to get more involed. sigh.

Yes, it is more appropriate than polemicising publicly.

> > What we do *not* do is consider *individual* interests of some over
> > the ones of others. If we would do that we would eliminate our
> > "raison d'etre".
>
> Why not. We are not a communist society are we ? Each individual member
> of RIPE have their own unique requirements in a commercial and
> academically challenging world. We have a USP (Unique Selling Point) of
> giving our paying customers there own IP address (OK - it is not
> unique, but close enough). We have built propretary technology that
> allows our users to use *any* of our dial in points and get the same
> service, with the same IP number etc etc, and as one of our primary USPs
> we cannot allow the RIPE NCC to try to change that.
> ...
> The RIPE NCC model probably would work if it took into account that
> fact that its members are (on the whole) commercial organisations
> that sell differing products and services and have different
> requirements of the NCC. This does not appear to be the case.

You have received sufficient address space for your present needs
and you have been assured that -unless there are policy changes- you
will receive enough for your future needs. The same policy is
applied to everyone.

--- Polemic mode on ----

I have the slight suspicion that for you the only good model is
one that does exactly what *you* want, everyone else be damned.

--- Polemic mode off ----

Daniel

> Yakov Rekhter <yakov@cisco.com> writes:
> > - The RIPE NCC will *guarantee* that we will not make more than
> > 1024 non-aggregateable allocations from each /8.
>
> Would the RIPE NCC provide such non-aggregatable allocations
> irrespective of how many hosts would be covered by such an
> allocation ?

Sorry, lack of clarity because of failing neurons.
What I meant to say was "1024 CIDRable allocations".
Or simply "allocations".

The point is that we will guarantee that our allocation policy will
create no more than 1024 allocations per /8 and therefore not
necessitate by itself more routes than that. Currently our allocation
sizes are /19 - /16. If you think about it a little you will see that
it is easy to achieve.

And just in case: Yes the minimum allocation is /19 irrespective
of the number of hosts covered. Note: allocation != assignment.

Daniel

Jeff Young wrote:

| say what you will about this policy, but someone (sean?) thought
| long and hard about it's implications. i didn't like the abrupt
| manner in which it was implemented, but it does take guts and it
| is pretty elegant:

Thanks, Jeff. Once again I shall repeat my apologies --
the original intent was to make sure the filters would break
things on day one, rather than retroactively apply to the
number of people whose route announcements had been leaked
in by mistake.

Despite the immediate retrospective thought that
it was a cute way to avoid accusations of collusion
among big providers, I did very much regret the work
you folks and others had to do when this got dropped
into place.

OTOH, well, there had been several months' warning about the
details...

But still, sorry that it wasn't as smooth as it could
have been if there hadn't been a flaw in the filtering
that crept in in about April, long before anyone was
even really thinking of allocating from 206.0.0.0/8.

However, as I think everyone remembers, after a short while,
in an effort to assist in getting aggregation of the
then-announced bits of 206.0.0.0/8 working OK and giving
people some time to get used to the filtering, I did relax
the filtering on 206.0.0.0/8 to permit /19s.

As you note, this was to the benefit of other peoples' customers.

| the real message is if you have a 206+ address, make sure that your
| provider can put it into an aggregation block for you (or go to sprint).

Right, and we have been warning our customer base for
some time that if they announce a 206+ address that is
not aggregatable into something reasonably big (like a /18),
they run the risk of losing connectivity to other providers
if they ever were to impose similar filters for business
or technical reasons.

Meanwhile, yes, it's a slight competitive advantage. :-)

(Frankly though, that was a at first side-effect of not
having the ability to do the outbound filtering immediately,
but it rapidly seemed like a smart thing to do to make other
people think about similar filtering.

An interesting thing to wonder about is how different the
early days of CIDR deployment would have been if rather
than aggregating at the source, people were to have set
up some sort of inbound filtering at places like MAE-EAST.)

| nobody said it would be boring. :-)

Yup.

Sean.

> We just have some differences of philosophy -- you think
> that RIPE really can persuade people into having only
> 1024 announements (preferably far fewer) in 195/8, and
> I don't. That's all.

> The compromise we could find would involve a practicable
> method by which we don't have to put a prefix-length-floor
> in place, but at the same time don't have to spend enormous
> amounts of (unavailable) CPU time filtering based on what's
> in the RIPE database.

So how is this for a compromise:

If there actually _are_ more announcements than 1024 in any particular /8
under the control of the RIPE NCC, you implement filtering in such a way
that it gets down below 1024 again.

In this scenario, as long as the NCC can persuade it's customers to
aggregate, there are no problems. And if problems arise, it is extremely
likely that they can be fixed by filtering /20 and longer. That way, only
the offenders suffer and not the people who aggregate as RIPE tells them
to do.

A weekly check to see if the number of announcements stays below 1024
would be quite adequate and not unduly machine or manpower intensive, in
my opinion.

Paul -

Thank you for your kind words.

Sprint's filtering policies have led directly to a more
survivable SprintLink and ICM, which is to the benefit of
Sprint's Internet customers.

The trade-off is the inability to reach people who have
just hooked up to other parts of the Internet for the first
time and who are using addresses that are in conflict with
what we feel our routers can support.

So far the two (yes, two) customer-originated complaints
involving reachability affected by our filtering have been
resolved by straightforward renumbering of the non-SprintLink
entity. There have, by comparison, been several hundred
rather angry messages from non-customers who hook up and find
that they can't use their freshly-acquired addresses to talk
to SprintLink/ICM, and who claim never to have been warned
that this was a virtual certainty.

Two troubles in several months are rather obviously
dwarfed by the thousands of customer-originated complaints
about routing problems after major exchange points or other
major routing transitions happen (we have observed major
peers having serious difficulties with their routing system
scaling recently), not to mention the most recent serious
connectivity problem which involved working very closely
with our vendor on getting new technology out the door
that will let us scale with increasing traffic and
hopefully better deal with the scaling of the increase of
globally-announced routing informaiton.

Customer feedback I have gotten about our CIDR and other
routing policies tends to be very positive. Indeed, a
number of our customers are active participants in CIDRD,
NANOG, EOF and other forums where these policies sometimes
are discussed at length, and none of them seem very shy
about putting forward their own points-of-view, all of which
is remembered and thought about frequently.

We are, after all, very keen as a corporation to develop
and maintain long-lasting relationships with our customers.

It is possible that a number of unhappy customers have
not made themselves heard, or that a number have simply
voted with their feet on this precise issue, however there
certainly has not been enough of the latter to justify any
sort of re-think on this particular policy.

Whenever I see "Sprint sucks" in newsgroups and
mailing-lists, it's almost always because of reliability
problems. One of our most serious backbone reliability
problems involves routing convergence times and long-term
stability, and this particular routing policy in combination
with BGP dampening and other tools and techniques we've
developed here, goes directly to the heart of those problems.

I am always interested in proposals that will help
provide a more robust and stable level of connectivity and
performance to our entire customer base, and if you have any
ideas that would make it reasonable to withdraw our
prefix-length filters and _improve_ our routing stability, I
would be very glad if you could detail them.

Sean.

Forrest,

> This method would have (at least) the following advantages (or
> disadvantages, from your particular viewpoint):
>
> 1) You could reasonably assure that the number of prefixes in an
> /8 would match what was allocated.
>
> 2) Because of 1, if you get the registries to set their
> allocation policies such that no more than 1024 (or the target number)
> blocks are allocated per /8, you can guarantee that the number of
> routes in an /8 is not too far out of wack with the target.
>
> 3) You can give those people moving providers a grace period to renumber,
> say 30 days. Essentially, the time given to clean up the routing
> tables. This would be a side effect of the "you have 30 days to fix
> the routing tables or else".
>
> 4) You eliminate the wasted space of addresses with prefixes longer than
> /18 being allocated.
>
> The only problem this leaves is how to decide who gets an /18...

That is a *very good question*. Different answers to this question
have *quite different* implications on the address space utilization.

Yakov.

(If this isn't appropriate for nanog, would someone drop me a note in
private? All other CC's deleted).

I'll poke my nose in here again....

If you convince the registries to allocate no longer prefix than an /18
or a mix of lengths up to say /19 or /20 (such that no more than 1000ish
are allocated) to ISP's or multihomed companies, and then require that
the announcement must match the allocated block, you can guarantee that
the routing table will not exceed the 1024 per /8.

Then, some of you will ask how to enforce this. Once every so often, you
dump the BGP routing tables from strategic routers. If you see any
non-matching prefixes, you send an email to the network coordinator for
the allocated block giving them a set amount of time to clean it up. Any
routes which are not cleaned up by the deadline are added to a filter
list which could be carried on routers.

This method would have (at least) the following advantages (or
disadvantages, from your particular viewpoint):

1) You could reasonably assure that the number of prefixes in an
/8 would match what was allocated.

2) Because of 1, if you get the registries to set their
allocation policies such that no more than 1024 (or the target number)
blocks are allocated per /8, you can guarantee that the number of
routes in an /8 is not too far out of wack with the target.

3) You can give those people moving providers a grace period to renumber,
say 30 days. Essentially, the time given to clean up the routing
tables. This would be a side effect of the "you have 30 days to fix
the routing tables or else".

4) You eliminate the wasted space of addresses with prefixes longer than
/18 being allocated.

The only problem this leaves is how to decide who gets an /18...

BTW, I'm willing to write (for free) the tool to compare the routing table
to a registry, assuming someone can provide me with a copy or a source
for the IP registry files, or a subset thereof.

-forrest

On Fri, 26 Jan 1996, Alex.Bligh wrote:

>
> Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:
>
> > If you insist on prefix-length filtering I have proposed a soloution
> > for future address space allocated via the RIPE NCC several times:
> >
> > - set your inbound prefix length filter to /19.
> >
> > - The RIPE NCC will *guarantee* that we will not make more than
> > 1024 non-aggregateable allocations from each /8.
> >
> > - The RIPE NCC will continue to work with the providers to
> > maximise aggregation. Our goal is a maximum of 1024 routes
> > per /8 visible at major exchange points. Incidentally this
> > is the same goal that you seem to have.
>
> You are not distinguishing (initial) allocation from announcement.
>
> Your guarantee is worthless in the sense that it only gurantees that
> the announcements (as opposed to allocations) can be aggregated if
> each window allocation is tied to a single AS, and thus, for instance that
> none of the allocation is for PI space, or for allocation to customers
> who aren't local-IRs but have their own AS etc. etc. You also have the problem
> that currently it is impossible for local-IRs to allocate blocks
> of IP numbers that wouldn't be filtered out to multihomed customers
> (with their own AS - thus almost inevitably requiring a separate
> announcement) where that customer under the RIPE rules isn't 'justified'
> in getting a /19 (too small, for instance). Conservation vs. aggregation
> again. What is your recommendation on this?
>
> Alex Bligh
> Xara Networks
>
> PS: Here's Sprint's sister company's current announcement of routes
> *originating* in its AS as I see them - I do hope Sprint takes the honest
> path if it does refuse to carry short announcements and not route all bar
> 4 of these nets, as well as a similar long list from AS1239 :-) I'm
> not convinced Sprint has the moral highground here....
>
> Network Next Hop Metric LocPrf Weight Path
> *> 160.214.0.0 194.68.130.50 0 4000 ?
> *> 163.164.0.0 194.68.130.50 0 4000 ?
> *> 194.41.63.0 194.68.130.50 0 4000 ?
> *> 194.106.0.0/19 194.68.130.50 0 4000 ?
> *> 194.106.32.0 194.68.130.50 0 4000 ?
> *> 194.106.33.0 194.68.130.50 0 4000 ?
> *> 194.106.34.0 194.68.130.50 0 4000 ?
> *> 194.126.64.0/19 194.68.130.50 0 4000 ?
> *> 194.133.0.0/19 194.68.130.50 0 4000 i
> *> 194.133.4.0/23 194.68.130.50 0 4000 ?
> *> 194.133.6.0 194.68.130.50 0 4000 ?
> *> 194.133.7.0 194.68.130.50 0 4000 ?
> *> 194.133.8.0 194.68.130.50 0 4000 ?
> *> 194.133.15.0 194.68.130.50 0 4000 ?
> *> 194.133.24.0 194.68.130.50 0 4000 ?
> *> 194.133.28.0 194.68.130.50 0 4000 ?
> *> 194.140.128.0/19 194.68.130.50 0 4000 ?
> *> 194.140.224.0/21 194.68.130.50 0 4000 ?
> *> 194.149.192.0/18 194.68.130.50 0 4000 ?
> *> 194.158.0.0/20 194.68.130.50 0 4000 ?
> *> 194.176.96.0/19 194.68.130.50 0 4000 ?
> *> 194.204.96.0/23 194.68.130.50 0 4000 ?
> *> 196.27.0.0 194.68.130.50 0 4000 ?
> *> 196.27.1.0 194.68.130.50 0 4000 ?
> *> 198.169.26.0 194.68.130.50 0 4000 ?
> *> 204.59.0.0/16 194.68.130.50 0 4000 i
> *> 204.83.37.0 194.68.130.50 0 4000 ?
> *> 204.83.237.0 194.68.130.50 0 4000 ?
> *> 204.83.254.0 194.68.130.50 0 4000 ?
> *> 206.49.64.0/18 194.68.130.50 0 4000 i
> *> 206.49.65.0 194.68.130.50 0 4000 ?
>
>

On Fri, 26 Jan 1996, Yakov Rekhter wrote:

> Forrest,
>
> > The only problem this leaves is how to decide who gets an /18...
>
> That is a *very good question*. Different answers to this question
> have *quite different* implications on the address space utilization.

My personal opinion is that you err on the side of giving someone an /18
that doesn't need one, However you DO need to be careful about assigning the
space. The general qualifications I would imagine are:

1) ISP's assigning (non-portable?) address space to non-dialup customers,
on a fairly regular basis.

2) Large-ish companies which of themselves would need the /18.

3) Anyone who is multi-homed on a "permanent" basis. (Probably
mostly covered by 1&2)

-forrest

I thought it's time for the InterNIC to join in on the fun :-)

The registries (although I shouldn't speak for all of them) would be
more than happy to allocate address space in whatever way the ISPs
agree is the "right way". The problem is, you can't agree on what's
the "right way" of doing it. Everyone has their own agenda and
most have a very limited view of what's best, meaning their view is
limited to their own requirements.

On the other hand, the registries must try and take into consideration
everyone's agenda and needs. This is not an easy task.

The InterNIC is very aware of the routing table problem. We do everything
humanly possible to educate everyone requesting address space about this.
We also refer everyone to their upstream provider in an effort to help
with this problem. The truth is, Sprintlinks filtering policy has helped
because in the past we could only threaten people with the possibility of
what might happen. Now we can point to facts rather than supposition.
People are listening and they are going to their ISP for address
space. We have dropped from about 800 /24s - /21 assignments per month to
about 30 /24s - /21s per month.

However, it isn't so easy to convince ISPs to contact upstream providers
for address space. Understandably, they all want portable address
space. They do not want to be tied to their upstream ISP. David
Conrad mentioned that the InterNIC receives about 20 templates per
week from startup ISPs, the number is now closer to 50. Most I
refer to their upstream but they are not happy about it.

True, the registries do work hard to help preserve the address space.
I don't know what the growth rate of new ISPs in other areas is, but in
North America it seems to be the newest fad. The InterNIC receives many
calls each day from people who have decided to become ISPs, the only
problem is that many don't know how to spell TCP/IP. Now if we were to issue
every ISP a first allocation of a /18 prefix or shorter - how long do you
think the address space will last. I know that the routing table problem
is a more pressing issue, however, I believe if we drastically change
the allocation policy and give a /17 to each ISP regardless of their
requirement that will quickly change.

Most of you honestly believe you need a huge amount of space for growth,
well what makes you any different from every other ISP on the planet.
If you didn't believe in yourself or your potential, you wouldn't
be in this business. However, realistically, we cannot give everyone
the amount of address space that he/she wants to start - that's why
we have slow-start, to help determine what an ISP actually needs.

And for the record, the InterNIC does make many allocations from
larger reserved blocks.

Now, I'm sure that every ISP reading this message cares very deeply
for the Internet (as does the InterNIC) and utilizes address space
efficiently, etc. But consider the hundreds of ISPs that don't.


Kim

> On Fri, 26 Jan 1996, Yakov Rekhter wrote:
>
> > Forrest,
> >
> > > The only problem this leaves is how to decide who gets an /18...
> >
> > That is a *very good question*. Different answers to this question
> > have *quite different* implications on the address space utilization.
>
> My personal opinion is that you err on the side of giving someone an /18
> that doesn't need one, However you DO need to be careful about assigning the
> space. The general qualifications I would imagine are:
>
> 1) ISP's assigning (non-portable?) address space to non-dialup customers,
> on a fairly regular basis.
>
> 2) Large-ish companies which of themselves would need the /18.
>
> 3) Anyone who is multi-homed on a "permanent" basis. (Probably
> mostly covered by 1&2)
>
> -forrest

How about trying to prevent the static assignment of addresses to
dial-in customers? This chews IP space like there was no tomorrow...

>If you convince the registries to allocate no longer prefix than an /18
>or a mix of lengths up to say /19 or /20 (such that no more than 1000ish
>are allocated) to ISP's or multihomed companies, and then require that
>the announcement must match the allocated block, you can guarantee that
>the routing table will not exceed the 1024 per /8.
>
>Then, some of you will ask how to enforce this. Once every so often, you
>dump the BGP routing tables from strategic routers. If you see any
>non-matching prefixes, you send an email to the network coordinator for
>the allocated block giving them a set amount of time to clean it up. Any
>routes which are not cleaned up by the deadline are added to a filter
>list which could be carried on routers.
>
>This method would have (at least) the following advantages (or
>disadvantages, from your particular viewpoint):
>
> 1) You could reasonably assure that the number of prefixes in an
> /8 would match what was allocated.
>
> 2) Because of 1, if you get the registries to set their
> allocation policies such that no more than 1024 (or the target number)
> blocks are allocated per /8, you can guarantee that the number of
> routes in an /8 is not too far out of wack with the target.
>
> 3) You can give those people moving providers a grace period to renumber,
> say 30 days. Essentially, the time given to clean up the routing
> tables. This would be a side effect of the "you have 30 days to fix
> the routing tables or else".
>
> 4) You eliminate the wasted space of addresses with prefixes longer than
> /18 being allocated.

An excellent, well thought out proposal. I like it.

Eric

--
Eric Kozowski Structured Network Systems, Inc.
kozowski@structured.net Better, Cheaper, Faster -- pick any two.
(503)656-3530 Voice "Providing High Quality, Reliable Internet Service"
(800)881-0962 Voice 56k to DS1