Re: [Int-area] Where to aggregate, where to drop

[Tony Li <[e-mail]>]

Dino,

Thanks for the question.

> When a provider proxy aggregates, it means they will summarized more specific routes they have stored in their routing table. Like ISP-A above has routes P.1, P.2, and P.3. When ISP-A advertises a P prefix, it is indicating it can reach all more specifics, even though it may not have a full-set of those more specifics that are covered by P.


In the figure, ISP-A is the administrator for P, so when they aggregate it’s not proxy aggregation, it’s just simple aggregation.

> 
> So here are the options:
> 
> (1) ISP-A advertises P to ISP-B (and may also advertise more specifics to other peers for policy reasons).
> (2) ISP-A advertises P.1, P.2, and P.3 to ISP-B and ISP-B advertises P to its peers.
> 
> The questions is *where is the best place to aggregate*. Its a tradeoff on routing table savings and how far a packet can travel to either (1) get delivered to the destination or (2) get dropped by a router that doesn't have a more-specific for the destination (thereby wasting resources from the source to the drop point).
> 
> (1) If ISP-B aggregates P to the links you see above to stub peers, then the stubs can load-split on P and ISP-B can drop packets for say P.4 and deliver packets for P.3. The drop can happen at the PE router relatively soon.


If they are stub peers, then sending them anything more than default is inefficient. Yes, ISP B will drop anything for P.4.  There’s no way to deliver that any way.

If the peers are not stubs and ISP B advertises P, then yes, it will attract P.4 traffic.  Presumably, the peers are not learning alternate paths for this traffic, so there’s also no way of delivering this traffic and ISP B would get to drop it.  

I’m not sure why we’re trying to optimize drop traffic. Hopefully, there isn’t a large volume of it. :)


> (2) If ISP-B gets P from ISP-A and advertises to the links you see above to stub peers, then P.3 and P.4 packets move through ISP-B where the edge router in ISP-A delivers to P.3 and drops for P.4.


And in that case, ISP B has now paid for transit for P.4 drop traffic. That seems painful.

As you point out, there’s a trade-off here: if you move the abstraction action boundary outward, you carry more prefixes but you drop unreachable traffic sooner.  If you move the abstraction action boundary inwards, then you carry fewer prefixes, possibly damage traffic engineering, and cause unreachable traffic to take a longer path before it’s dropped.


> All things not considered and looking at this specific topology, I would vote for (1).


Of course, but what we’ve found is that prefix owners are not willing to just aggregate. They want traffic engineering so they also advertise more specifics.  Thus, the question is (2) or (3) let more specifics propagate throughout the network.


> Another issue, which I think Tony brought up is, if P gets sent to peers, hijackers have a better opportunity to hijack routes by injecting more-specifics to direct traffic to a bad acting honey pot. This has been known for a long time though so we are not bringing up a new issue.


Actually, the point that I was bringing up was not one of security.  If more specifics are also present when ISP B performs remote aggregation, then the more specifics will tend to draw traffic away from ISP-B.  ISP B might like that.


> Another question is, if all more-specfics are not stored (due to major link failure), is the aggregate withdrawn from the routing system. That is, if you want less route flapping, you may just want to keep P advertised. That optimizes FIB add/delete entropy everywhere that wants to store P. I would rather have hardware routers drop packets fast, then to have route oscillation.


Yes, if ISP B isn’t getting all of the more specifics and continues to aggregate, it could attract traffic that it can’t deliver. Presumably this is a transient until it can get the more specifics.

Tony