[25123] in North American Network Operators' Group
Re: IS-IS reference
daemon@ATHENA.MIT.EDU (Dave Cooper)
Wed Sep 15 16:32:56 1999
Date: Wed, 15 Sep 1999 13:30:16 -0700
From: Dave Cooper <dcooper@gulp.org>
To: Vijay Gill <wrath@cs.umbc.edu>
Cc: nanog@merit.edu
Mail-Followup-To: Vijay Gill <wrath@cs.umbc.edu>, nanog@merit.edu
In-Reply-To: <Pine.SOL.3.95.990914151949.13600D-100000@mailserver-ng.cs.umbc.edu>; from Vijay Gill on Tue, Sep 14, 1999 at 03:28:32PM -0400
Errors-To: owner-nanog-outgoing@merit.edu
Vijay Gill wrote:
>
> On Tue, 14 Sep 1999, Dave Cooper wrote:
>
>
> > 1. if you are going to scale a large national backbone, limit as much
> > as you can in your IGP. the less fluctation in flooding protocols, the
> > better. and since most backbones run on a single area (on the main
> > IGP process) or level-2 only, then fluctuations cause headaches for
> > all participating routers. this is especially so when you have a
> > full layer-2 mesh or a full MPLS mesh.
>
> A full mpls mesh should not be a problem as instantiated LSP's are
> probably not going to be in your igp. Running an IGP over an (opaque) LSP
> adds a lot to your complexity without delivering any major benefits.
agreed.... i don't advocate running igp process on your tunnels. but
is-is does contribute to LS path selection during setup. but has nothing
to do with the IGP process itself. thanks for the clarity, vijay.
>
> You can add hierarchy to your topology obviating a need for a full mesh at
> the L2 level.
>
> Hierarchy can solve almost any scaling issue. Hierarchy in BGP through
> confederations/RR, hierarchy in your IGP and hierarchy in your physical
> circuit layout.
>
> /vijay
>
>
