[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANCP] Adjacency timer

Sanjay,

Thanks for the detailed response. Short term, I think option 2 is the
most sensible. Longer term, I see value in defining a mechanism for
timer value renegotiation without bringing a session down. Divergence
from GSMP should not be an issue here; ANCP is no longer a GSMP
extension, it is a separate protocol that happens to reuse chunks of
GSMP functionality.

Vitali

> -----Original Message-----
> From: Sanjay Wadhwa [mailto:swadhwa at juniper.net] 
> Sent: Thursday, July 10, 2008 10:09 PM
> To: Vitali Vinokour (vvinokou); ancp at ietf.org
> Subject: RE: [ANCP] Adjacency timer
> 
> Hi Vitali
>   You raise a valid question. Handling of a change in timer 
> value in adjacency messages is not specified. Some possible 
> options are:
> 
> 1. Allow dynamic changes in timer value without bringing down 
> the adjacency. ANCP draft calls for timer values to be 
> configurable, and explicitly allows for asymmetric timer 
> values between peers. This makes it possible for graceful 
> handling of timer changes without bringing down the session. 
> However, allowing change in the timer value for an active 
> session diverges from GSMP RFC.
> 
> 2. Ignore timer field in subsequent messages after the initial SYN.
> Optionally, the change in timer value from the one received 
> in initial SYN can be detected and logged as an error, but 
> the adjacency messages with the changed timer value could be 
> processed normally.
> 
> 3. Consider the message with a changed timer value invalid 
> and ignore the message. However, ignoring periodic ACK 
> messages with changed time value will eventually bring down 
> the session. 
> 
> 4. Log an error and bring down the session if you observe a 
> changed timer value.
> 
> Options 1 and 2 seem more reasonable. I do see some value in 
> option 1 i.e. in allowing for dynamic changes in the timer 
> value (e.g. if the controller is busy, it could temporarily 
> advertise a higher value to the peer). However, option 2 is 
> simpler and more inline with GSMP RFC.
> Thoughts?
> 
> Thanks
> -Sanjay
> 
> 
> -----Original Message-----
> From: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On 
> Behalf Of Vitali Vinokour (vvinokou)
> Sent: Thursday, May 22, 2008 3:24 PM
> To: ancp at ietf.org
> Subject: [ANCP] Adjacency timer
> 
> Hello,
> 
> GSMP rfc specifies that "The Timer field is used to inform 
> the receiver of the timer value used in the adjacency 
> protocol of the sender.  The timer specifies the nominal time 
> between periodic adjacency protocol messages.  It is a 
> constant for the duration of a GSMP session."
> 
> However, Timer field is present in all adjacency protocol 
> messages. Is the receiver expected to cache the remote timer 
> value from the very first SYN and ignore Timer field in all 
> subsequent messages? Or is the expected behavior to match the 
> Timer field in each message to the initial value and consider 
> invalid all messages whith mismatching values?  Neither GSMP 
> rfc nor ANCP draft specify the behavior.
> 
> Thanks,
> Vitali
> _______________________________________________
> ANCP mailing list
> ANCP at ietf.org
> https://www.ietf.org/mailman/listinfo/ancp
> 
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp


der: ancp-bounces at ietf.org
Errors-To: ancp-bounces at ietf.org

Sanjay,

Thanks for the detailed response. Short term, I think option 2 is the
most sensible. Longer term, I see value in defining a mechanism for
timer value renegotiation without bringing a session down. Divergence
from GSMP should not be an issue here; ANCP is no longer a GSMP
extension, it is a separate protocol that happens to reuse chunks of
GSMP functionality.

Vitali

> -----Original Message-----
> From: Sanjay Wadhwa [mailto:swadhwa at juniper.net] 
> Sent: Thursday, July 10, 2008 10:09 PM
> To: Vitali Vinokour (vvinokou); ancp at ietf.org
> Subject: RE: [ANCP] Adjacency timer
> 
> Hi Vitali
>   You raise a valid question. Handling of a change in timer 
> value in adjacency messages is not specified. Some possible 
> options are:
> 
> 1. Allow dynamic changes in timer value without bringing down 
> the adjacency. ANCP draft calls for timer values to be 
> configurable, and explicitly allows for asymmetric timer 
> values between peers. This makes it possible for graceful 
> handling of timer changes without bringing down the session. 
> However, allowing change in the timer value for an active 
> session diverges from GSMP RFC.
> 
> 2. Ignore timer field in subsequent messages after the initial SYN.
> Optionally, the change in timer value from the one received 
> in initial SYN can be detected and logged as an error, but 
> the adjacency messages with the changed timer value could be 
> processed normally.
> 
> 3. Consider the message with a changed timer value invalid 
> and ignore the message. However, ignoring periodic ACK 
> messages with changed time value will eventually bring down 
> the session. 
> 
> 4. Log an error and bring down the session if you observe a 
> changed timer value.
> 
> Options 1 and 2 seem more reasonable. I do see some value in 
> option 1 i.e. in allowing for dynamic changes in the timer 
> value (e.g. if the controller is busy, it could temporarily 
> advertise a higher value to the peer). However, option 2 is 
> simpler and more inline with GSMP RFC.
> Thoughts?
> 
> Thanks
> -Sanjay
> 
> 
> -----Original Message-----
> From: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On 
> Behalf Of Vitali Vinokour (vvinokou)
> Sent: Thursday, May 22, 2008 3:24 PM
> To: ancp at ietf.org
> Subject: [ANCP] Adjacency timer
> 
> Hello,
> 
> GSMP rfc specifies that "The Timer field is used to inform 
> the receiver of the timer value used in the adjacency 
> protocol of the sender.  The timer specifies the nominal time 
> between periodic adjacency protocol messages.  It is a 
> constant for the duration of a GSMP session."
> 
> However, Timer field is present in all adjacency protocol 
> messages. Is the receiver expected to cache the remote timer 
> value from the very first SYN and ignore Timer field in all 
> subsequent messages? Or is the expected behavior to match the 
> Timer field in each message to the initial value and consider 
> invalid all messages whith mismatching values?  Neither GSMP 
> rfc nor ANCP draft specify the behavior.
> 
> Thanks,
> Vitali
> _______________________________________________
> ANCP mailing list
> ANCP at ietf.org
> https://www.ietf.org/mailman/listinfo/ancp
> 
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp