The MPLS WG Archive

[Rahul Aggarwal <rahul@redback.com>]

Kishan,
We have posted a new version of the spec to clarify Recovery 
Time usage further :

draft-ietf-mpls-ldp-restart-01.txt

Please see comments inline. 



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

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


We have removed this restriction from the spec. The following text from
the updated spec clarifies the usage of the Recovery Time at the 
non-restaring LSR :

Section 6.3

....

If the LSR re-establishes an LDP session with the neighbor within the
   lesser of the Restart Time and the local timer, and the LSR
   determines that the neighbor was not able to preserve its MPLS
   forwarding state, the LSR should immediately delete all the stale
   label-FEC bindings received from that neighbor. If the LSR determines
   that the neighbor was able to preserve its MPLS forwarding state (as
   was indicated by the non-zero Recovery Time advertised by the
   neighbor), the LSR should further keep the stale label-FEC bindings
   received from the neighbor for as long as the lesser of the Recovery
   Time, advertised by the neighbor, and a local configurable value.

   The LSR  should try to complete the exchange of its label mapping
   information with the neighbor within the Recovery Time, as specified
   in the Graceful Restart TLV received from the neighbor.      

....





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

The above issue doesn't arise anymore.

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

The idea is that all the non-restarting neighbors of a restaring LSR
should send label mappings to the restaring LSR before the Recovery
Time of the restarting LSR. This ensures a) that the restarting LSR
doesn't clean its stale label mappings before receiving updates and b) 
restarting LSR advertises its label mappings to its neighbors before
they clean up the label mappings learned from it. The  updated text
clarifies that in section 6.3. Hope this is clear and thanks for 
your comments. 



rahul


>Thanks,
>Kishan