Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

[Martin Millnert <[e-mail]>]

On Fri, 2012-12-14 at 22:02 -0500, Michael H Lambert wrote:
> Well, if a new ashex type were to be introduced, 0xff000000 to
> 0xfffffffe would be rather clean for the proposed private range.

It's my understanding this horse has left the barn as well, so this is
not an option.

FWIW, I am OK with the large size of a new range of 2^24 private ASNs.
I'd also be OK with a smaller range which is more easily typed in or
otherwise humanly processed.

Chances are, if you need a private space of 2^24 scale, you can rather
easily just pick your own bits from the 2^32 space...

W.r.t predicting future scale of ASN ranges, the real "concern" is IMO
whether 2^32 is sufficient, or if we'll end up needing 128-bit ASNs
eventually...  but as long as we avoid trying to put more information in
an ASN than it is for, we should be fine.

 - at most, a scale of one private ASN per physical VM server, "ought to
be enough" for internet connected networks, w.r.t any scaling I can
imagine. 16M physical VMs? you can probably afford to design a better
solution to your overlay networking :>
  -  larger simulations or experiments need not be connected to the
internet anyway, or could easily afford some translating gateways to use
the full 32 bit space privately on the simulation side
 - burning through "public" ASN space by allocating large ranges of
public ASNs to each network by default (by RIR policy, or any
hierarchical story...) is wasteful and designs for rare exceptions
rather than the norm, which is simply wrong.  much more wise to have a
private range in this case.
 - operators are going to use the numbers, so readability is a really
wise thing.

all in all, I'm ok with the proposal, and with 2^24 even though I'm hard
pressed to see a use case for more than O(100000) private ASNs in
practice.
but the numbers really should be readable, so 420* is ok, as well. 

the numbers in the draft are a bad choice in this regard and should be
changed.

/M