Subject: [ANCP] Graceful restart for MC extension

From: Alexandre Cassen <[email-masked]>
Date: Mon, 23 Mar 2009 13:47:39 +0100

Hi,

Having the ability to manage AN multicast membership from NAS is a great
flexibility. In such an environnement a NAS manage a lot of AN. Using
ANCP replication control message MUST be reliable in respect of service
it provides. I mean, if we are using ANCP replication control message to
perform IPTV zapping there is an important need to have a fallback
adjacency or other kind of mecanism to provide the best end user
experience possible especially if active NAS crash down.

If a NAS is managing 100 AN, each AN hosting lot of customers then NAS
crash will directly impact end user experience by disabling service.
Plus, it will provide an 'avalanche' side effect, especially for IPTV
zapping use-case. The very first action end-user will have, when zapping
is not working, is to RETRY... it generates TONES of retry which will
lead to a mass-flood when zapping is back to life (secondary NAS
takeover). IMHO, there is an IMPORTANT need to have a transparent and
rapid fallback mecanism in order to protect end-user experience and any
kind of side-effect.

A simple approach would be to define a fallback adjacency as introduced
in : http://www.ietf.org/mail-archive/web/ancp/current/msg00787.html

Another approach would be to simply remove the non-correlation between
layer4 and ANCP. IMHO, if something is wired at layer4 side then ANCP
must be sync with this. If TCP RST is received (or any other issue) then
ANCP is broken and not working. Why waiting adj timer expiration at AN
side to bring up a new adjacency ? Layer4 broken could be put into
loss-of-synchronization equation.

regards,
Alexandre