Re: ASN draft

[Sean Doran <[e-mail]>]

| Must be true then.  Tagging prefix/mask pairs (NET objects) under
| Aut-Num objects seems to be the way to clearly identify the "home-AS"
| in a route registry.  Paul asked for -one- instance where the ASN is
| not used for BGP.  I gave him one.  Co-opting the NIC assigned ASN
| for use strictly as a routing tag is IMNSHO, a -bad- idea.

You will note that in my brief definition of an ASN as
something that uniquely identifies an AS, I mentioned
nothing about how the ASN should be used.

How ASNs tend to be used is in BGP (for tagging NLRI) and in
policy-routing databases and configurations.   In both
cases, the ASN describes an AS and nothing else.

People sometimes tend to think of ASes and ranges of address
space as inseperable to the point where an ASN is simply a
short-hand for a range of address space.

The reality is a bit different, and flows from some
conventions:

1. An AS has a single, consistent exterior routing policy.
   This could be, for example, hot-potato routing to MCI,
   cold-potato routing to ANS, and so forth.  All traffic
   follows this policy, regardless of origin, once it hits a
   router participating in the AS.

2. ASes are discrete, and inter-AS routing functions in a
   hop-by-hop fashion.

Because of 1 and 2, an AS can be viewed as a single big
black-box router.

3. Any exact prefix/mask pair should originate in a single AS.
   This is a BGP convention, and is relatively new.  EGP and
   PSI violate this convention.

4. An AS may aggregate a prefix/mask pair originating in
   another AS into a shorter prefix.  This is a BGP 4
   convention.  Moreover, as far as other ASes are concerned
   this can obscure or completely hide the AS where the
   longer prefix/mask originated.

Number three makes home-as information useful for some
things, but number four restricts that utility, depending
on where one is relative to the home-as.  In combination,
they do not promise indivisibility of a range of
address-space and AS.

Finally:

5.  Each AS is uniquely identified by an AS Number (ASN).

These four conventions, which are real, and in play, and
adequately describe the way the current Internet operate,
lead me to reject your assertions that:

	-- tagging prefix/mask pairs by originating AS's ASN
	   is valuable in a registry that is to be used
	   globally in that depending on where one is in the
	   worldwide Internet and the behaviours of
	   different ASes, one may see what's in the
	   registry, or something different than what's in
	   the registry, or one may not see what's in the
	   registry.   

           ASes and ranges of address-space are not indivisible.

	   (Consider AS 1280 (CIX-WEST) or AS 1800
	   (ICM-ATLANTIC), which are both ASes with no
	   address-space, or 192.157.69/24, which originates
	   in no AS, or 192.41.177/24, which originates in
           more than one AS.  Then there's AS 1799...)

	-- Using an ASN exclusively to identify an AS is a
	   bad idea.

	   By convention, that's all an ASN is for. 

	   I still fail to see how else one could use numbers
	   like 701, 1239, 1790, 1791, 1792, 1793, 1799, 1800, 
	   1801, 174, 2149, 3561, 3058, and so forth in
           technically meaningful ways.

| It sounds like what you are really after is the functional equivalant
| of the RFC 1597 prefixes.   A set of "reserved" ASN's that are used 
| strictly for routing.

Sorry, I don't understand this.  Please explain.

| Any specific ISP can develop policies to effect egregious
| holddowns to dampen flaps but they won't go away. 

What needs doing is a shift in the mindset that the
closest router should be the one giving a host an
unreachable message.

Moving towards a model where the router closest to the
problem (in most cases) is the one that gives an
unreachable message.

The only things that technically and pragmatically need
to be routed dynamically, such that all non-defaulting
routers on the Internet will drop traffic if the route
goes away, are: 1/ extremely high-traffic prefix/mask
pairs (for pragmatic reasons), and 2/ prefix/masks carried
by multiple ASes (for technical reasons).

Moreover, the scope of propagation in case (2) can be
limited in many cases.

This model is in play in the telephony world.  It is also in
play in the Internet in cases where an aggregate is generated
(204.94/16, for example.  If you try to get to a subnet of
204.94/16 that isn't there due to a line flap or what have
you, it will be a SprintLink router in Stockton that will
give you the unreachable message).

IMHO, it would be a good idea to extend this model so that if
singly-homed prefix/mask pairs become unreachable, their
networks or a shorter-match prefix would continue to be
advertised into the global BGP soup, as that would
dramatically reduce global route-flap.

That is what I will argue at NANOG.  I believe I have 
some measurements of route flap growth at the core vs. the
edges which will make a fairly persuasive statement in favour
of adopting this model in order to protect everybody, and
not just the big routers that are having problems now.

(Hopefully I might even get to say that plans are afoot
to make this easier for operators to configure, router vendor
and bug-fixing/change-making priorities willing)

I do not share your sense of futility about this.

I also do not share the "throw hardware at it -- it's
reality" attitude you express below:

| Time to ask vendors how they intend to deal with
| the need for bigger/better CPU's/Memory etc for the comming 10-12 nets
| world that we are designing for.

That time was several months ago, and vendors started
getting asked these questions back then.

Reality check -- if current trends hold, there will be
nothing available for general consumption and deployment
worldwide before route-flapping and other things which are
scaling proportionally to the overall growth of the Internet,
start causing very serious operational problems for smaller
providers, ex-NSFNET regionals, and networks overseas.

| As clients/customers We are all entitled to tell cisco what to do... Yes?

I'm sorry, I don't remember suggesting otherwise.
I only expressed my personal opinion that IDRP is not
something that Cisco should expend large amounts of 
finite resources on developing and deploying.

I know very few operators who are sitting on the edge
of their chairs waiting with bated breath to deploy IDRP.

I know of several operators who are in that position
and hoping for tools to deal with the real world of BGP4.

Both draw upon the same resources.

Cisco will decide how to allocate those resources based upon
what will bring in the most revenue, and that generally
means doing what most of their customers want.  So yes, you're right.
But then, I never suggested otherwise.

	Sean.