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

[Jon Mitchell <[e-mail]>]

Robert - this appears to be a non-private use case as you are providing
service to multiple customers, and I support it and encourage you to
work a proposal through the proper venue (RiR's) to get them to lower
the bar for applying for larger blocks of public ASNs if necessary,
however I think fixing this particular problem is orthogonal to the
draft proposed.

By definition, a Private Use reservation by IANA is unreserved for a
specific customer and re-use is to be expected, in accordance with
section 4.1 of RFC 5226.  I don't expect this draft to fix/change every
situation where AS_PATH manipulation hacks are used, but it should
reduce the ones where they are used for communication within one
administrative domain that can allocate their own numbering yet the
number of sites exceeds 1022.

Jon

On Tue, Jul 03, 2012 at 10:21:41AM +0200, Robert Raszuk wrote:
> <offline>
> 
> Hi Jon,
> 
> Thx for your reply.
> 
> How about a bit different approach.
> 
> Could we define a new AS allocation option that I get a registered
> AS block of ASes rather then single AS as it is today ?
> 
> So if I get registered AS (first three octets) and fourth octet ANY
> then I would have no problem reg my case of any possible private AS
> overlap with my customers.
> 
> Just like we allocate prefixes ;)
> 
> Thx,
> R.
> 
> 
> >
> >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
> >>>
> >>>
> >>
> >
> >
>