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

From: [email-masked]
Date: Mon, 18 Sep 2000 15:53:58 -0500

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

---

From: Porotsky Sergey <[email-masked]>
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 ?    

	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.
> --------------------------------------------------------------------------
> [email-masked]    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:	[email-masked] [SMTP:[email-masked]]
> Sent:	Mon September 18 2000 23:52
> To:	[email-masked]
> Subject:	Comments: draft-ietf-mpls-recovery-frmwork-00.txt
> 
> Hello All,
>