> 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
