Subject: [Idr] new revision of private use ASN reservation draft

From: Jon Mitchell <[email-masked]>
Date: Mon, 6 Aug 2012 16:33:38 -0400

IDR folks -

Thanks for the helpful feedback both during and after IDR WG meeting in
Vancouver.  I've revised the draft with the following changes:

        1.  Tighten wording, hopefully increased readability.
        2.  Close existing range at 65534, matching existing IANA
            reservation.
        3.  Change structure of range to bit boundary friendly.
        4.  Increased size of range to 2^24 (~16M).

Cheers,

Jon

--

A new version of I-D, draft-mitchell-idr-as-private-reservation-01.txt
has been successfully submitted by Jon Mitchell and posted to the IETF
repository.

Filename:        draft-mitchell-idr-as-private-reservation
Revision:        01
Title:           Autonomous System (AS) Reservation for Private Use
Creation date:   2012-08-06
WG ID:           Individual Submission
Number of pages: 4
URL:
http://www.ietf.org/internet-drafts/draft-mitchell-idr-as-private-reservation-01.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-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-mitchell-idr-as-private-reservation-01

Abstract:
   This document describes the reservation of Autonomous System numbers
   (ASNs) that are for private use only and 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

---

From: David Farmer <[email-masked]>
Date: Mon, 06 Aug 2012 16:19:23 -0500

This looks really good.

I have a suggestion for the Operational Considerations, Section 3.  I'd 
suggest adding, something like the following;

"If private use ASNs are used between cooperating operators, special 
attention should be given to ensuring uniqueness of the private use ASNs 
between the operators. The use of the newer, numerically higher range of 
private use ASNs is recommended for such cooperative use between 
multiple operators, its significantly larger size allows the 
coordination of large ranges for each cooperating operator, simplifying "

On 8/6/12 15:33 CDT, Jon Mitchell wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 20 Aug 2012 10:11:18 -0400

On Mon, Aug 06, 2012 at 04:19:23PM -0500, David Farmer wrote:
> This looks really good.
> 
> I have a suggestion for the Operational Considerations, Section 3.
> I'd suggest adding, something like the following;
> 
> attention should be given to ensuring uniqueness of the private use
> ASNs between the operators. The use of the newer, numerically higher
> range of private use ASNs is recommended for such cooperative use
> between multiple operators, its significantly larger size allows the

Although in many cases, we know that these situations are a reality, I'm
a bit concerned about the language here as it might encourage such use
or mis-use of private ASN's that both Chris and Randy were concerned
with, and boundary (public) ASN's or other approaches maybe better
approaches to solve this problem depending on the specific use case.
Secondly, the above seems to imply that using the newer range is
preferred, when in reality many other approaches as long as they were
coordinated would work (one use older range, one use newer range,
centralized database/registry, etc...).  I'd prefer to keep the operator
guidance to items that have impact on the Internet community at large
rather (Internet boundary cases) rather than trying to outline any best
practice on how to deploy these inside of Enterprises, but open to
others feedback on whether some version of just the first sentence of
the above would add value.

Jon

---

From: Randy Bush <[email-masked]>
Date: Mon, 20 Aug 2012 23:22:56 +0900

> Although in many cases, we know that these situations are a reality,
> I'm a bit concerned about the language here as it might encourage such
> use or mis-use of private ASN's that both Chris and Randy were
> concerned with, and boundary (public) ASN's or other approaches maybe
> better approaches to solve this problem depending on the specific use
> case.  Secondly, the above seems to imply that using the newer range
> is preferred, when in reality many other approaches as long as they
> were coordinated would work (one use older range, one use newer range,
> centralized database/registry, etc...).

let's be honest here.  what is being said is that this is really a new
public space with ad hoc assignment and recording.  we already have a
centralized database, we should use it.

randy

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 20 Aug 2012 11:01:44 -0400

> centralized database, we should use it.

Disagree, but I think we already established that.  I know of at least a
couple of use cases where private ASN usage needs to be coordinated
between different groups (typically within a company) but there is no
Internet connectivity for said ASNs.  When I said registry above, I
meant private registry run by an organization for the users of their
private ASN space, not one that is exposed to the public or Internet
(maybe wrongly used the word centralized to describe this).  That said,
I'm happy to not mention coordinated assignment in the draft at all as I
mentioned above, I actually think this is the more sane approach as
otherwise we are detailing many use cases for private asns and giving
recommendations and guidance on what should be done for each (which in
some case is definitely not to use them).  I'd prefer to stay out of
recommendations for how people use "private use" ASNs as unless they are
leaking these improperly to the Internet, it should not impact me.  :-)

Cheers,

Jon

---

From: David Farmer <[email-masked]>
Date: Mon, 20 Aug 2012 11:18:15 -0500

> the above would add value.

Ok, I'm fine with that, but then I think it should be explicit that it 
is not providing guidance on the use of private ASNs other than their 
interface with the Internet.

Note: I was only trying to say that coordination within a larger block 
is typically easier, and therefore the larger block my be preferred in 
such cases.