Re: Static LSP Configuration

[Sudheer Dharanikota <sudheer@nayna.com>]

Hi Ramesh:



"Nagarajan, Ramesh (Ramesh)" wrote:

> Sudheer, Shahram,
>
> I agree. *Fast* failure detection and reporting are challenging issues even
> when we consider physical layer failures (fiber cut etc.,) only. If you
> throw in soft failures of many kinds it becomes even more challenging.
> This was one of the motivations, among many others, in developing a
> restoration scheme/proposal (link below for convenience) which provides
> broad coverage for many failures without requiring failure detection and
> reporting. This will work across the recent L2/L1 technologies that you
> refer to which lack either proper failure detection and/or reporting.
>
> ramesh.
>
> http://www.ietf.org/internet-drafts/draft-nagarajan-ccamp-mpls-packet-protec
> tion-00.txt
>

Although I agree that 1+1 mechanisms may solve (to be precise avoid)
such problems, they are very resource intensive. Also most of the
data applications do not need the recovery times that you can support
by 1+1. In my opinion, the challenge is to support less resource intensive
but reasinably faster restoration times for data applications by reusing
the under-lying technologies.

Regards,

sudheer

>
> ----------------------------------------------------------------------------
> --------------------------------------------------
> Room 3M-335, Bell labs
> Tel: 732-949-2761
> 101 Crawfords Corner Road
> Fax: 732-834-5906
> Holmdel, NJ 07733.
> e-mail: rameshn@lucent.com.
> ----------------------------------------------------------------------------
> ---------------------------------------------------
>
> > ----------
> > From:         Sudheer Dharanikota[SMTP:sudheer@nayna.com]
> > Sent:         Monday, May 06, 2002 5:27 PM
> > To:   Shahram Davari
> > Cc:   'curtis@fictitious.org'; Gary Tam; Ajay Simha; Ron Bonica; Brijesh
> > Kumar; mpls@UU.NET; CCAMP WG
> > Subject:      Re: Static LSP Configuration
> >
> >
> >
> > Shahram Davari wrote:
> >
> > > Curtis,
> > >
> > > > -----Original Message-----
> > > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> > > > Sent: Monday, May 06, 2002 4:31 PM
> > > > To: Sudheer Dharanikota
> > > > Cc: Gary Tam; Ajay Simha; curtis@fictitious.org; Ron Bonica; Brijesh
> > > > Kumar; 'Curtis Villamizar '; mpls@UU.NET; CCAMP WG
> > > > Subject: Re: Static LSP Configuration
> > > >
> > > >
> > > >
> > > > In message <3CD6C43C.94BACCEE@nayna.com>, Sudheer Dharanikota writes:
> > > > >
> > > > > Transport networks are *built* to provide 50 msec recovery
> > > > > times (e.g., rings, span, 1+1 etc). Hence a failures are
> > > > scoped to be
> > > > > within a domain (typically a ring or a span or in the worst case
> > > > > end-to-end[1+1 case]).  Excluding failure detection time in this
> > > > > 50 msec (taking from SONET knowledge), failure reporting
> > > > > and recovery should take 50 msec. Obviously this cannot
> > > > >  be done with OSS intervention. One can use SONET's
> > > > > inband signaling mechanisms for failure reporting or use
> > > > > *directed notification* mechanisms such as the ones proposed
> > > > > for signaling protocols. Note that if we assume a ring topology then
> > > > > the messages are only one hop away (with the assumption that
> > > > > only the DCS are the intelligent devices). So your worry of 5-10
> > > > > hop path is not valid in my opinion.
> > > > >
> > > > > Regards,
> > > > >
> > > > > sudheer
> > > >
> > > >
> > > > The discussion was about MPLS but an underlying assumption seemded to
> > > > enter into the thread with that last email that either APS was running
> > > > under MPLS or L2 was the application and APS was running over MPLS
> > > > provided over multiple end to end L2 tunnels.
> > > >
> > > > I don't know of anyone doing SONET APS over the L2 tunnels of an MPLS
> > > > backbone.
> > > >
> > > > I do know of providers who want to eliminate the APS on the sonet
> > > > links under their MPLS network cutting some costs significantly (but
> > > > with all things considered, not in half).
> > >
> > > What mechanism will they use to detect the failure then?
> >
> > With most of the *recent* L2/L1 technologies, failure dection is not the
> > only problem.
> > Without APS-like mechanisms (sub-second) failure reporting is also a major
> > problem.
> > In my opinion, for the sake of the underlying technologies which does not
> > have
> > APS-like reporting mechanisms, we need to optimize our signaling protocols
> > and propose sensible control plane topologies.
> >
> > Regards,
> >
> > sudheer
> >
> > >
> > >
> > > -Shahram
> > >
> > >   MPLS restoration needs to
> > > > work quite well to do this and still meet SLAs and carrying L2 service
> > > > is even more demanding.
> > > >
> > > > Curtis
> > > >
> >
> >