Subject: Re: [Sigtran] M3UA IG05 :Response to ASPIA

From: [email-masked]
Date: Tue, 23 Sep 2003 16:03:35 +0530

Brian,
             It is not there in current IG.

"Brian F. G. Bidulock" <[email-masked]> on 09/23/2003 03:56:25 PM

Please respond to [email-masked]

To:    Kamesh Kaul/HSS@HSS
cc:    [email-masked]

Subject:    Re: [Sigtran] M3UA IG05 :Response to ASPIA

kakaul,

We already agreed to drop the 's' (plural) from Application Server's'
in these passages.

--brian

[email-masked] wrote:
(Tue, 23 Sep 2003 15:33:15)
>
>
>
>
> Hi,
>          Referring to section 4.3.4.3 ASP Active Procedures
>
>    "In the case where an ASP Active message does not contain a Routing
> Context
>    parameter, the receiver must know, via configuration data, which
>        Application Server(s) the ASP is a member."
>
>      Referring to section 4.3.4.4 ASP Inactive Procedures
>
>         "In the case where an ASP Inactive message does not
>    contain a Routing Context parameter, the receiver must know, via
>    configuration data, which Application Servers the ASP is a member and
>        move the ASP to the ASP-INACTIVE state in all Application
Servers."
>
> These lines imply that if ASPAC/IA messages is received without RC
receiver
> should activate/inactivate all the application servers served by ASP.
> If that is not implied then some clearification should be added in IG to
> make RC conditional in ASPAC and ASPIA messages aswell to avoid any
further
> confusions. Current IG does not address this problem
>
> Kamesh Kaul
> www.hssworld.com
> Hughes Software Systems

--
Brian F. G. Bidulock
[email-masked]
 http://www.openss7.org/

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "J.Javier Pastor (TS/EEM)" <[email-masked]>
Date: Tue, 23 Sep 2003 17:08:45 +0200

Hi Tolga, 

If we don't really see a problem in keeping it, I would prefer to leave the RFC as it is.

Cheers // Javier.

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: martes, 23 de septiembre de 2003 16:43
> To: [email-masked]
> Subject: RE: [Sigtran] M3UA IG05 :Response to ASPIA
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Barry Nagelberg
> > Sent: Tuesday, September 23, 2003 10:05 AM
> > To: [email-masked]
> > Subject: RE: [Sigtran] M3UA IG05 :Response to ASPIA
> >
> >
> > Why would we want to remove the 's' (plural) here? I think 
> that it must
> > remain. Otherwise how would the SGP know in this case (no Routing
> > Contexts)
> > in which ASs to mark the ASP as Inactive? The only logical action
> > is to mark
> > the ASP inactive in all the ASs.
> [TOLGA]In fact SGP already should know about RCs in such a situation,
> otherwise it wouldn't be able to put RC in other messages 
> (for example for
> DATA). Not sending RC in ASPAC/ASPIAC was just intended to be a
> shortcut -rather than putting all RC in the relevant message- . From
> procedures pont of view, IMO there aren't any significant
> advantages/disadvantages to keep or to drop this way of
> activating/deactivating AS but if it causes some confusion, 
> maybe it is
> better to drop it.
> >
> > Barry Nagelberg
> >
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > > Brian F. G. Bidulock
> > > Sent: Tuesday, September 23, 2003 6:26 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > >        move the ASP to the ASP-INACTIVE state in all
> > > Application Servers."
> > > >
> > > > These lines imply that if ASPAC/IA messages is received without
> > > RC receiver
> > > > make RC conditional in ASPAC and ASPIA messages aswell to avoid
> > > any further

---

From: [email-masked]
Date: Wed, 24 Sep 2003 09:18:26 +0530

Hi,
   In my understanding Section 4.3.4.3 in RFC needs minor change:

   Old Text:
  In the   case where an ASP Active message does not contain a Routing
Context parameter, the receiver must know, via configuration data, which
Application Server(s) the ASP is a member.

New Text:
  In the case where an ASP Active message does not contain a Routing
Context parameter, the receiver must know, via configuration data, which
Application Server(s) the ASP is a member and move the ASP to the
ASP-INACTIVE state in all Application  Servers.

 Also error code No Configured AS for ASP should mean that receiver of
ASPAC/ASPIA messages has no configured AS for the ASP/IPSP  sending
ASPAC/ASPIA messages.In this case IG 05 section 3.9.2 should be changed to
give correct meaning of the error code.

Kamesh Kaul
www.hssworld.com
Hughes Software Systems

"Brian F. G. Bidulock" <[email-masked]> on 09/23/2003 11:11:28 PM

To:    "J.Javier Pastor (TS/EEM)" <[email-masked]>
cc:    [email-masked], Kamesh Kaul/HSS@HSS

J.Javier,

A few moons ago now.  Perhaps Tolga can recall the name of the thread...

The point was that the RFC permits an SG implementation to decide what
"configured" means and refuse any ASPAC/ASPIA without an RC value with "No
Configured AS for ASP".  The wildcard behavior is not guaranteed by the
RFC.
The ASP must include RC in DATA and SNMM if there is more than a single AS
and
must therefore know the values if there is more than one AS and an SG
implementation is fully within its rights to refuse any ASPAC/ASPIA where
there is more than one AS.

Note that the error message say "No Configured AS for ASP", not "No
Configured
AS(s) for ASP".

The situation was meant to accomodate the case where the ASP thought that
it
was not necessary to include RC in any message, but there is not a single
AS
configured for the ASP.

If the wildcard behavior is necessary, it needs to be stated under which
conditions the SG should not (or must not) respond with "No Configured AS
for
ASP".  But that is rather pointless for M3UA, as the ASPs need to know the
RC
values in any case.  For SUA, the matter is a little different.  SUA can
have
many thousands of RC values representing GTT entries.  Wildcarding in this
fashion is a short-hand for long SUA messages.  M2UA gets around this by
activating IIDs rather than AS, and providing its own shorthand and rules
for
specifying ranges of IIDs that make up a single AS.

Somehow I don't think that we can get away without making some statement
in the IG.

Perhaps the advocates of the "wildcard" behavior can propose text.

--brian

J.Javier Pastor (TS/EEM) wrote:
(Tue, 23 Sep 2003 15:43:01)
> Brian,
>
> Could you please refer where that decission was agreed? I didn't find
it...
> Thanks // Javier.
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: martes, 23 de septiembre de 2003 12:34
> > To: [email-masked]
> > Cc: [email-masked]

--
Brian F. G. Bidulock
[email-masked]
 http://www.openss7.org/

---

From: [email-masked]
Date: Wed, 24 Sep 2003 11:04:43 +0530

Brian,
   I agree that configuration of AS at SG is a local thing. What i mean to
say is that SG will send error "No configured AS for ASP" only if no AS is
configured at its end when ASPAC message without RC is received.

"Brian F. G. Bidulock" <[email-masked]> on 09/24/2003 10:30:30 AM

To:    Kamesh Kaul/HSS@HSS
cc:    "J.Javier Pastor (TS/EEM)" <[email-masked]>,
       [email-masked]

kakaul,

I don't see how this guarantees the wildcard behavior.  As configuration
data is a local (and optional) thing, the SG is still at liberty to send
the
error code whenever RC is missing.

--brian

[email-masked] wrote:
(Wed, 24 Sep 2003 09:27:48)
>
>
>
>
>
> Hi,  Sorry for typo in New text it is ASP-ACTIVE instead of ASP-INACTIVE
> ASP-ACTIVE state in all Application  Servers.
>
> "DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited
> (HSS) and is intended solely for the use of the individual to whom it is
> addressed. It may contain  privileged or confidential information and
> should not be circulated or used for any purpose other than for what it
is
> intended. If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying, altering,
or
> disclosing the contents of this message. HSS accepts no responsibility
for
> loss or damage arising from the use of the information transmitted by
this
> email including damage from virus."

--
Brian F. G. Bidulock
[email-masked]
 http://www.openss7.org/

"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."

---

From: "J.Javier Pastor (TS/EEM)" <[email-masked]>
Date: Thu, 25 Sep 2003 12:50:58 +0200

Folks, 

As a summary of this discussions, after checking the RFC and the IG we can see the following disalignments:
- Use of wildcard and RC conditional for ASPAC and ASPIA 
- Use of wildcard and section 3.9.2 in IG

Then, aligning text with the wildcard option implies the following changes:

IG Section 2.9.2 new text will be updated to:

<newText>

When an ASP wishes to withdraw from receiving traffic within an AS,or the ASP wants to initiate the process of activation, the ASP sends an ASP Inactive message to the SGP or IPSP.
	
An ASP Inactive message MUST be always responded by the peer (although other messages may be sent in the middle) in the following way:

- If the ASP Inactive message contains a RC parameter and the corresponding RK is registered, the peer must respond with an ASP Inactive Ack message. 

- If the ASP Inactive message contains a RC parameter that is not registered, the peer must respond with an ERROR message with Error Code = "Invalid Routing Context".

- If the ASP Inactive message does not contain a RC parameter and the RK is registered, the peer must turn the ASP/IPSP to ASP-INACTIVE state in all the ASes it serves  and must respond with an ASP Inactive Ack message.

- If the ASP Inactive message does not contain a RC parameter and the RK is not registered, the peer must respond with an ERROR message with Error Code = "No configured AS for ASP".

</newText>

Also, the RC parameter for ASPIA and ASPAC will turn to optional instead of conditional and the corresponding changes will be removed from the section 3.5.2 in IG.

Finally it would be good to align 4.3.4.3 and 4.3.4.4 including in the former the last sentence of the latter: "and move the ASP to the ASP-ACTIVE state in all Application Servers", as Kamesh suggest.

Hope things get clearer with these changes...

As I final side thought I wonder whether it would be good to include a detailed outline of the possible responses to ASPAC message as a function of RC, in the same way as is proposed for  ASPIA answers...

Cheers // Javier.

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: martes, 23 de septiembre de 2003 19:41
> To: J.Javier Pastor (TS/EEM)
> Cc: [email-masked]; [email-masked]'
> Configured AS for ASP".  The wildcard behavior is not 
> guaranteed by the RFC.
> The ASP must include RC in DATA and SNMM if there is more 
> than a single AS and
> Note that the error message say "No Configured AS for ASP", 
> not "No Configured
> AS(s) for ASP".
> 
> The situation was meant to accomodate the case where the ASP 
> thought that it
> was not necessary to include RC in any message, but there is 
> not a single AS
> configured for the ASP.
> 
> conditions the SG should not (or must not) respond with "No 
> Configured AS for
> ASP".  But that is rather pointless for M3UA, as the ASPs 
> need to know the RC
> values in any case.  For SUA, the matter is a little 
> different.  SUA can have
> activating IIDs rather than AS, and providing its own 
> shorthand and rules for
> > Could you please refer where that decission was agreed? I 
> didn't find it...
> > 
> > Thanks // Javier.
> >