Re: [Idr] new ID on expansion of private use ASN range

[Jon Mitchell <[e-mail]>]

On Tue, Jul 03, 2012 at 10:18:30PM -0400, Christopher Morrow wrote:
> On Tue, Jul 3, 2012 at 4:06 PM, David Farmer <[e-mail]> wrote:
> > So Chris, why does clothing store with 1.5k endsites want those ASNs
> > publicly registered. ?I tend toward why not, but they frequently seem to not
> > want them publicly registered.
> 
> I'd want them registered in case I happen to link my corp network with
> any partners, less pain in the rear when it comes to 'who's net is
> this anyway?' discussions.

[JM] Unless we assume that all Enterprise operators are unable to make
wise decisions, I agree they should choose to use a Public ASN to make
this connection, likely at their HQ or in a dedicated DMZ network, as
they are probably not bringing in partner connections directly at their
stores.  Often this ASN will advertise an aggregate network or very
small number of networks containing the servers that need access to the
data from this extranet partner and no data from the extranet partner
will go directly to the store terminals situations but I think it is
hard to justify the next conclusion that they should register the other
1500 ASNs needed for this networking scenario just because they should
register that one.  Of course this is only one example of a single use
case, and walking through every use case of private use ASNs does not
seem useful.


> 
> TODAY they choose the path of zero resistance, 'our vendor said use
> 65something... oh, 65535, done.' :(
> 
> I'm not sure it's in our best interest to continue to let people paint
> themselves into a corner needlessly. (if we can fairly easily avoid
> it)

[JM]  Many networks are succesfully using private use ASNs, I suspect
we'll never know how many (although I'd guess far more individual
private ASN instances are deployed thank Public) since we don't connect
to them all or have to deal with them.  In my mind the only thing that
would have painted anyone into a corner would have been if such a
private use range had never existed in the first place and they were
forced to register every ASN, as likely this would have lessoned BGP
adoption overall (since there are many use cases that will not meet the
RIR justification requirements), when otherwise it was the right
protocol for their needs.

I don't see how this draft, providing a larger private use range, changes
the situation given that there are no plans or even feasible way to make
the existing private use ASN space to go away.  Not increasing the space
will only result in further hacks being used (internally) by networks
that need more than 1000 ASNs, not suddenly create a desire or a
realistic path to getting public ASNs.  Even if we theoritically could
take away away all private use space this may not get the result you
want either, but may push operators who don't want to incur this burden
to utilize other parts of the vast ASN space that they don't think will
be allocated soon.  I'm not suggesting this is wise or proper behavior,
just pointing out it has been done in other resources such as IPv4
private use space when the size was not sufficient for the requirements.

I welcome approaches/proposals to encourage a lower threshold for when
to use a public ASN and lowering the administrative and justification
burdens to obtaining them, and would be happy to work with anyone who
wants to solve this problem.  However as Brian pointed out, this draft's
progress should not be tied to the success of that effort as they are
solving different problems.