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

[Brian Dickson <[e-mail]>]

On Thu, Nov 29, 2012 at 11:54 PM, Christopher Morrow <
[e-mail]> wrote:

> On Thu, Nov 29, 2012 at 2:27 PM, Brian Dickson
> <[e-mail]> wrote:
>
> > If the "private use" ASNs were NOT from a well-known range, you would
> detect this how?
>
> some other macro of integers perhaps?
>

The point I was trying to make was, with the PRIVATE range, the purpose &
intent of the ASNs in THAT range is reasonably well defined.

If a large number of ASNs are used, AND non-contiguous, whose intent is
unclear or not specified (and may or may not be "private", as in, not
intended for announcements towards the Public Internet), there is no
general way for a third party to infer the intent. In fact, generally,
intent cannot be inferred.

On the other hand, if there is a new block where the one rule is, "Do NOT
announce to the Internet", then the only inference rules are very clear.

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.



>
> >
> > This actually does a lot to demonstrate the usefulness of the old range,
> and of having a new range larger in size.
>
> how does it help show a larger size range would be helpful?
>
> >
> > If 192.168.0.0/16 was the only RFC 1918 space, the value of 10.0.0.0/8might not be as clear.
> > The analogy is pretty clear.
> >
>
> expand pls.
>
> > Not only is there value in more space, there is value in distinct ranges.
>
> a distinct range is of value, sure. how are more ranges helpful though?
>

A larger contiguous block means anyone USING that block can impose
structure on that block.
Since the block is private, there are no restrictions on how someone
partitioning their own instance might do so.

Structure => tool-friendly

Using tools is generally preferably to managing things manually, and if
done well, reduces the likelihood of errors that lead to non-Internet ASNs
showing up on the Internet.

E.g. a hierarchical network architecture, which incorporates such private
ASNs, e.g. pre-allocated in blocks (by continent, NFL city, router, etc.),
is much simpler to understand (inside the network doing this), and
scalable, and by having the private ASNs from a single well-known and
re-used range, enables third parties to know that the ASNs are not public
Internet ASNs.

The new range of private ASNs not only works for filters, but also various
OSS systems, e.g systems to monitor BGP announcements, which can alert when
anomalous announcement activity is seen.



>
> > Having non-globally-unique space that is well known allows third parties
> to detect leaks, filter, and make permanent bogon filters.
> >
>
> you mean it makes people carry crufty config for exceptions forever...
> sure.
> it also does show some obvious routing problems to the world, or does
> it? maybe it's not a routing problem but a 'forgot to
> cut/paste/replace my ASN for my customer ASN' ? it's not clear at all
> from the data on the wire, except that the reaction to: "I see 65535
> in an as-path" is "that is bad".
>
> if I see:
>  198.41.0.0/24 as-path: 1 2 3 26415 65534
>
> is that a leak or a missed configuration on a 26415 device? (forgot to
> put remove-private-asn on the upstream neighbor to 3).
>
>
It DOES NOT MATTER what the original intent was, or why you see the
questionable ASN.

What does matter, is that it does not belong, and can/should be
ignored/blocked/whatever.

The only time you SHOULD care (i.e. why it shows up), is if the ASN
immediately to the left (of the private ASN) is your own, at which point
you really should take direct action. The important thing is,  YOU will (or
at least should) have all the info you need to figure out why etc.

Without such a well-defined range, there is not always a clear relationship
between the cause and the effect, and the ideal corrective action.

However, with a pre-defined range or set of ranges, you are actually very
concise when you say, "I see 65xxx and that is bad". Nothing more is needed.

Regardless of cause, the effect is "that is bad". At which point, however
many ways there are to get rid of the bad, the correct course is, "make it
go away". As long as there _is_ a way, things are good.

Additionally,  there are plenty of mechanisms for doing ASN re-writing,
which are more general-purpose than just "remove-private-as". So, prior to
hardcoded support for new ASN blocks, the necessary mechanisms to achieve
the same functionality are ALREADY available. There is no need to tie it to
router firmware, as such. (E.g. AS rewriting for ASN migration during
merger/acquisition activity, etc.)


> > In case it is not obvious:
> >
> > Support (strongly).
>
> mostly I'm ambivalent at this point. I'm not really in favor of adding
> more complexity here, especially when there is a regular remedy: "Hi
> ARIN, I need 300 asns for my next 300 deployments, all which are
> scheduled to happen in the next Y days, all of which have a unique
> routing policy."
>
>
The proposal REMOVES complexity, by removing the non-public ASNs from the
RIR-managed space.
It simplifies the logic for non-Internet ASN usage. And for managing a mix
of public and "other" usage, for an SP, managing two pools of ASNs is
pretty straightforward. Especially if one of those does not require
interaction with an RIR.

Hopefully, this clarifies the questions Chris had, as well as illustrating
some of the finer points made earlier.

Brian