>I've seen both, at both large and small ISPs. In my experience, those
>that are familiar with doing offline calc for ATM VC placement are
>comfortable with doing for TE LSPs; those who come to MPLS-TE from an
>IP background, rather than an ATM one, are less comfortable with it
>and gravitate towards online placement. Online is less optimal than
>offline, but also less work; it becomes an economic decision, if not
>an emotional one, as to which method you use.
>
if you have real data, give a percentage would be great. but my
observation is that, for the guys who used to be old style
traffic-engineering, very hard to convince them the on-line
version. for the native IP/sonet lovers, they either don't need
TE, or they rather run LDP for the vpn stuff. Besides, for any
big network, they probably should run multiple areas/levels, for
that, mpls TE does not offer any meaningful solutions yet. Not
every one is happy with TE only in the core.
> >
> > >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.
> >
> > As in "old" TE with ATM backbones, you can know all the paths
> > to use. We don't need to debate which one is better here. You
> > can setup active and standby LSPs(which is the dynamic
> > portion here).
>
>My point in asking this question was that if you don't have TE info
>in the IGP and you send out an RSVP message, who in that setup knows
>there are four paths? How do you find the best one without crankback
>or explorer frames? This makes the third time I've asked that
>question, and nobody's answered it for me.
if they run offline calculation, they know exactly which path to
take. they have more information usually than the on-line TDB.
For most of the time, if i want to setup a lsp from DC to SanFrancisco,
i can either go through chicago the north path, or go through
huston the south path for example. there is not even a offline
calculation needed.
>
>It is possible that if you do all offline calculation, you need no TE
>extensions. But if you're solving a problem so complex that it has to
>be done offline, then you have enough TE tunnels and associated
>signalling that the IGP flooding of TE extensions is little more than
>background noise. And flooding the TE info in the IGP is still
>useful; if an explicitly placed LSP can't come up for some reason,
>it's better for the headend to know that it can't come up and to tell
>you so than to keep trying to signal an LSP that keeps failing.
that's true. but when its not needed, why waste bandwidth.
>
>What do standby LSPs have to do with dynamic?
>
> >
> >
> > >
> > >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.
> >
> >
> > Why it still "needs" a TE DB? why not offer a knob to let user to
> > decide if it needs to be turned off? to make this check by default
> > is completely OK, but "have to" check is not very reasonable.
> >
>
>I'm not saying that doing things without a TE DB is a bad idea; all
>I've been trying to point out is that it's not as useful as some folks
>seem to think, and in some circumstances (BW reservation) can be
>downright dangerous. I've asked for specific instances of when this
>would be useful, since I'm trying to understand if there really is a
>big hole there that I'm missing, and so far all I've got were two
>contradictory scenarios. Certainly an ERO-less CSPF is useful, but I
>want to understand the problem it would solve. Often, in discussion
>with customers, I've found that focusing on the problem, rather than
>what they've already decided was the solution, has led to a better
>solution to the actual problem.
>
>On the other hand, I fully recognize that knobs are always good. And
>it's not like we don't let you do enough dangerous stuff with IOS
>now.
>
> >
> > >
> > >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?
> >
> > its user's decision. Say I want to setup a static MPLS LSP to my
> > customer, I just want to set it up, there may only be one single
> > path, why should this TE DB be required? OK, in the backbone,
> > its not good to just set them up and assume they always work. but
> > rsvp hellos can be used to indicate status of the lsp, and active
> > and standby mechanism can be used here. Yes, its not "fast"
> > convergence, but also users need to make this decision.
> >
>
>1) are you really signalling TE LSPs to your customer? as in
>terminating RSVP signalling on a customer router? this brings up a
>whole host of other issues (security being number one) that also need
>to be solved; ERO-less signalling by itself is not the complete answer
>to this application.
i just picked this as a possible thing to do. as for issues, look
at the carrier to carrier mpls vpn, LDP is used across the AS
boundary, they would have the similar issues.
>
>2) RSVP hellos are only useful when you can't detect that the link has
>gone down via physical mechanisms (some FR links, etc), or you use
>hellos an order of magnitude faster than IGP hellos. RSVP hellos have
>nothing to do with ERO-less signalling; the discussion here is about
>getting rid of IGP, not getting rid of RSVP.
what i was saying was that, if you think the explicite lsp setup
is too "static", and it lacks of "dynamic" signalling to tell the
headend there is something broken in the middle of the lsp path;
then my answer is that, rsvp hello/refresh can be used to
propagate the link failure back to the headend, so we don't
blackhole the traffic down this broken lsp. I'm not saying to
get rid of IGP, only the TE info inside the IGP.
>
>3) I still don't see what active and standby have to do with it.
>IIRC, those weren't even part of the original discussion. If you're
>talking about merging LSP setup with fast reroute (we don't have
>"standby LSPs" in the sense of Path protection), then you're going to
>need IGP signalling for the protection LSPs, precisely because they
>need to deviate from the IGP shortest path in order to protect the
>resource in question.
No. same as above. since explicite lsp is a manually built path,
if the path is broken, the rsvp signalling should be propagate
back to the headend. Another lsp can be setup to take over the
traffic, thus standby lsp. The standby can either be a hotstandby,
or being setup explicitely after the active one is down.
I think cisco used to do some kind of standby lsp. juniper may
call it "secondary".
>
>If you do path protection (active and standby LSPs) in the network,
>and you don't use TE extensions and therefore no ERO, how do you
>ensure the standby LSP is routed diversely from the active LSP? What
>if a link or node goes down (or comes up) in the network - how do you
>guarantee mutual exclusion (or as close as possible) without a network
>topology?
again, if offline database is used, and the assumption is made that
if the chicago had a fiber cut, the chances of huston also has a
fibercut is very small. in the case both happen to have problem,
then, it does not matter its on-line or off-line, nothing will work.
>
> >
> > So I think it does not matter IOS is the source of the lsp tunnel,
> > or in the middle of the lsp transit, it should offer a mechanism to
> > allow user to config this "check TE DB" off if needed. Its very
> > useful, this is not just school project interest IHMO.
> >
>
>What is the problem you're trying to solve? If you want to do TE
>tunnels that terminate on customer routers, you need other stuff
>besides ERO-less signalling. In fact, you can do customer-terminating
>stuff and still have an ERO. Feel free to contact me offline if you
>don't want to discuss your network problems out in the open (same goes
>for anyone on this thread), but I'm still not seeing an actual problem
>that needs to be solved. I agree that the knob would be useful, but
>knobs stem from specific problem scenarios. All the stuff about
>tuning IGP timers, IOS scheduler, etc., etc., etc., came from specific
>requirements where those knobs helped solve a particular problem. All
>I'm asking for is the same justification here.
>
>FYI, at least in our implementation, it's only the headend that cares
>about whether TE extensions to IGP are required; the midpoints don't
>care, unless they see a loose subobject in an ERO.
I don't think this statement is true. try this:
A --> B ---> C ---> D
run A, B with TE in IGP, C and D without TE in IGP. setup an
explicite lsp from A to D. Assume A is a juniper, so it does not
care about C has TE or not. I think B will refuse to relay this
rsvp signalling to C since B does not have C's TE links in its TDB.
D is the only guy who does not need to run TE in IGP;-( the odd
thing to me is that, if A does not even care, why should B care?
-george
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:41 EDT