mtinka at globaltransit
Nov 9, 2009, 12:22 AM
Post #17 of 26
(1243 views)
Permalink
|
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
1
