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

[Jon Mitchell <[e-mail]>]

Comments [JM] Inline...

On Mon, Jul 02, 2012 at 07:03:57PM +0200, Robert Raszuk wrote:
> Hi Jon,
> 
> I have read your draft few days back and support adopting it as an
> IDR WG doc.
> 

[JM] Thanks.

> However I have one question/suggestion ...
> 
> Perhaps you recall some debates on the topic of reserving some
> address chunk like 1918, but only for operator's use.
> 
> Here with private AS numbers we actually are facing the same issue
> today. Flat space introduces a bit of a difficulty when both my
> internal ASes (example: data centers) as well as my customer's ASes
> use the same private as number.
> 
> This mandates the knobs like as_override or allowas_in to be applied
> on all address families.
> 
> The simplest way to solve it would be to define two blocks of 4
> octet private AS numbers .. One for multi-as operators and one for
> stub networks. Maybe we could do the same for 2 octet AS numbers too
> if we manage to find some decent block space.

[JM] I'm not sure that adding a single second range would alleviate
this.  This seems to suggest that networks and the services they offer
are somewhat static, or that multi-as network operators could not
acquire services from each other?  Given that little guidance is given
to network operators on private Use ASNs by definition I'm not sure that
we could easily define or expect your customers to abide by a defintion
of whether they are a multi-AS operator versus a stub network unless you
are the one doing the ASN assignment, in which case you shouldn't run
into this issue.  The only workable solution I can envision for your use
case that would guarentee uniqueness is a GLOP style block reservations
so anyone with a Public AS would have another set of private ASN to use,
however this is so much more ambitious/complex than my proposal and
would consume potentially a much larger portion of the pool.
 
Unless others weigh in this is a problem space they feel needs to be
solved, I expect that others will accept the existing knobs or the
workaround of using a Public (RIR assigned) ASN to front services when
connecting to private ASNs that customers own.  I also think that this
problem will be less likely to occur with a much wider range of ASNs
available as David mentioned, assuming you are willing to renumber into
a semi-random location in the new range.


> 
> Cheers,
> R.
> 
> 
> >IDR WG folks -
> >
> >I hope you can take some time from the normal debate(s) to consider and
> >review a fresh draft on expanding the ASN space reserved for Private
> >Use.  All comments regarding content, clarity or structure welcome.
> >
> >Cheers,
> >
> >Jon
> >
> >--
> >
> >A new version of I-D, draft-mitchell-idr-as-private-reservation-00.txt
> >has been successfully submitted by Jon Mitchell and posted to the IETF
> >repository.
> >
> >Filename:        draft-mitchell-idr-as-private-reservation
> >Revision:        00
> >Title:           Autonomous System (AS) Reservation for Private Use
> >Creation date:   2012-06-20
> >WG ID:           Individual Submission
> >Number of pages: 4
> >URL:
> >http://www.ietf.org/internet-drafts/draft-mitchell-idr-as-private-reservation-00.txt
> >Status:
> >http://datatracker.ietf.org/doc/draft-mitchell-idr-as-private-reservation
> >Htmlized:
> >http://tools.ietf.org/html/draft-mitchell-idr-as-private-reservation-00
> >
> >
> >Abstract:
> >    This document describes the reservation of Autonomous System numbers
> >    (ASNs) that may be used within networks but should not be advertised
> >    to the Internet, known as private use ASNs.  This document enlarges
> >    the total space available for private use ASNs by documenting the
> >    reservation of a second larger range and updates RFC 1930.
> >
> >
> >
> >
> >The IETF Secretariat
> >
> >_______________________________________________
> >Idr mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/idr
> >
> >
>