The MPLS WG Archive

[Vishal.Sharma@tellabs.com]

Hi Sergey,

I apologize for the delayed response. Our company email server
was having some problems the week you sent this email, so 
I never received a copy of it directly. It was only this
weekend, while reviewing the MPLS list archives, that I came
across it, so I am responding at the first opportunity.

Anyway, thanks very much for your comments and observations.
Please see my comments below.

Regards,

-Vishal

> -----Original Message-----

> Comments: draft-ietf-mpls-recovery-frmwork-00.txt
> 
>      From: Porotsky Sergey <Sergey.Porotsky@ecitele.com> 
>      Date: Thu, 21 Sep 2000 15:58:25 +0300 
> 
> 
> Hello, Vishal. 
> Thanks for this draft, it gets us very good initial point to create
> protection/restoration schemes. 
> I have a few comments and questions.
> 
>         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.
 
> 
>         2. In section 2.1.1 is written :
> "In terms of the principles defined in section 3, reroute 
> recovery employs
> paths established-on-demand with resources reserved-on-demand."
> I think, that for pre-planned rerouting techniques we can use two
> alternatives:
> *       Only recovery route is selected, resource reservation 
> is absent;
> *       Recovery route is selected and resources are 
> semi-dedicated (e.g.,
> bandwidth is pre-planned assigned and shared for several 
> recovery paths). 

You are correct. This is something we realized before the last
IETF but did not incorporate into the draft yet. In fact, the latter
case is particularly important in the case of generalized MPLS (GMPLS),
where resources for protection paths in a SONET or an optical 
cross-connect may be
reserved, but the actual cross-connections may not be made until
a fault occurs, and it becomes known which of the working paths sharing
the protection resources actually has the fault.

We will incorporate this in the next revision. 

>         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?
 
>         4.In section 3.3 is written:
> "Reserved-on-Demand:This option may apply either to rerouting or to
> protection switching. Here a recovery path reserves the 
> required resources
> after a failure..."
> Is it really for protection scheme to reserve resources after 
> failure? If I
> understand right, for this scheme the aim of the recovery LSP 
> establishment
> before failure is only label assignments. In this case after 
> failure  for
> early established recovery LSP it is necessary once more to 
> perform Setup by
> means of LDP/RSVP signalling, isn't it? Moreover -  this 
> scheme, in differ
> of pre-reserved protection, can't guarantee success of this 
> second Setup.
> What is significant difference and advantage of this scheme 
> from re-routing ?

The scheme referred to above is what you have earlier called:
>*       Only recovery route is selected, resource reservation 
> is absent;

The advantage of such a scheme over rerouting is that the recovery
route can be selected a priori by on-line or off-line algorithms
and, as you observe, label allocation can be also done along the 
recovery
route (although it may not be), which would not be possible in a pure 
rerouting scenario.

Also, in the above scheme, since the backup route is selected before
hand, it can be done more carefully than might be possible in a 
rerouting scenario. The only thing that remains upon the occurrence
of a fault is to use signaling to reserve resources along the path.
If the backup route calculation is a time consuming exercise (which
it can be in a mesh network) this scheme can be faster than pure
rerouting. In fact, pure rerouting may be forced, due to time
constraints, to simply resort to using hop-by-hop routing to find
the protection path, which may not be good or optimal.

Of course, if one argues that in the "rerouting" case also, one will
run the same path computation algorithms as in the protection switching
case, and make a resource reservation along an optimal backup path, then
the first scheme may not offer any advantage over the reroute case.


> 
>         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.