Re: 3177-bis

[Thomas Narten <narten@us.ibm.com>]

Fred Baker <fred@cisco.com> writes:

> The matter of reducing ones prefix length is, imho, either a red  
> herring or poor statement of a normal silver one. If I used to have  
> a /13 and deployed two subnets, and now am renumbered to a /63, what  
> in terms of my present requirements have I lost? I needed two  
> subnets, I used two subnets, and I have two subnets.

I agree. There are two parts of renumbering that are
painful. Renumbering at all is painful, meaning that there is pain if
*any* of the bits have to change. But that is a cost that is paid no
matter how many or how few bits actually change.

A second order pain is if you have to decrease the number of available
subnet bits when renumbering. If you previously had 5 bits of subnet
space, and have to compress that to (say) 3 or 4, there could be
additional pain if you have to change your subnet numbering plan. This
may still be relatively painless. For example, if you actually only
have 2 subnets and you are renumbering from a /48 to a /60, that might
be a slightly painful, but not terribly difficult either. On the other
hand, renumbering from a /48 to a /56 when you have 200 (or 300!)
subnets would be a very different story.

That is  why the document says:

     - assigning a longer prefix to an end site, compared with the
        existing prefixes the end site already has assigned to it, is
        likely to increase operational costs and complexity for the end
        site, with insufficient benefit to anyone.

But now that I have written the above, it seems to me that I could add
a bit more text to give some examples where renumbering to a smaller
subnet size really isn't a big deal vs. where it is.

Thomas