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

From: Eric Osborne (eosborne@cisco.com)
Date: Fri Apr 12 2002 - 23:13:47 EDT


On Fri, Apr 12, 2002 at 01:48:40PM -0700, LU wrote:
>
> --- 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.

Roads that are not wide enough can be considered not to exist.

>
> >
> > 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?

RSVP; see RFC3209.

>
> 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.
>

True.

> >
> > 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?

How does the headend know there are four paths? You can't use the IGP
database because, as you point out above, you don't need to use
MPLS-TE across the entire network, only in some places. Show me a way
to do this without resorting to explorer packets or crankback.

>
>
> >
> > > 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.
>

I think you've missed the difference between verbatim and explicit.
Explicit still needs a TE DB, and will check the path against the TE
DB before signalling.

> > 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.
>

You still haven't answered the question I've been asking - if you
configure a static path, using no dynamic topology information
whatsoever, what do you do when a link or node in your static path
goes down?

> 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.

Now you make no sense. I'm not arguing that there are no cases where
ERO-less signalling is bad, just that there are very few. If you need
MPLS-TE, you need MPLS-TE; who you get it from is another matter.

I ask again - do you have a specific need for ERO-less signalling?
All you've done is say that there might be a reason why you'd want it,
but your reasons seem to contradict each other (you want to use it in
a small portion of your network, but don't want a way to tell the
network which portions do MPLS-TE and which don't). I will agree that
having ERO-less signalling is not inherently harmful, however. My
only argument is that it's not all that useful, and certainly not in
any of the cases you've brought up.

  

eric

>
>
> >
> >
> >
> > 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:11 EDT