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

From: LU (wenxuecity2001@yahoo.com)
Date: Fri Apr 12 2002 - 16:48:40 EDT


--- Eric Osborne <eosborne@cisco.com> wrote:
> On Fri, Apr 12, 2002 at 01:10:34PM -0700, LU wrote:
> > I may be missing some thing here.
> >
>
> Yes...
>
> > If there are multiple IGP paths and only one of
> them
> > has the bandwidth demanded from the LSP, even if
> > without TE-database, we should be able to get
> there,
> > just try them one by one till it finds it.
> >
>
> How do you propose to find the right path? What
> decision algorithm
> will you use that will find the best path for a
> given LSP without
> being able to see the path in front of it?

It is seeing the roads, just do not know how wide the
roads are.

>
> The problem with that is that you either need
> crankback or explorer
> frames, neither of which are particularly pleasant
> (or standardized
> for TE).

How does IOS signal the ingress when there is no
enough bandwidth?

Plus, since you'll tend to have far more
> TE LSPs than
> nodes/links, you'll end up with more traffic
> exploring that you would
> just distributing info via IGP.

I could just use LSP somewhere to tune the traffic, no
necessrily use it all over the place.

>
> If you want to get from your house to a place you
> only know the
> address of, but not directions to, do you just drive
> down the street
> and keep turning left until you find the place?
> that'll work, but
> it's not terribly efficient. That's why we have
> maps....

No, you are missing the point, I know the address as
well as all possible pathes.
If I know there are four pathes lead to the
destination, but I do not know which of them have been
blocked for road work, why can't I just try one by
one?

>
> > If I want to a static LSP, I can just define the
> path
> > and bandwidth, if it can be accepted or not is
> another
> > story which depends on my estimation of the path
> > status. Is that how people calculate LSPs off-line
> in
> > stead of on-line?
>
> No....offline calculation defines explicit paths for
> LSPs to take.

That was what I said.

> You're talking about not propagating IGP information
> and letting the
> network magically find the right path. Bad idea;
> not only does it not
> scale, but even in small, infallable networks, you
> can still get into
> race conditions that cause (at the very least) more
> signalling churn.
>
> >
> > I think wether static is useful or not, it should
> be
> > up to the users, I guess that's why we still have
> > static and dynamic routing protocols.
> >
>
> With IOS, you can declare an explicit path, which is
> a path where
> every hop is defined. The explicit path is checked
> against the TE DB
> (excepting inter-area TE, which is a whole different
> conversation),
> and the signalling is sent out only if there's a
> reasonable chance of
> making it. Explicit can specify links and/or nodes,
> and unless you
> specify every link an LSP takes, you still need the
> IGP DB to figure
> things out. JUNOS does something very similar, if
> not exactly
> similar; explicit paths are a necessary piece of any
> TE
> implementation.

JUNOS has no-cspf, nobody is arguing how similar cisco
and juniper are when using TE information.

>
> Explicit makes more sense than no-cspf/verbatim.
> Flooding information
> in the IGP is necessary to deal with the reality
> that things are
> dynamic.

If I do not want to deal with the dynamic, why do I
have to listen to the noise. Sometimes, I do not care
about the dynamic.

Static unchecked paths are useful in
> corner cases, lab
> trials, and networks where you have more signalling
> than you'd have
> TE; in the case where you'd have more signalling
> than TE, I submit you
> don't need MPLS-TE at all.
>

Not with IOS.

>
>
>
> eric
>
> > Thanks
> > LU
> >
> >
> >
> >
> > --- Eric Osborne <eosborne@cisco.com> wrote:
> > > 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
> > > / \r
> > > D \r
> > > / \r
> > > / 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.
> > > >
>
=== message truncated ===

__________________________________________________
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