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

[Dino Farinacci <[e-mail]>]

> Hi Dino,
> 
>>>> 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.
>> 
>> Well the stub AS could be multi-homed and want to load-spread traffic for different prefixes. The a set of advertised prefixes are exceptions for not following the default path.
> 
> 
> ??? If the AS is multi-homed, then it’s not a stub.

It's not transit if it's a multi-homed stub. Like most multi-national enterprise networks. That's what I mean.

> Yes, if this is a third AS (ISP-C) that has other connectivity, then it would see longer prefixes as well as the aggregate.  Traffic would be diverted to the longer prefixes and away from ISP-B, as noted.

That's what I meant by exceptions.

>> 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. :)
>> 
>> If you can, you want to drop traffic early as possible so you optimize network resources.
> 
> 
> As always, it’s a trade-off.  In this case, do you want to optimize your routing resources or a small amount of bandwidth.  You can either carry more specifics or drop P.4 traffic.  IMHO, that’s an easy call.

Not at all clear that its a small amount of bandwidth.

> 
>>>> 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.
>> 
>> Right, but you are trying to fix this, right? You are trying to do better.
> 
> 
> That is indeed the point.  If aggregation happens at the right place, you get traffic engineering close to the destination and you get abstraction farther away. IMHO, that’s ideal.

That is, if where traffic engineering is required or desired. 

> 
>>>> 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.
>> 
>> So what is your conclusion? Is your draft saying to optimize traffic engineering or saving routing table space? Or simply documenting the tradeoffs?
> 
> 
> I’m saying do both: aggregate at the right place and it’s a win-win.  But figuring out where to aggregate does require some thought.

Definitely agree.

Dino