On Fri, Oct 22, 2010 at 2:22 PM, Geoffrey Pendery <[email protected]> wrote:
> > Not true. All /prefixes/ will still be visible in all areas without > summarization, but you'll still minimize the LSDB because type 1 and 2 LSAs > never cross an area boundary. > > Right, but as Brett mentions, that doesn't stop them, it just turns > them into type 3s. Sometimes it even turns a single type 1 (with stub > networks on it) to multiple type 3s. > I am curious if someone can explain any benefits to non-summarized > areas. The main benefit is that link and router failures in separate areas don't trigger SPF/Diijkstra. Also, when SPF is run it's not as hard to calculate a path to a destination outside of the area. As someone mentioned these guidelines are rather old, definitely before routers with 1G or more of RAM and multi-core processors. > Perhaps the flooding model is reduced a bit by relying on a > small number of ABRs to flood the type 3s, rather than intra-area type > 1 and 2 flooding? > Flooding is still relatively the same. The number of LSA's remains the same they are just of a different type. So your neighbors will still send you the same number of routes even if they are advertised from one or two ABRs. > > I honestly don't know, and would like to. > > > According to Jeff Doyle, control plane performance concerns are not > related to running Dijkstra, but rather lie in LSDB maintenance: Keeping > track of timers and such. > > So if this is the case, it would seem the LSDB doesn't get any smaller > (with type 3's subbing in for 1 and 2), except now ABRs have to > maintain multiple LSDBs, thus doubling/tripling their burden? > I'm actually not sure about this either. Specifically, why it's easier to manage an LSDB full of type-3's rather than one full of type1/2's. Also, does any of this still matter? Many of the higher end routers have as much processing power as servers did when these standards were written. Keegan _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
