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

[Jon Mitchell <[e-mail]>]

[JM] inline...

On Mon, Jul 02, 2012 at 10:12:38PM -0400, Jeffrey Haas wrote:
> Jon,
> 
> On Mon, Jul 02, 2012 at 09:55:21PM -0400, Jon Mitchell wrote:
> > > I suggest that we leave 65535 alone as a reserved AS.
> > 
> > [JM] I think it should be clarified either way, and I think adding it to
> > the private use ASN range with this draft is the better approach for the
> > following reason.  I consider this an after-the-fact registration (RFC
> > 5226 section 6.3) since this ASN seems to have widespread (mis-)use as
> > many implementations strip it using their remove private ASN knobs and
> > various networks undoubtedly have it deployed since it seems more than
> > since a large amount of Internet documentation including RFC 1930 seem
> > to include it as a private Use ASN.  Also, if this document progress,
> > implementors will need to update their knobs and documentation anyway,
> > so they, IETF and IANA can all be on the same page, allowing this ASN to
> > be stripped if there are vendors that don't do it today (note even some
> > vendors with published documentation stating that private ASN range is
> > 64512-65534 strip 65535 with their remove private knobs).
> 
> A strong part of my recommendation has to do with the fact that this AS has
> assumed a level of "magic" in some implementations.  In the case of much
> older implementations on antique hardware may, in fact, be a magic internal
> value as it is UINT16_MAX.  As a WG, we can deal with such things two ways:
> 
> 1. Good grief, your code is that old and broken? Replace it/the hardware.
> Let's use it!
> 2. We don't really need that one extra AS lying around.  Assume it may
> potentially be toxic and try to pay no attention to the man behind the
> curtains.
> 
> I will agree with anyone that the above opinion is one of strong cynicism.
> :-)

[JM] This is interesting, however given these ASNs are in use today and
there is widespread mis-understanding that the 65535 ASN is a private
use ASN already based on widespread vendor and other networking
documentation, I think publishing this informational draft to
officially allocate it as such is not going to cause a rush of changes
to use it on devices this old.  However new implementors would have
clear guidance on what a private ASN if they are trying to comply with
this draft/RFC if/when it's published and therefore could avoid this
leaving this open to error in new implementations.

> > Can I suggest your alternative proposal for
> > folks to comment on then is 4293918720 - 4294967295 (maintaining ~1M) or
> > are you suggesting a different range location or sizing?
> 
> If you want ~1M, pick 2^20 addresses.  You could probably even just do 2^16
> and have most providers happy.  (2^16 was the number I had in mind for my
> draft.)  This lets you align the private AS number at a convenient as.dot
> boundary.  I could even forsee someone's CLI saying PRIVATE.<num> :-)

[JM]  Although 65K private ASNs meet our near term needs, BGP is being
used further and further down in the DC, with proposals that push it
even to the host/hyper-visor.  Therefore, given the large amount of
space available, I think it makes sense to not limit this so artifically
and be frustrating operators again 5-10 years from now as more and more
creative network designs are proposed.  As for any implementation hoping
to make more asdot friendly implementations and encourage it's use, I
think this sounds like a good reason not to make the range 16 bits!