most current version

[john heasley]

Wed, Mar 14, 2001 at 06:01:57PM -0500, 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?

if i produce 0/23 out of 0/24 and 1/24, i have to retain both of those /24's
so if either is withdrawn i know the aggregate is crap and i have to tell
my neighbor.

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

no, the end nodes loose information.  eg: 1239 has a policy to tx-aggregate
to their customers and 2914 does not.  which route(s) end up in the fib
and which are used for forwarding?

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

ed would have to comment.  randy, weren't you involved?  you arranged to
land that t1 from their lab in vienna and we loaned them a prefix to
play with.