The MPLS WG Archive

[prabakarts@future.futsoft.com]

Dear MPLS-WG,

I have the following doubts in MPLS LDP Graceful restart :

I was searching in the mailing list about this topic, but, I am not able
to find out the relevant info, If this question has been already raised
and discussed in MPLS-WG, I would greatly appreciate if you could show the
pointers.

1. In RFC 3479 states, In section 8.2.  FT Session TLV,

" FT Reconnection Timeout
      If the S bit or C bit in the FT Flags field is set, this indicates
      the period of time the sending LSR will preserve state and
      resources for FT Labels exchanged on the previous instantiation of
      an FT LDP session that has recently failed.  The timeout is
      encoded as a 32-bit unsigned integer number of milliseconds.

      A value of zero in this field means that the sending LSR will
      preserve state and resources indefinitely. "


2. In RFC 3478 states, In section 2,

"Setting the FT Reconnect Timeout to 0 indicates that the sender of
   the TLV will not preserve its forwarding state across the restart,
   yet the sender supports the procedures, defined in Section 3.3,
   "Restart of LDP communication with a neighbor LSR" of this document,
   and therefore could take advantage if its neighbor to preserve its
   forwarding state across the restart."

Question:
=========
In the above point 1, as per RFC 3479, "a value of zero in the FT
Reconnect timeout means that the sending LSR will preserve state and
resrouces indefinitely" and as in point 2, as per RFC 3478, "if FT
Reconnect Timeout is zero, then the sender of the TLV will not preserve
its forwarding state across the restart"

To me both the RFC 3478 and RFC 3479 conflicts with each other in the
above statements, I would like to know which one is appropriate for the
LDP graceful restart and what is the industry prefered one and is there
anything finalysed in the mailing list/MPLS-WG about this, authors please
clarify me regarding this?

Thanks in advance,
Best regards,
Prabakaran T.S.
Future Communications Software,
a Flextronics company.




***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls