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

[Jon Mitchell <[e-mail]>]

Pradosh / Randy / et al - although Robert has pointed out already that
in the end someone who knows that these routes need to go to the
Internet needs to peer with said Enterprise in your example, and this
ISP is ultimately responsible for allowing the routes to reach the
Internet (and can consider the operational considerations that is
already fairly clear in my opinion), I think this is a moot point.
However, thinking about your inter-as use case if combined with Internet
access gateway type functionality or other random topologies, I can
certainly create some that allow an ISP that allows BYOA (bring your own
asn?) to accept routes from an ASN that is private (old range) and
provide transit to a new range ASN behind that old range.  I actually
think this problem is not a large operational concern as it already is
an artificat of mis-configurations and mis-understandings of said vendor
implementations in the existing range.  Those using private ASNs and
leaking them to the Internet do not get a lot of tear drops when their
prefixes are dropped based on ingress filters or as-path loop detection
by other networks.

I think a large part of the debate on this draft has been due to the
implication that these would be used by organizations that allocate ASNs
to others outside their organization, such as ISPs, versus internal use
within very large organizations.  After WGLC, if the draft proceeds, I
may propose small changes to the operational considerations section as
there does seem to be sufficient angst, especially from the ISP
community on behavior changes (to use private ASNs in more networks or
applications that otherwise wouldn't have I guess) that may be induced
by operators based on there being an expanded range.  Are there others
who think that the following modification(s) would be useful (whether or
not you support the draft)?

(from the last sentence of 1st paragraph and total of second paragraph
is the new proposed text, ignore sp or grammer errors)

---
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.  Prior to making use of the second, numerically higher, range
of these ASNs network operators should be confident any implementation
specific features or filters that recognize private use ASNs have been
updated to recognize both ranges correctly so that no unintended
announcement of private use ASNs to the Internet occurs.  Specifically,
any implementation specific features should treat both ranges similarly
and there is no need to differentiate between the existing and new
ranges.

Networks that provide Internet connectvity for prefixes originated in
other ASNs should be cautious about allocating the new range or ever
guarenteeing transport of prefixes originating from private ASNs
especially if alternative approaches can suffice for their needs, for
instance as described in RFC2270.  Certain topologies, whether using the
existing or new range, can cause vendor specific implementations of
features that recognize the private ASN range to not remove all
instances of the Private ASNs from the AS_PATH, resulting in a prefix
that may not be reachable from all of the Internet due to containing a
Private ASN.  Private ASNs also introduce additional complexity
especially during network mergers and consolidations and careful
consideration should be given to their use versus a globally unique ASN
from a Regional Internet Registries (RIR).
---

Let me know your thoughts on this...

Thanks,

Jon


On Wed, Dec 05, 2012 at 09:45:14PM +0000, Pradosh Mohapatra (pmohapat) wrote:
> >I think both Tony and Jay forgot that routing and reachability is not
> >about originator AS .. it is about prefixes they advertise.
> >
> >If peering ISP AS chooses to peer with private as or remove private as
> >from AS-PATH or for completeness substitute with their own it is all
> >ok. He takes responsibility to route data to such customer(s).
> >
> >Any subsequent removal of private as in the path also results in the
> >same responsibility of the provider who permits private AS for
> >peering.
> >
> >I am not sure why there is concern with it on the list.
> 
> 
> Not sure you understood the issue Jay was pointing to - but it is a
> problem worth talking about if we are serious about advancing this draft.
> 
> Say an enterprise starts using ASN 4278190081. It already has a bunch of
> ASNs from the 16-bit private AS range and relies on the correct behavior
> of "remove-private-as" from the ISP. The ISP routers are not upgraded to
> understand 4278190081 is a private ASN. We get into all sorts of
> interesting scenarios based on the connectivity graph (changes in traffic
> pattern come to mind as I know folks compare AS_PATH length taking into
> account remove-private-as).
> 
> The 'operational considerations' section does talk about this - but I
> would like it described in more detail.
> 
> - Pradosh
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr