[OCCAID] Proper zone for 2001:4830:2010::/45

[James]

On Sat, Jan 08, 2005 at 09:07:40PM -0500, Neil wrote:

[ snip ]

> 
> 
> this is an operational problem JTC members should work together to fix. they
> came up with idea to allocate /48's out of /45 reserved bits so if a member
> can justify additional /48, his subnet can be just enlarged for aggregation.
> 
> but that is broken numbering plan because it does not make the reverse dns easy
> since now you have to do seven /48 zone definitions instead of a /44 single
> definition in named.conf.
> 
> the /32 block provides far enough space for us to allocate /48s with /44 reserve
> bits instead of /45 and still have tons left over that we won't even be able to
> saturate. lets be realistic than extremely conservative! i am not advocating we
> should waste ip addresses. note the word RESERVE BITS, not allocation bits.
> we are still abiding to NRO numbering resource manual by allocating /48 and
> requriing justification before handing out more.
> 
> i urge james etc to review the numbering plan again and increase the reserve
> bits to /44 before handing out more prefixes out of the new block.

I think you are right. Our numbering plan is indeed somewhat broken. It's good
you brought this up earlier before the snowball turns to a disaster as we start
making allocations to requests coming into renumber at cnacs.occaid.org.

We have reserved total of seven /35's for active member/downstream allocations.
Each downstream typically receives a /48 allocation, however a /45 boundary was
to be left RESERVED, if in that future that member can sufficiently justify
additional allocations.

However the /45 boundary appears to provide dangerous operational issue and
threat to the scalability of reverse DNS delegation management. While the /45
boundary was made to ease routing aggregation, what gives when DNS becomes
stressed in return.

Doing the math, reserving /44 bits per member gives us 512 /44 blocks per /35.
512 * 5 /35 blocks = 3584 possible reservations.

3584 reservations is far from our total membership base today, therefore it
makes more sense to make both DNS and routing requirements easier to set the
reserve bits to /44 instead of /45.

In addition, as we move toward EINTAP framework, each EINTAP will be given
larger than /48 blocks as they will have their own downstream customers. So
it makes sense to increase the reservation boundary to something more
realistic than a very conservative plan.

Finally we are still not wasting IP addresses as we are only handing out
a /48 to a downstream site or downstream EINTAP as required by the NRO
policies. We will be able to enlarge their space up to /44 per justification
by the downstream. Bigger than /44 will require additional routing entry in
the OCCAID routing table.

So, I am making the change to our new numbering plan to reserve up to /44
bits per each downstream EINTAP allocation. Each downstream will be given
a /48 to start with. Sufficient justification meeting HD ratio of 0.8 or
greator by the downstream will allow us to enlarge his space as justified.

Let me know if there are objections to this change.

-J

> 
> 	-ndf 
> _______________________________________________
> OCCAID Mailing List: http://www.occaid.org
> schednetisr(NETISR_COFFEE); inq=&coffeebreak_intrq;
> 
> Occaid at cnacs.occaid.org is the list posting address.
> db-admin at cnacs.occaid.org is the human contact address.
> See below URL for subscribe/unsubscribe and list options:
> http://mailman.twdx.net/mailman/listinfo/occaid

-- 
James Jun                                            TowardEX Technologies, Inc.
Technical Lead                      Boston IPv4/IPv6 Web Hosting, Colocation and
james at towardex.com            Network design/consulting & configuration services
cell: 1(978)-394-2867           web: http://www.towardex.com , noc: www.twdx.net