Sprint violations (setting space aside for slow-start allocations)

Nick -

   Good points. You also join the registries in making
one of the two very persuasive arguments in favour of
relaxing (perhaps some, perhaps all) of 206.0.0.0/8 by
one bit, to allow in /19s.

   Slow-start is a good idea, and we have the RIPE /19
legacy to prove it. Now we need to look at whether this
can be done with /18s without exhausting IPv4 too soon,
as there are some real concerns about doubling the maximum
number of prefixes many routers will see.

   I also see no problem about working out case-by-case
arrangements for putting holes into our filters in the
future, taking everybody's various costs into consideration.

If Sprint is not doing a good job of aggregating its announcements,
filter them, eventually they'll get around to aggregating everything
they can.

   There certainly is some aggregation that should be
done downstream from Sprint. We try to encourage people
to aggregate what they can aggregate, but some outside
pressure to do so probably would help...

  Sean.

P.S.:

So how about agreeing on pools of address space for small allocations?

I think you found a good topic!

Sean Doran <smd@icp.net> writes:

  > Slow-start is a good idea, and we have the RIPE /19
  > legacy to prove it.

It is not legacy. We are using it in 193/8 and 194/8 and currently we
do not intend to do differently in any new /8 we might start. /18 is
just too much of an allocation for a garage with a couple of <your
favourite modem hub>. We cannot and will not refuse to allocate address
space to such garages until someone comes up with a *resonable* policy
of what is an eligible garage. I can understand that some sugest that a
reasonable policy is to require connections to a at least two <major
transit provider>, but I postulate that <major transit provider> can
never be defined in a rasonable way.

So please define which garages shall be eligible for an allocation
and get the RIPE community to agree. Mind this is easier than the
Internet community.

Folks: Here is an issue!!!!

  > Now we need to look at whether this
  > can be done with /18s without exhausting IPv4 too soon,
  > as there are some real concerns about doubling the maximum
  > number of prefixes many routers will see.

My experience tells me that it is too big. We are not doing slow start
long enough however to quantify that.

  > > So how about agreeing on pools of address space for small allocations?
  > I think you found a good topic!

Check out ripe-127.

Daniel