Subject: [ANCP] Fate of connection state after loss of synchronization detected

From: Tom Taylor <[email-masked]>
Date: Tue, 19 Apr 2011 13:35:24 -0400

The current text in the ANCP protocol draft says that if loss of 
synchronization is detected, all connection state is immediately cleaned 
up. I am wondering if this just slipped in without prper consideration. 
Section 11.4 of RFC 3292 says just the opposite, that connection state 
is held until resynchronization is achieved and then is handled 
according to the value of PFlag.

Which behaviour does the WG favour? The RFC 3292 behaviour seems to 
offer more flexibility and certainly a better subscriber experience, as 
I see it.

If there are no comments I propose that we update the document to use 
the RFC 3292 procedure.

Tom Taylor

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 21 Apr 2011 15:04:47 +0200

There is fundamental issue here:

- Keeping state after the loss of synch, does not guarantee that the info is
in any way accurate.
- There is no incremental update mechanism, ie The only update mechanism
currently is "send all" following a re-synch. Coincidentally, does the text
actually make that clear?
- Knowing via the Pflag that a connection is back up or a new connection is
made, would only be useful if we also knew whether any changes occurred in
the time the synch was down.

I suppose keeping the state and then having a full re-send by either side
could be an option.

-Woj.

On 19/04/2011 19:35, "Tom Taylor" <[email-masked]> wrote:

> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp

---

From: Tom Taylor <[email-masked]>
Date: Thu, 21 Apr 2011 10:05:28 -0400

What I had in mind when I suggested that holding state until contact 
with the peer is reestablished would be better for subscriber experience 
was a scenario where the NAS control application crashed. Subscribers 
could at least continue with their current IP-layer sessions until 
contact was re-established and the adjacency renegotiated. Maybe I'm 
unrealistic in my understanding of NAS function.

On 21/04/2011 9:04 AM, Wojciech Dec wrote:
> On 19/04/2011 19:35, "Tom Taylor"<[email-masked]>  wrote:
>

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 21 Apr 2011 17:06:38 +0200

On 21/04/2011 16:05, "Tom Taylor" <[email-masked]> wrote:

> Woj> Ok, I guess we need to be more precise in terms of what ³state² is being
> referred to. I tend to think of it in this context as ANCP-state such as
> line-synch-rates & characteristics, mcast bw info, mc-forwarding states, all
> not associated with any NAS data plane state.
> 
> -Woj.
>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 21 Apr 2011 11:59:39 -0400

I have multicast in mind, where both the AN and the NAS participate 
actively.

On 21/04/2011 11:06 AM, Wojciech Dec wrote:
>
>
>
> On 21/04/2011 16:05, "Tom Taylor"<[email-masked]>  wrote:
>
>> line-synch-rates&  characteristics, mcast bw info, mc-forwarding states, all

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 21 Apr 2011 18:03:18 +0200

On 21/04/2011 17:59, "Tom Taylor" <[email-masked]> wrote:

> Woj> Ok, but ANCP derived mcast state is not data-plane related  that¹s all
> still there (or not) as per IGMP/whatever other signalling.
> 
> In any case, we have a decision, in terms of which of two evils is better
> following a loss of synch:
> 1. keep ancp state (even though it may be stale)
> 2. clean ancp state (to applications this one would show that something is
> amiss).

-Woj.
>>>>> >>>> - Keeping state after the loss of synch, does not guarantee that the
info
>>>> >>> is