Subject: Re: [ANCP] Adjacency timer

From: "Sanjay Wadhwa" <[email-masked]>
Date: Thu, 10 Jul 2008 22:08:37 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Vitali Vinokour (vvinokou)
Sent: Thursday, May 22, 2008 3:24 PM
To: [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: "Vitali Vinokour (vvinokou)" <[email-masked]>
Date: Thu, 10 Jul 2008 23:34:43 -0400

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

> From: Sanjay Wadhwa [mailto:[email-masked]] 
> Sent: Thursday, July 10, 2008 10:09 PM
> To: Vitali Vinokour (vvinokou); [email-masked]
> 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 
> 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
> 
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vitali Vinokour (vvinokou)
> 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