Re: ASN draft

[Bill Manning <[e-mail]>]

A sparing partner! Yeah!

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

But that does/should not detract from the fact that they don't share revenue
streams or cost exposure. They don't have the same technical staffs nor are
they addressing the same customer base.   The rational for sharing the up
stream ISP ASN is:
	-stupidity (anyone have a mis-configured OSPF default blow away IGRP?
	-can't/won't (we don't trust you so we'll use statics, besides it
		      slows down the exaustion of a "scarce" resource -ASN's)
	-hardware (we can't afford new HW so are staying w/ our p4200s and
		   we want full (whatever the heck that means) routes.)


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

again, how to descriminate once you are in the IGP side of things?

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

I'll have to agree here.

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

On more than one occasion, (back when I was doing real work :) I would find that
my downstream clients would incorrectly configure the OSPF/IGRP etc default
and that would raise havoc with my IGP which would in turn affect my BGP peering
with the outside world.  For this reason, we would use EGP or static routes
to insulate their dyanmics to their own "administrative domain"  If they wanted
to fornicate themselves... fine, just leave me alone.  When BGP was available,
we migrated them to BGP.  It's faster and actually had support for some neato
features not found in EGP... (can you say CIDR... I knew you could).

Of course they could still bite my butt with flaps, but that is a fact'o'life
in the internet world.  The bigger it gets, the more flaps there will be.
(Network Flapulence? :)

I was still able to insulate the "offending" parties based on the ASN.

The ASN is the number that defines administrative bounds.  In a route registry
it denotes span of control.  If an AS has the ASN redefined to only be a route
tag, then what will replace it in the route registry to denote span of control?

Of course I have an hidden agenda.  If we could get a working IDRP base from
any commercial router vendor (nudge, nudge, wink, wink) then the whole idea
of ASNs being a scarce resource is a wash.  We have RDI's to contend with.

-- 
--bill