most current version

[abha ahuja]

> 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 agree that the smaller guys with the least resources would want to
reduce their load the most, they are the least likely to be able to do
something like this.  almost all of these aggregation techniques are only
useful for sender-side.  So, in general, it will reduce the amount of
garbage sent between peers.  rx-side aggregation is possible, but not in
nearly as many situations from what i can tell... please feel free to
discuss because maybe i am missing something.


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

hmmm... rx-side filtering is only possible if the next-hops are the same
for 2 paths.  if the next-hop AS/ip is the same for both, then it is
possible to filter out a more specific without any loss of information.
or am i missing what you are saying here?

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

agreed.  but, if the bgp rules are still followed, ie - you only advertize
what you are using (special knobs aside) this shouldn't cause
unreachability.

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

you are correct.  

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

is there a draft on this?  definitely interested.

-abha ;)