> 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.
Right, but doesn't matter what you call it, the point is where to aggregate. > >> >> 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 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. > >> (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. Right. > 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. Yep, well said. > >> 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. > >> 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. Yes. > >> 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 So what is your conclusion? Is your draft saying to optimize traffic engineering or saving routing table space? Or simply documenting the tradeoffs? Cheers, Dino _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
