Subject: Re: LSP Failure Notification

From: Ramesh Bhandari <[email-masked]>
Date: Fri, 20 Apr 2001 15:58:00 -0400

For completeness, I might add that for calculation of
physically-disjoint paths incorporating SRLG's, I have a book:
"Survivable Networks: Algorithms for Diverse Routing", Kluwer Academic
Publishers (1999).

Ramesh Bhandari wrote:
> 
> Steven,
> 
> I might not still be answering your questions, but following are my
> comments:
> 
> While leasing dark fiber, two cases arise:
> 
> 1) The lessor guarantees diversely routed fibers (no sheath
> commonality)for different pairs of nodes in the network, in which case
> no problem should arise, assuming the lessor indeed honestly upholds the
> diversity part of the agreement.
> 
> 2) The lessor provides information on the fiber routes leased, and one
> then determines the SRLG's and computes the physically-diverse routes
> for the given pairs of nodes. If the lessor does not provide this
> information because of the proprietary nature, then of course, one
> option is to not to lease dark fiber for diversity purposes, and the
> other is to simply run the risk of losing both the paths when a sheath
> is cut, which is what I believe you are concerned with. In this latter
> event, you ares stuck as you have described.
> 
> Ramesh
> 
> 
> 
> "Dekany, Steven" wrote:
> >
> > Ramesh,
> >
> > See comments inline,
> >
> > Thanks again,
> >
> > Steven
> >
> > -----Original Message-----
> > From: Ramesh Bhandari [mailto:[email-masked]]
> > Sent: Friday, April 20, 2001 11:24 AM
> > To: Dekany, Steven
> > Cc: Ramesh Bhandari; Bora Akyol; [email-masked]
> > Subject: Re: LSP Failure Notification
> >
> > 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.
> >
> > *       The question is, what do I do if it still does? Example: My backup
> > LSP is running over a diverse fiber route but without me knowing about it,
> > the two fibers may still share the same sheath. Construction, backhoe error
> > etc., I am leasing dark fiber. So now I am stuck. There may still be an IP
> > hop by hp route available via Timbuktu though...
> >
> > *       I guess I am interested to find out if there is any "standard"
> > error signaling used somehow back to the source, either recommended by any
> > of the standards or  implemented as a matter of practice by a SP, in case my
> > LSP tunnel is hopelessly lost and I still have IP traffic coming in to my
> > ingress LER.
> >
> > *       I am not sure if Giles' comment applies to ATM LSR's only. What does
> > BGP have to do with the original question? Are you suggesting to use BGP in
> > case of LSP failures?  I know, that may be a backup safety net for some SP's
> > running VPN's, but I am not running VPN's in this particular situation, this
> > is only a "straight" or - crooked - LSP. BTW, for the record, Marconi does
> > have BGP ...
> >
> > 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
> >
> > "Dekany, Steven" wrote:
> > >
> > > 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 15:37:08 -0400

Steven,

Ramesh

---

From: "Dekany, Steven" <[email-masked]>
Date: Fri, 20 Apr 2001 12:45:39 -0400

Ramesh,

See comments inline,

Thanks again,

Steven

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

Steve,

Ramesh

the
NOC
wonder
what
place?
Now
my
somehow?
If
LER,
for
not
is
LER?