Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00 concluded, extended to consider ASN range

[David Farmer <[e-mail]>]

On 12/20/12 12:05 , Jon Mitchell wrote:
>
> On Thu, Dec 20, 2012 at 10:47:54AM -0600, David Farmer wrote:
>> On 12/19/12 08:57 , Jon Mitchell wrote:
>>
>>> Maybe some others would like to weigh in on one of the above options now
>>> that it's a focused discussion (otherwise I plan to make the small edits
>>> discussed in previous threads and move the start of range to
>>> 42xxxxxxxx so we can close this out...)
>>
>>
>> The idea is to allow the simple regexp of 42???????? to match
>> private use ASNs.  However, this makes a few assumptions.
>
> Human identifiable range was the primary concern raised with regex
> implementation another given justification for changing the
> recommendation to IANA for the start of range.

Bull!! Lets be honest here, 10 digits without any separators doesn't 
meet any definition of human friendly I can think of.  Also, humans 
would recognize 4.28B and above just about as easy as 4.2B and above, 
the real reason to go to 4.2B is it makes the regexp much simpler.  I'm 
fine with that, but its to make regexp easy.  However, picking 4.2B to 
make the staring point human/decimal/regexp friendly but completely 
ignoring the any issues at end point isn't going to work either.

>> 1. While not part of the Private Use ASN range, the intended regexp
>> also matches the reserved ASN 4294967295, and therefore 4294967295
>> can never be a valid ASN in an AS_PATH.
>
> The draft does not state how to construct a regex, this is out of scope
> for the draft.  Some operators may not even choose or need to filter
> private use ASN's inbound or outbound based on their
> requirements/design.

That argument doesn't fly, because you are saying that they MUST filter 
outbound to the Internet.  Yes, if there not announcing to the Internet, 
then there isn't an issue, but that is a common enough use case that it 
makes scene to provide some guidance on how to properly implement the 
filter you are saying they must implement.  You don't need to cover 
every possible solution, but saying that regular expression of the from 
42????????, where "?" selects 0-9, would provide a very big hint.

However, my primary motivation in bringing up the end point issues 
aren't operational, but is to ensure future protocol work doesn't create 
an issue with how people use the Private Use range.  If there were some 
future protocol changes, especially anything that required 4294967295 to 
be valid within the AS_PATH, there could be issues. I don't think anyone 
thinks this should happen, but its not explicit anywhere.  I'm only 
trying to make sure we don't making a similar mistake that was made with 
AS65535 in RFC 1930, that we are fixing now.

As a mater of fact this could be an issue with any range, no matter what 
size we pick, at the top of the 32bit ASN range.  The regexp issues with 
4.2B is only one possible issue.  There could easily be issues with 
4294967295 and your original range.  It would be problematic for many 
reason if 4294967295 became a valid ASN within AS_PATH.  If we're going 
to pick a range at the very top end of the 32bit ASNs then that should 
be made clear.

Also, you say were picking 4.2B primarily to be human friendly.  But, 
there is nothing human friendly about 4294967294 being part of the range 
and that 4294967295 is not part of the range.  So at the very least we 
should make it abundantly clear 4294967295 is not part of the range.

Maybe something like this, creating a new section;

    X. Other Reserved ASNs

    It should be noted that 65535 and 4294967295 are reserved ASNs,
    documented in the IANA Autonomous System Numbers Registry [IANA.AS].
    These two ASNs are the numerically highest values in the two-octet
    and four-octet AS number spaces respectively.  While directly
    adjacent to the Private Use ASNs they are not part of either
    Private Use ASN range, and MUST never be used as Private Use ASNs.
    However, any protocol changes effecting the status of these two ASNs
    should consider any impact on how the Private Use ASNs are used.

This makes it abundantly clear that these two ASNs are not part of the 
Private Use ranges, this conspicuously corrects RFC 1930 regarding 
65535. Further, it makes it clear there are no other valid ASNs above 
4294967295 that need to be worried about.  Finally, it make it clear 
that the current status of these two ASNs as reserved is important to 
the Private Use ranges and that any changes could have an impact on the 
use of Private Use ASNs.

>> 2. The intended regexp would select ASNs beyond the 32bit ASN range,
>> if they were valid, that is 4294967296 through 4299999999.
>> Therefore, if the ASN range were ever expanded to make these valid
>> ASNs, the private use ASN range would also need to be expanded to be
>> included these ASNs as well.
>
> Certainly something operators should concern themselves with when
> discussions start on moving beyond 4 byte ASNs (maybe a note about it
> could be attached to that draft).  On a side note, do you plan on this
> before or after IPv6 exhaustion?

Again its not the operators I'm worried about, its how future protocol 
work would interact the assumptions we are making about the validity of 
picking 4.2B as the starting point, and basically ignoring the end point 
issues.  This is mostly a hand wave for the operators, and that's fine, 
it will probably just work.  But, if the protocol guys do something in 
the future today's operational hand wave could become tomorrows ugly 
problem.

>> If we want to use 4.2B as the starting point to simplify regexp
>> matching of the private use range then these assumptions need to be
>> explicitly stated in the draft.
>
> I disagree, I prefer not delving how to construct regex's properly or
> stating how they work in various implementations in a simple IANA
> reservation draft.

While I'd prefer we did cover the whole regexp thing, that's not really 
necessary to deal with these issues.  If you include something like the 
text above regarding 4294967295, it makes it clear there are range 
endpoint issues that should be considered carefully.  I'd be OK dropping 
any discussion of what happens if you expand the ASN range, that is 
probably out of scope.  But the above text makes it clear that there are 
no valid ASNs above 4294967295, that should be enough of a hint if you 
don't cover the regexp stuff explicitly.

Thanks.

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