The MPLS WG Archive

[Porotsky Sergey <Sergey.Porotsky@ecitele.com>]

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 ?    

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

	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. 

	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
?

	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?


Regards, Sergey.
> --------------------------------------------------------------------------
> Sergey.Porotsky@ecitele.com    Tel. (972-3)926 1258
>                                                  Fax. (972-3)926 1630
>                                                  16 Martin Gehl St.,
> Sergey Porotsky                            P.O.B. 500,
> Transport Networks Division          Petach-Tikva 49104,
> ECI Telecom LTD                         Israel
> -------------------------------------------------------------------------
> -----Original Message-----
> From:	Vishal.Sharma@tellabs.com [SMTP:Vishal.Sharma@tellabs.com]
> Sent:	Mon September 18 2000 23:52
> To:	mpls@UU.NET
> Subject:	Comments: draft-ietf-mpls-recovery-frmwork-00.txt
> 
> Hello All,
> 
> A new version of the MPLS framework recovery document, which was 
> accepted as an MPLS
> WG document at Pittsburgh, is now available at the IETF drafts directory
> http://search.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-00.
> txt
> 
> At 
> Pittsburgh, we received comments from people who felt that certain parts
> of the document were unclear, and wanted us to provide clarifications.
> The decision then was to continue this on the mailing list. We now 
> invite
> comments from the mailing list on the current version of the draft,
> so that we may incorporate them in the next version of the document.
> 
> Thanks,
> -Vishal
> 
> *****************************************************************
> Vishal Sharma, Ph.D.  A small group of determined spirits with an
> Research Engineer     unquenchable thirst for their mission can  
>                       alter the course of history. --- Gandhi
> Tellabs Research Center                     
> One Kendall Square      Phone: (617).577.8760
> Bldg. 100, Suite 121      Fax: (617).494.0118
> Cambridge, MA 02139    e-mail: Vishal.Sharma@tellabs.com
> *****************************************************************