Subject: Cisco SG16: Failover

From: Chip Sharp <[email-masked]>
Date: Tue, 25 Jan 2000 19:33:42 -0500

Section:        11.3, second paragraph
Category:       Editorial
Issue:          The draft text specifies that "Upon failover, the Primary MG sends
a ServiceChange command with a "Failover" method and a "MG Impending
Failure" reasons", however the "Failover" method is not described in
Section 7.2.8 on ServiceChange.
Proposal:       It is recommended that definition of the "Failover" method in
accordance with the text in Section 11.3 is added to Section 7.2.8.

v13 Status:     CLOSED. Failover method added in Section 7.2.8

Section:        11.4,
Category:       Open Issue
Issue:          The draft text does not specify what the MG does if it exhausts its
list of MGC's to try. This is a rather serious omission.
Discussion:     It is strongly recommended that additional work to define this
behaviour is done, and in a way that will ensure that failed MGC's will not
be swamped when they become reachable again (cf. Annex D.1.6).

v13 Status:     OPEN. No text changed.

Section:        11.4,
Category:       Editorial
Issue:          The draft text specifies that "It sends a ServiceChange command
with a "Failover" method and a "MG Impending Failure" reason", however the
"Failover" method is not described in Section 7.2.8 on ServiceChange.
Proposal:       It is recommended that definition of the "Failover" method in
accordance with the text in Section 11.4 is added to Section 7.2.8.

v13 Status:     CLOSED. Failover method added in Section 7.2.8

Section:        11.4, third paragraph
Category:       Technical
Issue:          The draft text specifies that "Accordingly, commands in progress
continue, transaction replies are sent to the new MGC, and the MG should
expect outstanding transaction replies from the new MGC". It is not clear
if messages are directed to the new MGC prior to the handoff being
confirmed by a new MGC or not. Also, it is not defined where retransmitted
transactionrequests are to be sent when a handover occurs until Annex
D.1.4. In order to support consistent and transparent handoff, the above
must be specified.
Proposal:       It is recommended, that messages are not directed to a new MGC
until that MGC has accepted the handover (it is not clear if this is in
line with specification in Annex D.1.4 or not). It also proposed, that
retransmitted transactionrequests are sent to the new MGC as specified in
Annex D.1.4.

v13 Status:     OPEN. No text changed.

Section:        D.1.4, last paragraph
Category:       Open Issue
Issue:  The draft text specifies that "It is however important that the
maximum delay of retransmissions be bounded. Prior to any retransmission,
it is checked that the time elapsed since the sending of the initial
datagram is no greater than T-MAX. If more than T-MAX time has elapsed, the
MG concludes that the MGC has failed, and it begins its recovery process.
The value T-MAX is related to the LONG- TIMER value; the LONG-TIMER value
is obtained by adding to T-MAX the maximum propagation delay in the
network". Since the recovery procedure is not initiated until T-MAX time
has passed, this implies, that the transaction in question will be lost
when the recovery procedure is initiated. This furthermore implies, that
transparent failover is not supported by the protocol which again will lead
to a degraded level of service

Proposal:       It is recommended, that work on a recovery procedure that will
enable transparent failover is done and included in the specification.

v13 Status:     OPEN. No text changed.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------