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

[David Farmer <[e-mail]>]

On 7/2/12 12:03 CDT, Robert Raszuk wrote:
> Hi Jon,
>
> I have read your draft few days back and support adopting it as an IDR
> WG doc.

I agree and support support adopting it as an IDR WG doc.

> 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.

I'm not sure it is a good idea to try to define something like this 
within the limits of 2-Byte ASNs.

I'm not opposed to trying something like this for 4-Byte ASNs.  However, 
the analogy you provide isn't quite accurate, as there isn't really ASN 
translation that I'm aware of.  Stripping of private ASNs could maybe be 
thought of as a type of translation, but it doesn't function quite the 
same way especially as multi-layer CGN/NAT.

I'm not sure defining two layers of private ASNs is going to simplify 
anything though.  A provider will still need uniqueness among its 
customer stub ASNs, or have to use knobs like as_override or allowas_in, 
a million private ASNs will make that a lot easier to maintain 
uniqueness though.

A two layer system, might help if two providers are exchanging private 
ASNs and they both have stub customers out of the other range that are 
stripped.  But is that really a common situation?

I think a million private ASNs will be a much bigger help than trying to 
bifurcate the ranges, but I'm willing to listen to arguments otherwise.

> 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
>>
>>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr

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