Subject: Re: Cisco SG16: Failover

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 3 Feb 2000 16:09:11 -0500

Looks like an useful clarification to the existing text.

> -----Original Message-----
> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Tuesday, January 25, 2000 7:34 PM
        [[TomT]]  snip
>
> 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.
>
> --------------------------------------------------

---

From: Chip Sharp <[email-masked]>
Date: Fri, 4 Feb 2000 00:10:39 -0500

>Looks like an useful clarification to the existing text.
OK. For completeness all the relevant issues with a status update is 
included below. Please note the new issue.
>
>-----Original Message-----  From:  Chip Sharp 
>[SMTP:[email-masked]]  Sent:  Tuesday, January 25, 2000 7:34 
>PM  [[TomT]]  snip
Section:         11.3 (Failure of an MG), second paragraph
Category:     Editorial
Issue no.:     12.32
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 be added to Section 7.2.8.
Status:
     v13: CLOSED. Failover method added in Section 7.2.8

Section:         11.4 (Failure of an MGC),
Category:     Editorial
Issue no.:     12.33
Issue:          The draft text specifies that “It sends a ServiceChange 
command with a “Failover” method and a “MGC 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.
Status:
     v13: CLOSED. Failover method added in Section 7.2.8

Section:         11.4 (Failure of an MGC),
Category:     Open Issue
Issue no.:     12.34
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 be 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).
Status:
     v13: OPEN. No text changed.
     v14: SEMI-CLOSED. A mechanism has been defined, however it proposed to 
extend it with specifying, that a method of “Disconnected” is used in this 
case (at least if service is not restored within T-MAX time, cf. issue 12.50).

>    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.
>
v14: CLOSED. Text has been updated.

Section:         11.5 (Failure of an MGC), second paragraph
Category:     Technical, Editorial
Issue no.:     14.10
Issue:          The draft text specifies that when the MGC sends a 
“Handoff” message to the MG, “The MG should send a ServiceChange message 
with a “Failover” method and a MGC directed change” reason to the 
designated MGC”. Cf. issue 14.7, it would seem more consistent if the MG 
sent a “Handoff” rather than a “Failover” to the (new) MGC in response to a 
handoff from the old MGC
Proposal:     It is proposed that the sentence is modified as described above.
Status:

Section:         D.1.4 (Provisional Responses), last paragraph
Category:     Open Issue
Issue no.:     12.50
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- IMER 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 be 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 be done and included in the specification.
Status:
     v13: OPEN. No text changed.
     v14: OPEN (now Section D.1.5). The sentence “When the MG establishes a 
new control associate, it can retransmit to the new MGC” has been added. 
However, this particular sentence violates the basis of T-MAX and may 
consequently lead to the same transaction being executed twice (e.g. if the 
original request was received and executed, but the response lost – after 
LONG-TIMER the fact that the transaction was executed will be lost and a 
subsequent retransmission will lead to the transaction being executed 
again). It seems, that the only safe solution within the current framework 
is to discard the transaction and issue a “Disconnected” ServiceChange to 
the other entity.
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.          	
--------------------------------------------------

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 12:48:16 -0500

I don't think changing the restart mechanism to "Disconnected" is
warranted.  There never was an MG/MGC relationship established,
so there is nothing to be disconnected.  Disconnected implies
something was there, that isn't now, and in particular, implementations that
keep stable state may get confused.

I think I agree with 12.50, but I'm going to mull it over a little
more.

Brian

> From: Chip Sharp [mailto:[email-masked]]
> Sent: Friday, February 04, 2000 12:11 AM
> To: [email-masked]
> Subject: Re: Cisco SG16: Failover
>
>
> 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
> Proposal:     It is recommended that definition of the
> "Failover" method in
> Issue:          The draft text specifies that "It sends a
> ServiceChange
> command with a "Failover" method and a "MGC 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
> exhausts its list of MGC's to try. This is a rather serious omission.
> behaviour be done, and in a way that will ensure that failed
> MGC's will not
> extend it with specifying, that a method of "Disconnected" is
> used in this
> "Handoff" message to the MG, "The MG should send a
> ServiceChange message
> with a "Failover" method and a MGC directed change" reason to the
> designated MGC". Cf. issue 14.7, it would seem more
> consistent if the MG
> sent a "Handoff" rather than a "Failover" to the (new) MGC in
> response to a
> handoff from the old MGC
> Issue:         The draft text specifies that "It is however
> important that
> delay in the network". Since the recovery procedure is not
> initiated until
>      v14: OPEN (now Section D.1.5). The sentence "When the MG
> establishes a
> new control associate, it can retransmit to the new MGC" has
> been added.
> original request was received and executed, but the response
> lost - after
> is to discard the transaction and issue a "Disconnected"
> ServiceChange to
> the other entity.