Subject: RE: I-D ACTION:draft-ietf-mpls-ldp-restart-00.txt

From: "HariKishan" <[email-masked]>
Date: Fri, 8 Mar 2002 11:37:47 -0800

Hello,
 I have the following questions on the draft.
 (Please help me in understanding them)

 In 6.3, "the amount of time the LSR should keep
 its stale label-FEC bindings is set to the
 lesser of the Restart time, as was advertised
 by the neighbor, and a local time."

 What is the significance of this local timer?
 If the LSR doesn't establish an LDP session
 with the neighbor within restart time ( as
 advertised by the neighbor), just deleting the
 stale bindings may work. I did not catch the
 point in keeping this period to
 Min(Restart time advt., by neighbor, Local timer).

 In 6.3
 " The Recovery Time that the LSR
   advertises to the neighbor should be greater than the Recovery Time
   the (restarting) neighbor advertised to the LSR."

  Why is this necessary?
  If it is necessary, How do you guarantee the above?

  It may not be possible to guarantee because of the
  following reasons.

  The non-restarting LSR may not know the recovery time that
  will be advertised by the restarting LSR.

  If the non-restarting LSR plays passive role, it may know
  the recovery time advertised by the Active(re-starting) LSR.

  If the non-restarting LSR plays active role, it will not
  know the recovery time that may advertised by the
  passive (re-starting) LSR.

Thanks,
Kishan

---------------------------------
HariKishan Desineni,
PU IP Access,
BU Multi-Service Networks,
Ericsson,
70 Castilian Drive,
Santa Barbara,
California - 93117
United States of America.

E-mail: [email-masked]
Office:(805) 562 6419
Cell:(805) 252 2641
Home:(805) 562 8841
Fax: (805) 685 4465

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Thursday, February 14, 2002 4:05 AM
> To: IETF-Announce:;
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-mpls-ldp-restart-00.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Multiprotocol Label
> Switching Working Group of the IETF.
>
> 	Title		: Graceful Restart Mechanism for LDP
> 	Author(s)	: M. Leelanivas, Y. Rekhter, R. Aggarwal
> 	Filename	: draft-ietf-mpls-ldp-restart-00.txt
> 	Pages		: 10
> 	Date		: 13-Feb-02
>
> This document describes a mechanism that helps to minimize the
> negative effects on MPLS traffic caused by LSR's control plane
> restart, and specifically by the restart of its LDP component, on
> LSRs that are capable of preserving the MPLS forwarding component
> across the restart.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-rest
art-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-ldp-restart-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-ldp-restart-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 10 Mar 2002 10:04:49 -0800

Kishan,

>  Min(Restart time advt., by neighbor, Local timer).

The LSR may want to impose a (configurable) upper bound on the
amount of time it is willing to retain the stale state. Local time
is a way to impose this upper bound.

>   passive (re-starting) LSR.

which suggests that the non-restarting LSR should play a passive role.

Yakov.

---

From: "HariKishan" <[email-masked]>
Date: Sun, 10 Mar 2002 17:34:16 -0800

Yakov,
	Thanks for some of the clarifications.
	Please see comments inline.

> is a way to impose this upper bound.
 
  OK. I got the point.

> which suggests that the non-restarting LSR should play a 
  
  This is equivalent to saying that re-starting LSR plays
  active role.  

  This causes the active/passive role determination procedure
  in the LDP RFC (RFC3036) to change. 

  [ Section 2.5.2 "Transport Connection Establishment" ]
  
  What happens if two adjacent LSRs restart and try to 
  re-establish the session? Both of them would try to play
  Active Roles ??

  One of my un-answered question was:-  Why is it necessary
  to have the Recovery Time advertised by the non-restarting
  LSR to be greater than the Recovery Time advertised 
  by the re-starting neighbor LSR?

Thanks,
Kishan