Re: ASN draft

[Paul Traina <[e-mail]>]

> this rephrasing (and the rest of this document) discount the concept
> of "a single technical administration" as a basic criteria for ASN
> assignment and focus on the Exterior routing aspects. 

Yes, and let's look at reality here for a moment.  Almost all stub customers
of ISPs run under the ISP's AS number.  They certainly don't have a single
technical administration, nor do they have similar security policies.  The
only thing in common is their routing policy.

Let's cut to the chase...

> 4. Common errors in allocating ASes
> 
>    The term AS is often confused or even misused as a convenient way of
>    grouping together a set of prefixes which belong under the same
>    administrative umbrella, even if within that group of prefixes there
>    are various different routing policies. Without exception, an AS must
>    have only one routing policy.
> 
> This seems to fly in the face of the BGP definition (and the one to which
> I subscribe). ASNs have more uses than just routing. They are the way to
> define administrative/political/trust bounds.

Which are ONLY useful for making route determinations.  If there is no
route determination differential, then there's nothing wrong with clumping
together ASs.

The whole concept of an AS under common administrative bounds has nothing to
do with the way BGP uses ASs _today_.  I think we can all agree on that
statement, so let's get to the more conceptual question:

Is there any reason to maintain the idea of an AS as a collection of prefixes
under common administration and sharing the same security/trust policies?

If you can show just cause, then I'm willing to agree with you, at which
point, I will wet my panties because we're going to run out of AS space next
week.  However, I think that you will be hard pressed to show a case where
an AS could possibly be shown to have anything other than the same routing
policy (don't forget, path's are trivially spoofable).

Paul