Re: 3177-bis

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Hi Thomas,

On 2008-03-25 01:36, Thomas Narten wrote:
...
> 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.

Indeed, and I wouldn't call it "second order" pain. A large site's
internal subnet numbering plan has enormous inertia - it's built
into config files, documentation, and brains. I think any large site
would exhibit enormous resistance to having to compress its address
space rather than simply change the prefix bits.

> 
> 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.

Well, you can look at it the other way - possible advice to any site
designing a subnet numbering plan is to avoid very sparse numbering,
and seek a reasonably compact numbering plan, such that only the low
order bits of the subnet number vary. That would ease the pain of
a hypothetical increase in prefix length. But on the other hand,
this shouldn't become an artificial constraint on the subnet plan
either. For example I don't see why a large site with hundreds of
subnets would even bother considering a hypothetical future with
less space than a /48. This is after all an engineering tradeoff.

On 2008-03-25 01:38, Thomas Narten wrote:
...
> I think having 2 different end site prefix lengths (for a given end
> site) is (generally) needlessly complicated and should be
> discouraged. 

I would use stronger language. It would be horrible, if the longer
prefix forced the site to have two different subnet numbering plans
for the two prefixes. That would be an operational and admin
nightmare.

> That is why the bar for getting more address space needs
> to be reasonably low.

And why there should be a preference for all prefixes
of a multihomed site being the same length.

    Brian