The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] MPLS LDP Graceful restart doubts - FT Reconnection Timeout
Thanks for the reply and appreciate for the good clarification Adrian. Now I am clarified well. Best regards, Prabakaran T.S. > Good morning Prabakaran, > > Your issue hangs on the word "if". > > In 3479 the interpretation of the FT Reconnection Timeout you quote says > "if the S bit or C bit is set". These bits are only relevant to the > procedures in 3479. > > The L bit indicates the choice between 3478 and 3479. > > In section 8.2 of 3479 you will find... > > It is not valid for both the L and either the S or C bits to be > set to 1. > > Thus, there is no conflict (only peace and harmony) between the RFCs. > > If you want to compare and contrast the two approaches you may look at RFC > 3612. > As to which is more prevalent in "the industry", I will let the industry > comment. > > I hope that clarifies. > Regards, > Adrian > > ----- Original Message ----- > From: <prabakarts@future.futsoft.com> > To: <mpls@ietf.org> > Cc: <psampath@avici.com> > Sent: Thursday, April 21, 2005 1:58 AM > Subject: [mpls] MPLS LDP Graceful restart doubts - FT Reconnection Timeout > > >> 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 >> >> > *************************************************************************** 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
|
|