Comments on draft-ietf-cidrd-ownership-01.txt

Last week I sent detailed comments on the "Ownership" I-D to the cidrd
    mailing list.

Your document has many problems. Here are a few:

    The document goes on to describe the nature and benefits of hierarchical
    addressing. It then, incorrectly, asserts that the Internet topology
    reflects a hierarchy and that addresses must be kept aligned with the

Well, in fact it says that "the topology of the network is not strictly
hierarchical". I suppose you could read that as saying that the network
topology is basically hierarchical, but it turns out this is a moot point.

You appear to have missed the distinction between a hierarchical topology, and
an address hierarchy. One can apply hierarchical addressing to a perfectly
regular topology, e.g. a North-East-West-South mesh in which each node has
precisely four neighbours. (True, one doesn't need full-blown dynamic routing
for that case, but it's a useful test case.) This disproves your implicit
suggestion that one cannot use hierarchical routing in a network which does
not have a hierarchical topology.

    This requirement is used to assert the need for enforcing addressing
    changes when (some) topological changes take place.

The point remains that use of hierarchical addressing is the *only* way known
to control the growth of routing overhead costs in a very large network, and
that an addressing hierarchy that is loosely isomorphic to the conectivity
topology is the *only* one that will do that. As such, if it of course true
that as the topology changes, the addressing hierarchy will have to, as well.

    The document makes no effort to deal with the very real difficulties this
    model creates for multi-homed organizations

Multi-homing provides extra capability, but it does not come without a cost
(in terms of routing overhead), and this is true no matter which addressing
scheme is used. Since this topic is lengthy and complex, I will pass on.

    The document asserts the model of customer "leasing" of addressing rather
    than "owning" them but does not discuss the problems this creates with
    large-scale requirements for renumbering, generally viewed as difficult,
    but potentially quite insidious for local providers who change transit

Renumbering is indeed painful. However, given past decisions, no other option
is now available to us if we wish the keep the Internet i) growing, and ii)

    In the next paragraph the paper states the importance of having an address
    reflect the topology of the network. Since the Internet is not a simple
    tree, but instead is a messy mesh one must ask by what procrustean process
    the Internet is to be represented by (relatively) stable hierarchical

Exactly. There is no way to represent a dynamic topology like the Internet
with stable hierachical addresses.

    The paper also says that changing an address is required as the network
    topology changes. This simply isn't true ... Internet topology changes all
    the time and sites are not required to change their addresses. At best this
    paragraph is seriously imprecise. At worst it is seriously wrong.

This is a subtle and complex technical point, one that is not possible to
quantify, and certainly not in a paper intended for a non-technical audience.
A given address hierarchy, for a given topology, will produce a certain degree
of routing overhead (as well as non-optimal routes). If the topology is then
changed, wihtout changing the addressing, the routing overhead will grow.
Eventually, it will grow to the degree that changes to the address hierarchy
are needed to bring routing overhead back to reasonable bounds. The problem is
exactly that no single change is deadly, but rather it is the accumulation of
many small changes that cannot be supported.

    The end effect is to aid in the myth of Internet topological hierarchy.

There is no myth of toplogical hierarchy that I know of, except in this paper.

    The first paragraph cites concerns for routing system scaling. However
    there is no concern expressed for Internet local providers or users.

Presumably, an Internet which no longer worked because of routing system
scaling problems would be a severe concern for Internet local providers
or users.

    It is time to consider alternatives to CIDR.

Unfortunately, it's too late to consider alternatives. The Internet has a real
problem with routing table growth. To get something organized (since the
solution to this problem cannot be imposed piecemeal, but has to be applied
throughout the core), implemented, and deployed, will take at least a year, I
would guess, and probably a fair amount longer. (It took almost 3 years to get
CIDR, a relatively simple solution, deployed, BTW.) We don't have that time.

    CIDR was chosen with the expectation that it would be a sufficient
    near-term answer for routing table compression.

CIDR was intended to handle "[growth] of routing tables in Internet routers
beyond the ability of current software, hardware, and people to effectively
manage". It indicated that "[the] proposed solution is to topologically
allocate future IP address assignment". That is what we are doing now.

    After some considerable initial success it is proving inadequate.

No, it's perfectly adequate, just painful. However, no other tool is available
to handle growth in the network.

The Internet, to use my favourite analogy, is in the position of some who has
jumped off a 50-story building, and about the 10th story decides it's going to
hurt. Bit late now, guys...