On Sunday 08 November 2009 08:10:05 pm Mikael Abrahamsson wrote: > In order to detect loopbacks going away and using this to > invalidate/remove next-hops quickly, you can't aggregate > anyway.
My point exactly - the use of Route Leaking without the ATT bit nullifies the need for a multi-level IS-IS network for the sole purpose of scaling. > Sorry, I have yet to hear someone describe an ISP network > (designed as per ISP essentials, carry loopbacks in IGP > and everything else in BGP), where IGP aggregation makes > sense. If you have 10k routers in your IGP, well, you > most likely did something wrong earlier in the process. Completely agree with you, and I reiterate my statement in the paragraph above. While this may apply specifically to MPLS-enabled environments, you might like to know (in case you don't already) that 'draft-swallow-mpls-aggregate-fec-01.txt' proposes an extension to LDP that would allow it to form an end-to-end LSP without the need to hold each and every routing entry for all routers in all routers, i.e., it permits the end-to-end LSP setup while also allowing IGP route summarization. Check out: http://tools.ietf.org/id/draft-swallow-mpls-aggregate- fec-01.txt But as mentioned, it only applies to MPLS environments. It sounds interesting but I'm not sure whether we'd be keen on a feature like this. Given that we carry only infrastructure and Loopback addresses in IS-IS (and the fact that our routers are fairly CPU-able), we're not concerned about sacrificing scaling for optimality as it pertains to IGP route summarization, or lack thereof. > Also, with modern processorns and techniques such as > partial tree recalculation in modern router OSes, I'm > sure even 10k routers would be manageable in a single > area. Again, completely agree - and while I wouldn't want to start a "war of the protocols", I think IS-IS is better at this than OSPFv2, not only because of features such as iSPF, LSP Lifetime, PRC and SPF Delay, but also because unlike OSPFv2, IS-IS cleanly separates IP Reachability information from topology information, as distinct TLV's are used to encode both bits of information. Because OSPFv2 carries IP Reachability information in Type 1 and Type 2 LSA's, it means changes in IP Reachability information only will initiate a potentially unnecessary update of the topology information as well, e.g., when all that has changed is the metric for a route, and not a failure of a link. In this case, PRC in OSPFv2 is relegated to Type 3, 4, 5 and 7 LSA's, and this starts to get into OSPF hierarchy (which is the issue under discussion at this point in this thread). OSPFv3 has been fixed re: this limitation, as IP Reachability information and topology information has been encoded into separate data structures, much like IS-IS. But coming back to why I think the L1 and L2 separation might come in handy, is if we decide to isolate a part of our network for one reason or another. Why, one might ask? For better or worse, we have a number of scenarios where deploying networks that should have nothing to do with the rest of our backbone are being considered (these are mostly business reasons, not technical - just to be clear, hehe). In such a case, while the separation of L1 and L2 databases is not the driving factor for this, it becomes an unintentional enabling by-product of this structure. Again, this probably isn't reason enough to do things this way (as mentioned to Richard in my previous post, our goal for migration was because IS-IS is "stretchy" and not because OSPF is eating up too much router CPU), but in our case, the operational difference between running the network in either mode is trivial. Cheers, Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
