Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt

From: [email-masked]
Date: Wed, 4 Oct 2000 16:21:02 -0500

Sergey,

Thanks for your comments. My responses are inline.

-Vishal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 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.)

---

From: Ramesh Bhandari <[email-masked]>
Date: Thu, 05 Oct 2000 11:03:12 -0400

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?

---

From: "Loa Andersson" <[email-masked]>
Date: Thu, 05 Oct 2000 18:04:03 +0200

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

-- 

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: [email-masked]