most current version

[john heasley]

Wed, Mar 14, 2001 at 01:50:36PM -0500, abha ahuja:
> 
> okay... 
> 
> here is pointer.
> http://www.merit.edu/~ahuja/draft-ptomaine-taxonomy-00.txt 
> 
> i sent to bcole to review as well. 
> will announce today.  
> 
> in meantime, you folks should prolly subscribe to list (thanks, heas!) if
> you haven't already....
> 
> -abha ;)
> 
> majordomo at shrubbery.net, subscribe ptomaine

the draft doesnt consider differences of effects from the POV of a
transit AS (ie: teir 1 or teir N ISP, say sprint and ELI) vs. an
end node.  it is the end nodes, those small dialup ISPs (for eg),
who have older routers with less resources that would benefit most
from some degree of filtering or rx-aggregation or the knobs to do
so.

i suggest that it would be {near} impossible for a transit AS to do
either rx filtering from peers (where filtering means /dev/null).  loss
of routes from filtering could easily result in unroutable prefixes
should the resulting aggregate be withdrawn or one of the two contributing
routes behind the aggregate become unreachable; in fact, the rx-router
enjoys no resource benefits (in fact it is penilized) as for this problem
to be avoided, the router must retain the contributing routes and consider
these in recomputations; not to mention that should it be necessary to
withdraw the aggregate and advert the specifics, there are at least 2
computations (advert valid specific, remove aggregate).  hmm, could that
be magnified as it trickles through secondary ASes or flaps?

also, every AS at the same "level", if you consider "level" to be AS-hops
as in the transit ASes between a src and dst AS, as in:

	N - 1239 - Z
	N - 2914 - Z

2914 and 1239 would have to do filtering and/or aggregation the same
way, have the same routes, ???? to prevent loss wrt route selection for
end nodes.

otoh, for a small AS w/ 2 T1s, trying to turn bgp knobs to gain
balance in either direction can be large and repetitive task.  this
proxy aggregation makes this even more difficult.

] ID - (SO, SN) - the same prefix from the same neighbors and the same
]    origin AS
] 
]            198.108.1.0/24  from 1 2 3
]            198.108.1.0/24  from 1 11 3
] 
]    Only one of these prefixes would be sent from AS 1.  AS 1 would pass
]    only the best route.  However, there is a case where if AS 1 is
]    peering with your network in multiple places and is not announcing
]    their routes consistently, some of the receiving network's internal
]    routers would show both of these paths in the RIB.

there is nothing inconsistent about this.  if AS 2 and 11 connect to
two different routers within AS 1 and the routes are equal in all
respects (wieght, lclprf, ...), AS 1 is going to avert the route it
chooses as best; ie: the route whose next-hop is closest igp-wise.
and, assuming the AS 1 doesnt not alter the route, all the routers in
the ibgp mesh should have both prefixes in their RIB.

imo, shoot this thing before it spawns.  time might be better spent on
defining more effective knobs for route selection than lcl pref,
alternatives to traditional multi-homing....

what happened to ed kern and dianne's draft (or was it just a nanog
presentation) on multihoming without an AS?  what if 2 peering teir 1s
were to assume an AS akin to rfc 2270 for which customers of these
2 teir 1s were to use and/or aggregates of the routes were origin this
AS and specifics of were exchanged between the 2 teir 1s.  eg:

	rfc2270 AS 5
	teir 1 AS 1
	teir 1 AS 2
	aggregate 192.168.0.0/16 origin AS 5 announced by 1 and 2

	AS 1 and 2 exchange specifics of the aggregate over their peering
	links.

this allows reduction of the number of global prefixes and continues to
allow AS 5 the same degree of redundancy given typical peering practices.
otoh, it assumes AS 1 and 2 can enter into such a business agreement and
remain cooperative; so maybe it is impossible.