[ppml] HD Ratio changes

[Charles Scott]

Michael:
  Brief response to your comments...  OK, not so brief.

On Tue, 10 Feb 2004 Michael.Dillon at radianz.com wrote:

> With respect, I did say then, and I say again,
> this is all detailed in the RFC for applying
> the HD Ratio to IPv6 and in Paul Wilson's
> discussion paper of last year. I admit that I
> made some mistakes and posted the wrong URL for
> one of those documents, but that has now been
> rectified.

  IPv6 provides opportunities that we can't necessarily afford with IPv4, 
which is perhaps why his paper relates to IPv6.

> Not everyone can afford the routing table overhead that
> this entails. In fact, evading the use of hierarchy
> makes this non-scalable and therefore non-usable for
> larger networks. Hierarchy is the primary tool that
> we have for making complex networks scalable. This is
> a basic principle of physics that we cannot discard and
> that we ignore at our peril. The larger your network becomes
> the more important hierarchy becomes and the more overhead
> is consumed because of hierarchy.

  I did not mean to imply that people should intentionally design totally
amorphous networks that have no rhyme or reason to the layout of IP
addresses. However, it's my understanding that the HD ratio approach
attempts to accommodate the added waste of having to set aside address
space for exclusive numerically hierarchical deployment. If you start with
a rational plan that accommodates the bulk of your network and achieves
good internal routing aggregation, and then permit the use of other
address space to be overlaid as necessary it would seem that the impact on
your internal routing tables would be limited but you would not suffer
from the issues that HD radio intend to address.
 
> We really cannot impose specific technical solutions 
> as a matter of policy when there is no overriding policy
> goal to justify it. In this case, the overriding policy 
> goal which justified the 80% utilization rate is gone.
> We no longer have a looming shortage of IPv4 addresses
> because our existing stock will last 20 years. We have
> a fully functional replacement for IPv4 which does not
> have the same addressing constraints. And the large population
> asian nations have shown that they will move towards the
> IPv6 solution rather than increasing pressure on the IPv4
> address space. Since the overriding policy goals have
> now shifted, it is time to rationalize the policy to
> fit. 

  It should hardly be an imposition at this time to ask network managers
to employ network routing such that it permits efficient deployment of IP
space. Certainly we would not consider a network that does not support
VLSM at this time as a valid excuse to deploy IP space in a wasteful 
manner. Since we're not talking about huge increases in router memory to 
accommodate another 10-20 percent address efficiency I don't think we're 
really talking about imposing much of a technical solution, particularly 
considering that it's the larger, likely better funded networks, that 
would most benefit from HD ratio anyway.
  If it is true that there is not now any concern for IPv4 address space
then perhaps we should just relax the 80% to say 60% and make it easier
for everyone.
 
> The process of allocation, reallocation, and assignment
> divides a large address block into a larger number of smaller
> blocks. While it might be easy to get to 80% utilization
> of 1 large block, as we divide into smaller blocks we
> lose the effect of the law of large numbers. This means
> that some of the small blocks will reach 80% before others
> and we must start shifting addresses around robbing peter
> to pay paul. If there are several levels to this hierarcy
> of dividing, sub-dividing and sub-sub-diving, then we reach
> a point at which the time period represented by 20% (100%-80%)
> of an address pool is very short. That means that we could 
> use up the 20% in a very short time because it is a fairly
> small amount. In order to maintain a reasonable time buffer
> we need to reserve more than 20% unused addresses from a
> /23 even though 20% might be sufficient from a /17. The 
> cumulative impact of all these buffers adds up to more than
> 20% overall when you add up all the /23s in a /17. That's
> the hierarchical overhead.

  I don't necessarily agree that your premise is appropriate for address
allocation as opposed to address utilization. Regardless, the larger
providers already receive larger chunks of address space and therefore
their 20% is bigger.
  Also keep in mind this policy needs to be applied to those who manage
address space for assignment to end users, not to end user space. End user
space currently has considerably more relaxed standards of efficient
utilization (50%). This is why I've said in the past that ISP's who both
utilize as well as assign space should take the logical step of assigning
the space they will internally utilize to themselves and show that as
consumed from the total they have available for assignment.

> This approach does not unnecessarily increase 
> complexity because it is opt-in. If an organization is
> satisfied with the status quo they can continue as before.
> However, those organizations who need change can opt for
> the slightly more complex calculation if the benefits outweigh
> the added complexity.
> 
> As for waste, I do not consider hierarchical overhead 
> to be waste. This overhead is part of the structure of
> VLSM (Variable Length Subnet Masking) which is a fundamental
> part of any modern IPv4 network. If you have a subnet with 5
> interfaces on it and you assign 8 addresses to that subnet
> then you are *NOT* wasting 3 addresses. Those 3 addresses
> are part of the inevitable overhead of VLSM (and CIDR).

  Yes, but VLSM in itself does not relate to the efficiency of each
subnet. VLSM simply means that each subnet can be sized according to the
needs associated with it. Also, the subnets only need to comply with the
25%/50% utilization guidelines, so you could really make a subnet that has
5 active interfaces a /28 if you expect that you will be adding hosts to
it in the future. You do know that the total sum of host interfaces on all
networks of an assignment do not need to equal 80% of that assignment,
right?


Chuck Scott