Re: [nsp] Cisco vs. Juniper of LSP setup

From: Eric Osborne (eosborne@cisco.com)
Date: Fri Apr 12 2002 - 14:58:17 EDT


On Fri, Apr 12, 2002 at 11:37:19AM -0700, LU wrote:
> Eric,
>
> I am just comparing how JUNOS and IOS are different
> regarding this. My concern is that enabling OSPF
> opaque will generate too many additional LSAs, I am
> not sure if that will be a problem, but that's my
> concern. If I only want to create a LSP tunnel, why do
> I have to use opaque LSA? Why can I just use non-TE
> database to set up the tunnel?

This is like asking why you have to use an IGP, and can't just use
static routes everywhere. The only way to have anything useful is to
do it dynamically. What happens if a link in your verbatim path goes
down?

> Sure, the TE-database will make the setup faster, but I still do not
> see why trying to reserver bandwidth on a no-cspf path is a problem.

consider:
             F
            / \
           D \
          / \ \
         / G |
A---B---C > J
         \ H |
          \ / /
           E /
            \ /
             I

- there is a verbatim LSP from A to J that wants 3 units of BW

A-B and B-C have 10 units available
C-D has 5
C-E has 10
D-F has 0
D-G has 0
F-J has 10
G-J has 10
E-H has 3
E-I has 4
H-J has 10
I-J has 0

all links have equal IGP cost.
there are therefore 4 possible paths your signalling can take
Only one (A-B-C-E-H-J) can fit this LSP.
How do you ensure the LSP takes the right path without being aware of
the link bandwidth in the network? Do you configure 4 verbatim paths?
 What happens if you have an even more complex network, with more than
8 nodes? What happens if you have multiple TE tunnels in this
network?

> Bottom line is, I just want to create a
> static or dynamic LSP, I do not care about any other
> information, thus the opaque LSAs are useless for this
> task, and they will create more instability.
>

This is great in a network that's either very small or which will
never have link/router flaps. So are static routes. If you have a
network where verbatim will really work for you, even under various
failure conditions, feel free to use it. While it's true that we
don't have a knob as simple as no-cspf, I have yet to see a pressing
need for it in real life. I'm sure you can find knobs that either
vendor has which the other does not, but which are pretty useless.

For example, we have a knob, 'mpls traffic-eng link-management timers
bandwidth-hold' that I've been told JUNOS does not. I have yet to
find a use for this knob.

It sounds to me like you're taking an academic approach to this,
rather than a real-world one. You're free to do that, but if you do,
you will run into all sorts of 'shortcomings' that are academically
useful but operationally nonsensical.

eric

> Thanks
> LU
>
> --- Eric Osborne <eosborne@cisco.com> wrote:
> > On Fri, Apr 12, 2002 at 10:49:49AM -0700, LU wrote:
> > > Sean,
> > >
> > > If I understand this right, not only IOS does not
> > have
> > > the function of ignoring TE datatbase like the
> > > "no-cspf" in Juniper, it also can not run RSVP
> > without
> > > enabling OSPF opaque LSA on a interface. I have
> > not
> > > tried IS-IS, but I assume it has to have the
> > > wide-metric enabled in order to run the MPLS-TE,
> > > right?
> >
> > There is no command to explicitly enable/disable
> > opaque LSAs in TE.
> > There are two commands you could be referring to -
> > 'mpls traffic-eng'
> > under OSPF, or 'mpls traffic-eng' on the interface.
> > Both do more than
> > just opaque LSAs, tho.
> >
> > Why do you want to do this? It works fine in some
> > cases, but if you
> > have a no-cspf path and you try to reserve bandwidth
> > on that LSP, you
> > can paint yourself into a corner.
> >
> > There are some legitimate uses of verbatim/no-cspf,
> > but I'm curious to
> > see what your use is.
> >
> >
> >
> > eric
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:40 EDT