[c-nsp] IS-IS Multiarea on 12.2 SR

[Mark Tinka]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20091109/2886952b/attachment.bin>