Re: [Idr] new draft - reservation of two already reserved ASNs

[Jared Mauch <[e-mail]>]

On May 20, 2013, at 3:05 PM, David Farmer <[e-mail]> wrote:

> On 5/20/13 08:02 , Jon Mitchell wrote:
>> 
>> IDR -
>> 
>> During the private asn draft process, several times it was recommended
>> that proper documentation of the EXISTING reservations for 65535 and
>> 4294967295 be done, so have posted a draft to try and rectify that.
>> Wanted to get some initial feedback on this draft and add any
>> additional reasoning the group has for these reservations before
>> asking for WG acceptance.
> 
> At a minimum, we need to formally document the technical reservation of the numerically highest 16 and 32 bit ASNs as this draft does.
> 
> However, another approach would be to deal with these two ASNs as a protocol issue and require implementations of BGP to NOT originate or propagate a route with these two ASNs, similar to draft-ietf-idr-as0, section 2 "Behavior".
> 
> While I'm not convinced this is absolutely necessary, we should strongly consider it.  This has the advantage of clearly making any use of these two ASNs an actual protocol error.  As drafted, what implementations should do when these two ASNs are seen is ambiguous. I'm afraid some implementations will treat it as an error and others will not, minimally leading interesting operational situations, and worst case leading to outright incompatibilities.
> 
> On the other hand, treating it only as an operational issue keeps the status quo, and should not require any changes in the BGP protocol. But, if not explicitly disallowed, it should be clear that all implementations must at least provide an option to allow the use of these two ASNs, though.

There is some significant brain damage out there in some BGP implementations.  eg: Cisco reserves the MED of 2^32-1 as INVALID internally and forces anything 2^32-1 to 2^32-2 silently.

There is some hidden knob in some IOS versions that allows it to have 2^32-1 properly and moves that overload elsewhere.

- Jared