The MPLS WG Archive

["Loa Andersson" <loa.andersson@nortelnetworks.com>]

Ramesh,

if you need to restore thousands or 10's or even 100's of thousands of
LSPs
it will certainly take time, even it is not as easy multiply the time
to set up one LSP with the number of LSPs. You have to do something
else,
e.g. do everything with one aaction.

/Loa

Ramesh Bhandari wrote:
> 
> Is the MPLS-based recovery scheme really scalable and conducive to fast
> restoration? Imagine a catastrophic failure like a fiber cut, in which
> thousands of LSP's are lost. Are these all resorable in the time frame (tens
> of ms) you are targeting?
> 
> Vishal.Sharma@tellabs.com wrote:
> 
> > Sergey,
> >
> > Thanks for your comments. My responses are inline.
> >
> > -Vishal
> >
> > > -----Original Message-----
> > > From: Sergey.Porotsky@ecitele.com [mailto:Sergey.Porotsky@ecitele.com]
> > > Sent: Wednesday, October 04, 2000 9:08 AM
> > > To: Vishal Sharma /trc,its
> > > Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt
> > >
> > >
> > > Hi Vishal,
> > Thanks for your answer. Please see my comments and further questions
> > below. With best regards, Sergey.
> >
> > <<snip>>
> >
> > >
> > >         1. In section 1.3 you have wrote :
> > > "I. MPLS-based recovery mechanisms should facilitate fast (10?s of
> > ms)
> > > recovery times."
> > > I agree, that it is necessary and it is possible to support
> > > for protection
> > > mechanisms. But is it really to support for rerouting
> > > schemes, in which the
> > > recovery path is not pre-established ?
> >
> > If I understand your question, you are asking whether the 10s of ms
> > objective holds also for the case where one uses reroute recovery.
> > Please note that we specify the 10s of ms as an _objective or goal_
> > for protection/recovery schemes, as opposed to making it a requirement.
> > Not all of the schemes may meet
> > this goal. In particular, reroute recovery schemes, where the
> > recovery path is not pre-established may take longer to recover
> > the working traffic.
> >
> > [Porotsky Sergey]  OK. I fully agree with you. But what do you think,
> > what are REALL requirements for rerouting scheme recovery time?
> >
> > I don't know that there is one answer to this question. The REAL
> > requirements
> > are obviously to get the recovery done as soon as possible. The actual
> > constraints
> > will be set by the application or provider that chooses to use reroute
> > recovery.
> > If reroute recovery depends on the convergence of the routing protocols
> > (as we
> > have assumed), then the time is theoretically indeterminate! In
> > practice, it may
> > happen in a few tens of milliseconds to a few minutes depending on the
> > network.
> >
> > >         3. In section 2.3.1 is written:
> > > "Rerouting - a recovery mechanism in which the recovery path or path
> > > segments are created dynamically after the detection of a fault on
> > the
> > > working path."
> > > Notion "rerouting" usually is used not only for recovery. For
> > example,
> > > ATMForum uses both notions hard-rerouting
> > > (break-before-make)for recovery
> > > and soft-rerouting (make-before-break)for re-arrangement.
> >
> > The draft, as written, does not, strictly speaking, have a notion of
> > "soft rerouting" in it, since we felt that that is not a notion that
> > is related
> > to protection or recovery. We were using "rerouting" always in the
> > context
> > of "hard rerouting." The notion of optimizing a path is partially
> > addressed in the draft under "dynamic re-routing cycle" in Section
> > 2.2.3.
> > Do you think that we need to talk about "soft rerouting" in the draft?
> >
> > [Porotsky Sergey]  NO. You are right, soft-rerouting is outscope of
> > your draft.
> >
> >
> > <<snip>>
> >
> > >         5. In section 3.6 is written:
> > > "Fault Notification: Protection switching relies...the node
> > > should send out
> > > a notification of the fault by transmitting a FIS to those of
> > > its upstream
> > > LSRs..."
> > > What we have to use for notification on the Rerouting Scheme
> > > - also FIS or
> > > other mechanisms?
> >
> > The implicit assumption in our description of the reroute scheme was
> > that the nodes affected by the fault learn of the fault via changes
> > to the routing updates. I suppose it is possible, even in the
> > reroute case, to have the affected nodes (PSLs) be notified
> > by some means other than routing. In that case, an FIS message
> > would be one way to do so.
> >
> > [Porotsky Sergey]  I think, that FIS using for on-demand rerouting has
> > many drawbacks:
> >
> > On-demand rerouting does not require very fast recovery. First, after
> > receiving Notification Message, the Source has to wait some hold-off
> > time to successfully finish Pre-Planned Rerouting. Second, On-Demand
> > Rerouting scheme requires some (not very low) time both for Backup
> > Route Selection and Backup LSP Setup (CAC, Bandwidth Reservation, etc.)
> >
> > FISs are sent by means of RNT using. If RNT is used for all LSPs (both
> > supported of protection and restoration), RNT tables will be too large
> > and so FIS messages for protection-LSP should not send for Source very
> > fast.
> >
> > In differ for Protection, Rerouting tools have to free all resources,
> > used for failed LSP.
> > Therefore, in any case it is necessary to send RSVP Tear-Down messages.
> > To use network resources more effectively and to improve Restoration
> > Ratio, it seems prove to release resources of failed LSPs before
> > establishment of backup LSPs.
> > What do you  think about RSVP Tear-Down Message using for failure
> > notification on rerouting schemes ?
> >
> > [Vishal]
> > I mentioned the FIS as one possibility to intimate the affected
> > source(s) of a
> > failure that requires their intervention. It does not mean that the
> > source(s) will
> > begin recovery immediately on receipt of the message. They will, as you
> > observe,
> > take care of planned rerouting before initiating reroute recovery. In
> > fact for
> > the reroute recovery to be reliable, they would have to wait for the
> > routing tables
> > to converge. (Otherwise, an alternate route picked by the source might
> > need to be
> > changed again once the tables converge.)
> >
> > As regards the explosion of the RNT tables, that would depend on the
> > number and
> > granularity of the LSPs in the network. In fact, that is why, our
> > assumption
> > was that re-route recovery works in conjunction with IP routing
> > protocols, and
> > has to wait for them to converge. In that case, no special notification
> > to
> > the sources is needed. They learn all they need to via the routing
> > updates.
> >
> > The RSVP Tear-Down message itself may not reach the desired source, if
> > the
> > routing tables haven't converged, so I am not sure that that would be a
> > useful way to intimate the source. (Note that the FIS message uses
> > a preconfigured reverse path, that does not depend on L3 routing
> > tables.)

-- 

Loa Andersson
Director Routing Architecture Lab, EMEA
St Eriksgatan 115A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: loa.andersson@nortelnetworks.com