The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Mar> msg00086



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: "HariKishan" <harikishan.desineni@ericsson.com>
  • Date: Sun, 10 Mar 2002 17:34:16 -0800
  • Cc: <manoj@juniper.net>, <rahul@redback.com>, <mpls@UU.NET>, <afarrel@movaz.com>
  • Importance: Normal
  • X-Scanned-By: MIMEDefang 2.1

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

> 
> Kishan,
> 
> > 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).
> 
> 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.
> 
 
  OK. I got the point.


> >  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.
> 
> which suggests that the non-restarting LSR should play a 
> passive role.
  
  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

> 
> Yakov.