On Sun, Apr 14, 2002 at 12:58:18AM +0000, George Sheng wrote:
>
> Very interesting watching this thread, I think LU had a point here
> in the world of "dynamic everything". There were lots of interest
> from ISPs to do on-line cspf MPLS-TEs, I know two "big" ISPs tried
> this(one presented on last nanog i think). I also know some ISPs
> are using off-line calculations and then set explicitely the MPLS
> LSPs. I personally don't see more ISPs joining this on-line cspf
> TE camp.
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.
>
> >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.
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.
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.
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.
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.
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?
>
> 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.
eric
> thanks.
> george
>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:11 EDT