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

[Jon Mitchell <[e-mail]>]

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

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.

Jon


On Thu, Dec 20, 2012 at 09:03:56AM -0600, David Farmer wrote:
> I know the last call is over so ignore this if you wish;  However,
> I've been thinking about the issue of filtering private ASNs through
> out the discussion, but I hadn't identified what was bugging me
> until now.
> 
> Here are a couple quotes for some context;
> 
> On 11/29/12 13:10 , Jon Mitchell wrote:
> >Any network can filter private ASNs as well as various other types of
> >ASNs on ingress that they do not want to not accept/propogate.  This
> >draft will have no impact on whether people tend to do that correctly or
> >not in my opinion.  Folks who have no use for more than a thousand
> >internal use ASNs today are not likely to use this new range.
> 
> On 11/30/12 14:15 , Brian Dickson wrote:>
> > If you see it on the Public Internet, it does not belong and can be
> > ignored safely, and should not be propagated to one's Internet
> > peers/customers.
> 
> But several others have made similar comments as well.
> 
> This is basically covered in Section 3 "Operational Considerations"
> in the draft.  Here is what it says now;
> 
>    If private use ASNs are used and prefixes are originated from these
>    private use ASNs which are destined to the Internet, private use ASNs
>    must be removed from the AS_PATH before being advertised to the
>    global Internet.  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.
> 
> I like that this says "private use ASNs must be removed from the
> AS_PATH before being advertised to the global Internet."  However,
> it finally hit me that in the quotes above, and in others as well,
> we have said "if you see private use ASNs on the global Internet you
> can filter them." But, this is only implied by the text in section
> 3, not explicitly stated.  So, I suggest that section 3 also
> explicitly state that operators may filter private use ASNs they
> receive from the global Internet.
> 
> 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.
> 
> Again the intent of the change is to explicitly state operators can
> filter any prefixes received from the global Internet that uses
> private use ASNs.  In addition to stating you must not send the to
> the global Internet in the first place.
> 
> 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
> ================================================