Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

[David Farmer <[e-mail]>]

On 12/20/12 09:27 , Jon Mitchell wrote:
>
> David -
>
> I just posted a new rev of the doc which I hope is final incorporating
> the changes discussed on the list previously (must have just crossed in
> the wires with this email).

Yep, I saw it right after clicking send.

> I made slight changes to the section you
> describe, although I put the focus on filtering on the user of private
> ASNs (outbound).
>
> I think whether or not filtering inbound or not is a good idea is
> largely operator preference (I'm personally in favor as it pushes the
> drop closest to the source of the error which I'm generally in favor of)
> and the draft is not meant to dictate specific behavior (this is not a
> BCP doc) in this regard however it seems like if you are using private
> ASN's, it will simplify things a bit from a troubleshooting standpoint
> to not mis-identify a leaked private ASN as one of your own by inbound
> filtering at your border, but the impact in either case is the same and
> minimal (routes that are leaked are the ones impacted only - encouraging
> those who leak to fix their issues).

I'm OK with the focus being on outbound filtering and outbound filtering 
and being required with a "MUST" clause.  However, I believe that 
inbound filtering should be explicitly allowed, but not required, with a 
"MAY" clause being included as well.

However, there is the old mantra of "trust but verify".  So I think we 
need to be explicit that any other operator "MAY" filter inbound.  If 
you get the balance right this can be use to reenforce your focus that 
operators "MUST" filter outbound.

I'll agree my suggested text below did not get the balance right and 
focuses to much on the inbound filtering.  However, both your original 
and new text don't make it explicit that an operator "MAY" filter 
inbound if they wish.  That is what I would like to see added somehow.

> Also, it should be noted none of these issues are new (related to the
> new range), although some of them may have to be revisited as Pradosh
> pointed out if remove private implementations are not updated, and that
> is the focus of the text change I did make.

Completely agree, not a new issue.  However, we are touching the text, 
and vendors are going to need to touch code, so now is the time to fix 
issues, especially if they lead to divergent interpretations.

> Jon
>
>
> On Thu, Dec 20, 2012 at 09:03:56AM -0600, David Farmer wrote:
...
>> So here is some suggested text.
>>
>>     Operators may drop or disregard any prefix received from the global
>>     Internet that is originated from or that contains a private use ASN
>>     in the AS_PATH.  This may result in unpredictable connectivity for
>>     any prefix originated from or containing a private use ASN in the
>>     AS_PATH.  Therefore, all operators using private use ASNs to
>>     originate prefixes or passing an AS_PATH that contains private use
>>     ASNs to the global Internet, must remove all private use ASNs from
>>     the AS_PATH before being advertised to the global Internet.
>>     Furthermore, operators are cautioned to ensure any filters or
>>     implementation specific features that recognize private use ASNs
>>     have been updated to recognize both ranges prior to making use of
>>     the newer, numerically higher range of private use ASNs.

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