Subject: Re: Cisco SG16: Service Change

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 2 Feb 2000 20:51:29 -0600

Comments below.

> -----Original Message-----
> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Tuesday, January 25, 2000 7:55 PM
        [[TomT]]  snip
>
> Section:        11.2
> Category:       Technical
> Issue:          When a gateway starts, it generates a restart
> ServiceChange
> to the MGC. If the MGC's response to the ServiceChange is lost while a
> later command is received by the gateway, how this command is handled is
> not specified in the draft text.
>
> Proposal:       It is recommended that the gateway will return an error.
>
> v13 Status:     OPEN. No text changed.
>
        [[TomT]]  Agreed in principle.  This triggered thoughts of flooding
attacks where the attacker masquerades as the MGC which it is indirectly
trying to flood with error messages.  I suppose we're OK so long as
authentication failures are discarded silently.  Anyway, I'll add a
"clarification" to section 8.3 stating that the MG should respond with an
error to authenticated messages from MGCs with which the MG is not currently
associated.   It's not quite so simple for MGCs receiving messages from
strangers -- I guess the MGC has to look inside to determine whether to
accept them.

> Section:        11.2
> Category:       Technical
> Issue:          The draft text specifies that "If the MGC accepts the MG,
> it will send a Transaction Accept, with the MGCIdToTry set to itself. If
> the MG receives an MGCIDToTry not equal to the MGC it contacted, it send a
> ServiceChange to the MGC specified in the MGCIdToTry". It is inconsistent
> to on one hand accept the transaction as successful, yet on the other hand
> require the MG to examine the MGCIdToTry returned to determine if the
> registration really was successful or not. Examination of the syntax
> reveals that this is part of a larger problem where unsuccessful
> transactions, actions and commands are not able to return any other
> information than an ErrorDescriptor which can only contain an error code
> and text.
> Proposal:       It is recommended that the above procedure is replaced by
> return of an error code and another MGCIdToTry if the registration did not
> complete. Furthermore, it is recommended that ErrorDescriptors are
> extended
> to allow return of other information (essentially CommandReply) than only
> an error code and text.
>
> v13 Status:     OPEN. No text changed
        [[TomT]]
        As I see it, redirection is different from a transaction error.  The
MGC processed the command successfully, and the response contains useful
information.  An error should be thought of as a situation where the
responder reached a dead end when it tried to comply with the request.  In
general recovery from an error is pretty basic: kill the call.  In special
cases the error code and context should give enough information for
recovery.

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

---

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

At 08:51 PM 2/2/00 -0600, Tom-PT Taylor wrote:
>
>
>Comments below.
>-----Original Message-----  From:  Chip Sharp 
>[SMTP:[email-masked]]  Sent:  Tuesday, January 25, 2000 7:55 
>PM  [[TomT]]  snip
OK. Added the snipped stuff with updated status for completeness. Also note 
a couple of new issues here:

Section:         7.2.8 (ServiceChange), numbered list items two and three
Category:     Technical
Issue no.:     13.12
Issue:          The draft text has made significant changes to the 
semantics of the “Forced” and “Restart” ServiceChangeMethod since the Red 
Bank meeting. The old semantics guaranteed that the MG (or rather the 
affected terminations) would be in a known state following either a 
“Forced” or “Restart” ServiceChange. However the new semantics specified 
leaves the MG in an undefined state forcing the MGC to audit the MG to 
figure out what to do whenever it receives a “Forced” or “Restart” 
ServiceChange (consider the case where the primary MGC receives the 
“Forced” ServiceChange and the secondary (or another) MGC receives a 
subsequent “Restart” ServiceChange
Proposal:     It is strongly suggested that the MG (or affected 
terminations) will be in a known state when a “Forced” or “Restart” 
ServiceChange is issued. Consequently, the text should be brought back in 
line with the outcome of the Red Bank meeting.
Status:
     v14: OPEN. No relevant text changed.

Section:         7.2.8 (ServiceChange), numbered item six
Category:     Editorial/Technial
Issue no.:     14.7
Issue:          The draft text for “Failover” specifies that “…, and sent 
from MG to (new) MGC in response to the MG having received a ServiceChange 
with ServiceChangeMethod equal to Handoff”. It would seem to be 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 above text segment is moved from the 
“Failover” method to the “Handoff” method.
Status:

Section:         7.2.8 (ServiceChange), fifth last paragraph
Category:     Technical, Editorial
Issue no.:     14.8
Issue:          The draft text specifies that “The MGC shall use this 
Addres, if specified, in its response to the ServiceChange command and any 
subequent commands and responses” and “The MG shall use this address for 
any subsequent communication with the MGC”. While it makes sense to require 
commands to be sent to this address, it is generally not a good idea to 
require this for responses, e.g. for clustered systems. Furthermore, 
Section 9 (Transport) also specifies that “Responses to commands are sent 
back to the source address of the commands”
Proposal:     It is strongly recommended, that commands will be sent to the 
address specified while responses will always be sent to the source address 
they came from.
Status:

Section:         7.2.8 (ServiceChange), third last paragraph
Category:     Editorial
Issue no.:     12.25
Issue:          The draft text specifies that “The ServiceChangeMethod 
shall be “forced” for this usage”. This is inconsistent with the 
description in Section 11.2  which specified a ServiceChangeMethod of 
“Restart”.
Proposal:     It is recommended that the above text be modified to use a 
ServiceChangeMethod of “Restart” instead.
Status:
     v13: CLOSED. Text has been modified.

Section:     7.2.8 (ServiceChange), last bullet list
Category:     Technical
Issue no.:     13.13
Issue:          The draft text specifies that “Profile required if 
terminationID is not ROOT, optional otherwise”. However there may not be a 
profile, in which case it makes little sense to require it. Secondly, it 
would seem to make more sense to require a profile when the terminationID 
in fact is ROOT as that would be the initial registration.
Proposal:     It is proposed, that the text is changed in accordance with 
above.
Status:
     v14: OPEN. No relevant text changed.

>
>
>Section:        11.2  Category:       Technical  Issue:          When a 
>gateway starts, it generates a restart ServiceChange  to the MGC. If the 
>MGC's response to the ServiceChange is lost while a  later command is 
>received by the gateway, how this command is handled is  not specified in 
>the draft text.  Proposal:       It is recommended that the gateway will 
>return an error.
>
>error to authenticated messages from MGCs with which the MG is not 
>currently associated.   It's not quite so simple for MGCs receiving 
>messages from strangers -- I guess the MGC has to look inside to determine 
>whether to accept them.
v14: CLOSED. An error will be returned
>
>
>Section:        11.2  Category:       Technical  Issue:          The draft 
>text specifies that "If the MGC accepts the MG,  it will send a 
>Transaction Accept, with the MGCIdToTry set to itself. If  the MG receives 
>an MGCIDToTry not equal to the MGC it contacted, it send a  ServiceChange 
>to the MGC specified in the MGCIdToTry". It is inconsistent  to on one 
>hand accept the transaction as successful, yet on the other hand  require 
>the MG to examine the MGCIdToTry returned to determine if 
>the  registration really was successful or not. Examination of the 
>syntax  reveals that this is part of a larger problem where 
>unsuccessful  transactions, actions and commands are not able to return 
>any other  information than an ErrorDescriptor which can only contain an 
>error code  and text.  Proposal:       It is recommended that the above 
>procedure is replaced by  return of an error code and another MGCIdToTry 
>if the registration did not  complete. Furthermore, it is recommended that 
>ErrorDescriptors are extended  to allow return of other information 
>(essentially CommandReply) than only  an error code and text.
>
>v13 Status:     OPEN. No text changed  [[TomT]]  As I see it, redirection 
>is different from a transaction error.  The MGC processed the command 
>successfully, and the response contains useful information.  An error 
>should be thought of as a situation where the responder reached a dead end 
>when it tried to comply with the request.  In general recovery from an 
>error is pretty basic: kill the call.  In special cases the error code and 
>context should give enough information for recovery.
Not really. Think of SIP, HTTP, MGCP, etc. There are numerous return codes 
that have nothing to do with "errors" per se. In reality, these "error 
codes" are really "return codes" and maybe that's where the confusion arises.
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.          	
--------------------------------------------------

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 4 Feb 2000 11:30:59 -0500

Glitch warning -- indicated change won't work.  Our messages can include
both requests and responses, so the address to which messages are sent is an
all or nothing decision.  I'll try to make things consistent with section 9.
Simplest way is by saying that ServiceChangeAddress should not be sent by an
MG when transport is over IP.

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, February 04, 2000 9:22 AM
        [[TomT]]  snip
> > Issue:          The draft text specifies that "The MGC shall use this
> > subequent commands and responses" and "The MG shall use this
> > address for
> > any subsequent communication with the MGC". While it makes
> > sense to require
> > Section 9 (Transport) also specifies that "Responses to
> > commands are sent
> > back to the source address of the commands"
> I agree with this.  The text is inconsistant, so something needs
> to be changed.  Chip's proposal seems the most reasonable way
> to resolve it
>
>
        [[TomT]]  snip

---

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

Excuse me, messages don't matter, transactions do.  A message with one
request transaction and one response transaction can, and most probably
will, result in a different
structure in outgoing messages.  It would not be a big burden to have
responses going
to a different place than transactions, although it might increase the
number of
messages.

Brian

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Friday, February 04, 2000 9:22 AM
[[TomT]]  snip

        [[TomT]]  snip

---

From: Sachin Mittal <[email-masked]>
Date: Fri, 4 Feb 2000 22:28:49 +0530

Issues/questions:
1. Graceful - When this is from MGC to MG on ROOT with finite delay MG shall
immediately
start ServiceChange with Method = ??? (Is it handoff, failover) to either
MGCIdToTry or secondary MGC(s). Anything
that needs to be sent should be sent to new MGC ???. (Seems similar to Handoff
case).
Is it that Graceful from MGc to MG is not allowed on ROOT ????
What about Graceful on ROOT with NULL Delay ??

2. If MGC sends Handoff MG sends failover (issue below). Also when MG detects
MGC failure
it sends Failover. This means that MGC is not told BY MG about the situation and
there
is an underlying assumption that in case of handoff MGC must have been
coordinating
with other MGC. Then what is the use of MG telling failover to MGC ?

Also Handoff can be used both in case of "In partial failure........." and
"Pairs of MGCs......."
means handoff is not only used for redundant operation but failure (failover ???
or forced ???)
also. Inpartial failure the method should be failover.

No recommendation is made on how the MGCs involved in the Handoff maintain state
info...."
implies that handoff is only used in case MGCs are redundant. We should
change the bullet "MGCIdtotry optional if message...." to "MGC should set
MGCIdToTry
in case of Handoff optional otherwise" because the "next to be tried" MGC in MG
list may not be the Redundant MGC.

3. Restart and Disconnected are always from MGC to MG and never from MG to MGC
????

4. 7.2.8 Failover

? sent from MG to MGC to indicate the primary MG is out of
service and a secondary
MG is taking over, and sent from MG to (new) MGC in response to the MG having
received a
ServiceChange with ServiceChangeMethod equal to Handoff.". How can MGc figure
out that
a secondary MG exists or this is Handoff from other MGC or MG HAS DETECTED MGC
FAILURE.

5. "Allowing the MGC to send duplicate messages to both MGs accommodates pairs
of MGs that are
capable of redundant failover of one of the MGs. Only the Working MG shall
accept or reject
transactions. Upon failover, the Primary MG sends a ServiceChange command with a
"Failover"
method and a "MG Impending Failure" reason. The MGC then uses the primary MG as
the active
MG. When the error condition is repaired, the Working MG can send a
"ServiceChange" with a
"Restart" method."
This is one type of implementation specific detail but what about the other kind
of implementation
in which MGs are cooperating for redundancy and MGC is not aware of that. Can MG
send Handoff (do we need to have something called MGIdToTry)

"Rosen, Brian" <[email-masked]> on 02/04/2000 07:52:21 PM

Please respond to "Rosen, Brian" <[email-masked]>

To:   [email-masked]
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Cisco SG16: Service Change

Comments below

> From: Chip Sharp [mailto:[email-masked]]
> Sent: Friday, February 04, 2000 12:08 AM
> To: [email-masked]
> Subject: Re: Cisco SG16: Service Change
>
>
> semantics of the "Forced" and "Restart" ServiceChangeMethod
> since the Red
> "Forced" or "Restart" ServiceChange. However the new
> semantics specified
> figure out what to do whenever it receives a "Forced" or "Restart"
> "Forced" ServiceChange and the secondary (or another) MGC receives a
> subsequent "Restart" ServiceChange
> terminations) will be in a known state when a "Forced" or "Restart"
There has not been, to my knowledge, any change to forced and restart
which alters the state of the terminations since Red Bank.

If you cold-start an MG, it will come up in a known state, and
Restart to it's MGC, primary or secondary.  I think we can all
agree it does this.

If the MG itself FORCES terminations out of service, then the MGC
has to do the subtract.  There is no ambiguity of state.  No
secondary MGC is involved.

If the MGC FORCES terminations out of service, it must do the
subtract also, and there is no ambiguity of state.  No secondary
MGC is involved.

Somehow, your problem statement gets into a Handoff, or Failover
case, where, for some reason, you posit a working primary MGC
getting one message, and a working secondary MGC getting another one.
On a failure of an MG, there is no change of MGC, so the restart
looks like an initial registration, and all the terminations
should be in a known state.

On an MG initiated failover, the MG registers with the secondary
with Failover, not Restart.  The MGC could send Forced to
the primary, but the MG is considering it dead, and probably
wouldn't do it.  At any rate, failover DOES require an audit
by the secondary MGC as it should.

On an MGC initiated failover, you use Handoff.  Again, the MGC knows
what the state is, but the secondary doesn't.  It must Audit, but
that is as it should be.

There are no other cases of Forced or Restart that I know about.

> Issue:          The draft text for "Failover" specifies that
> "..., and sent
> with ServiceChangeMethod equal to Handoff". It would seem to be more
> consistent if the MG sent a "Handoff" rather than a
> "Failover" to the (new)
> "Failover" method to the "Handoff" method.
> Status:
I'm okay with this, although I think it's a nit

> Issue:          The draft text specifies that "The
> ServiceChangeMethod
> shall be "forced" for this usage". This is inconsistent with the
> "Restart".
> ServiceChangeMethod of "Restart" instead.
> Status:
> Issue:          The draft text specifies that "Profile required if
> terminationID is not ROOT, optional otherwise". However there
> may not be a
How about: Profile is Required if the termination ID is ROOT,
and the entity supports a profile, optional otherwise.

I agree the text is wrong, and some change is required.

> codes" are really "return codes" and maybe that's where the
I'm with Tom on this one, and I'll further point out you can't do
what Chip proposes since if you get an Error descriptor, you
won't get the Service descriptor with the MgcIdToTry!

> Support NetAid!  http://www.netaid.org

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:[email-masked]

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 4 Feb 2000 14:23:59 -0600

Proposal: if and only if the MG supplies a ServiceChangeAddress, it wants
all commands directed to that address.  The MGC would continue to send
responses back to the address the requests came from, even if this requires
sending transaction requests in separate messages from transaction replies
and transaction pending messages.

It's not symmetric: if the MGC supplies a ServiceChangeAddress, the whole
association moves over to that address.

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, February 04, 2000 11:48 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
>       Glitch warning -- indicated change won't work.  Our messages can
> include both requests and responses, so the address to which messages are
> sent is an all or nothing decision.  I'll try to make things consistent
> with section 9.  Simplest way is by saying that ServiceChangeAddress
> should not be sent by an MG when transport is over IP.
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 15:32:50 -0500

Agreed, and is there any reason the MG can't do the same?  Requests go where
ServiceChange says, replies go back to whom they came from.  Must make sure
we handle failover correctly.

Brian

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Friday, February 04, 2000 11:48 AM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
Subject:        RE: Cisco SG16: Service Change

        Excuse me, messages don't matter, transactions do.  A message with
one request transaction and one response transaction can, and most probably
will, result in a different

        structure in outgoing messages.  It would not be a big burden to
have responses going
to a different place than transactions, although it might increase the
number of
messages.

Brian

        -----Original Message-----
From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Friday, February 04, 2000 11:31 AM
To: Rosen, Brian; [email-masked]
Subject: RE: Cisco SG16: Service Change

        Glitch warning -- indicated change won't work.  Our messages can
include both requests and responses, so the address to which messages are
sent is an all or nothing decision.  I'll try to make things consistent with
section 9.  Simplest way is by saying that ServiceChangeAddress should not
be sent by an MG when transport is over IP.

                -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Friday, February 04, 2000 9:22 AM
[[TomT]]  snip

                [[TomT]]  snip