Subject: RE: LSP Failure Notification

From: "Dekany, Steven" <[email-masked]>
Date: Fri, 20 Apr 2001 11:03:14 -0400

Hi Ramesh,

Yes, I have. The assumption that I made in my first email is, that I have
exhausted all back-up and LSP re-route options, at least temporarily. At the
moment there is no LSP available. What do SP's most often do in this case
with the incoming IP traffic? Signal back to source with Dest Unreachable?
Silently drop until a new LSP finally comes up? Light a red lamp in the NOC
signaling a NW outage or link failure? 

Best Regards,

Steven

-----Original Message-----
From: Ramesh Bhandari [mailto:[email-masked]]
Sent: Friday, April 20, 2001 10:00 AM
To: Dekany, Steven
Cc: Bora Akyol; [email-masked]
Subject: Re: LSP Failure Notification

Steven,

Have you considered phyiscally-disjoint pair of LSP's in the solution,
with one LSP as a backup so that if the primary path fails the affected
traffic can flow on the backup?

Ramesh

"Dekany, Steven" wrote:
> 
> Thank you Bora;
> 
> and thank you Haoxin and Giles.
> 
> Yes, best effort is kind of the expected "default" behavior. I just wonder
> that when we say that the IGP route will become the "next best route" what
> happens to my SLA with the customer - assuming that there is one in place?
I
> guess the underlying assumption is that I use MPLS in the core because I
> want to give something better than best effort service to my customer. Now
> that my LSP is broken and that I cannot setup another one - at least for
> while, in theory - if I use best effort only, I have basically violated my
> service level agreement with my customer. Should I not notify him somehow?
> Or this REALLY VERY IMPLEMENTATION SPECIFIC - read, either private
> information, or policy dependent?
> 
> Another theoretical question - how significant is usually the time delay
> between IGP's convergence and by the time RSVP-TE has found a new LSP? If
> that is a relatively short time, I may not care, but if it takes a few
tens
> of seconds or minutes, and I have a relatively high speed link to the LER,
> it may flood my network with unwanted IP traffic real badly too, causing
> another cascading TE problem for me potentially in the core.
> 
> Along the same line, if I have certain traffic parameter requirements for
my
> LSP - as required by my SLA - it is entirely possible that RSVP-TE may not
> find a suitable LSP and comes back with PathErr. Do I still fall back to
> forward best effort?
> 
> I wonder if there is any practical experience with this question, or IP
best
> effort is the generally implemented default.
> 
> Thank you again to all again, who kindly responded,
> 
> Best Regards,
> 
> Steven
> 
> 
> -----Original Message-----
> From: Bora Akyol [mailto:[email-masked]]
> Sent: Friday, April 20, 2001 9:00 AM
> To: Dekany, Steven
> Cc: [email-masked]
> Subject: Re: LSP Failure Notification
> 
> The tunnels are established using IGP reachability information. When the
> tunnel goes away, IGP route will become the next best route and traffic
> will be traveling via IP.
> 
> This may take a while, but until the head end realizes that the tunnel is
> down, there really is not much you can do. The packets will fall on the
> ground.
> 
> I believe G-MPLS defines a failure notification mechanism.
> 
> Bora
> 
> On Fri, 20 Apr 2001, Dekany, Steven wrote:
> 
> > Greetings;
> >
> > I am looking for help, with the following:
> >
> > Assume I have an MPLS Service Provider network, running RSVP-TE as a
> > signaling protocol. Customer sites are connected to my network via
various
> > IP only links - no MPLS.   Upon a LSP link failure in my core - assume
> that
> > I have exhausted all back-up, re-route etc., options and my LSP tunnel
is
> > still down - what happens to my incoming IP traffic at the ingress LER?
Is
> > there an ICMP message generated back to IP Source with "Destination
> > Unreachable? , or an SNMP Trap, or both? Or something else?
> >
> > (Or is this a dumb question, because I have not read the relevant
> draft...)
> >
> > Any help or pointers would be greatly appreciated.
> >
> > Thanks in advance,
> >
> >
> > Steven
> >

---

From: Ramesh Bhandari <[email-masked]>
Date: Fri, 20 Apr 2001 12:23:32 -0400

Steve,

Normally, if the customers's traffic is so critical, then one would (to
meet the SLA) assign a separate (or at least shared) backup path  for
this particluar LSP. If the network is properly designed and used, the
situation where no backup LSP is available, when the primary LSP fails,
should not arise. In the event a new service request comes in and a
backup cannot be found (and  reserved) due to bandwidth exhaustion or
for whatever reason, then the request (with protection LSP) should be
denied. If the customer agrees to an unprotected LSP servce, then
depending upon the SLA,  "best effort" service in the event of a
node/link failure could be provided. If the unprotected LSP service
cannot be provided also, then the request for this service is also
denied, and depending upon the SLA only "best effort" service may be
provided.

Ramesh