Subject: RE: [Sigtran] SUA - RC in CLDT

From: [email-masked]
Date: Thu, 2 Oct 2003 12:56:59 +0300

Hi all, 

The (s) has now been struck from SUA.

John

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 08 August, 2003 12:12
> To: Anzile, Christophe
> Cc: [email-masked]
> Subject: Re: [Sigtran] SUA - RC in CLDT
> 
> 
> Anzile,,
> 
> We already discussed for M3UA that the '(s)' in the following passage
> should be struck.  The same argument applies to SUA:
> 
>   "In the case where an ASP Active message does not contain a Routing
>    Context parameter, the receive must know, via configuration data,
>    [of] which Application Server(s) the ASP is a member."
> 
> Should read:
> 
>   "In the case where an ASP Active message does not contain a Routing
>    Context parameter, the receive must know, via configuration data,
>    [of] which Application Server the ASP is a member."
> 
> --brian
> 
> On Fri, 08 Aug 2003, Anzile, Christophe wrote:
> 
> > I agree about this section.. 
> > what is confused to me is just the sentence following that one,
> > the one talking about "all Routing Contexts" when it is supposed
> > to have only one RC configured on the SG.
> > 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Friday, August 08, 2003 10:27 AM
> > To: Anzile, Christophe
> > Cc: Samuel Dur D. Jeyaseelan; Valerie Gastaud; Sigtran
> > Subject: Re: [Sigtran] SUA - RC in CLDT
> > 
> > 
> > Anzile,,
> > 
> > SUA-15 was supposed to include some of the more stable changes from
> > the M3UA IG where applicable to SUA.  Changing optional to 
> conditional
> > should have been one of them.
> > 
> > Nevertheless, SUA-15 section 4.3.4.3 does say:
> > 
> >   "...  In the case where an ASP wishes to process the traffic for
> >    more than one Application Server across a common SCTP 
> association,
> >    the ASP Active message(s) SHOULD contain a list of one or more
> >    Routing Contexts to indicate for which Application 
> Servers the ASP
> >    Active message applies. ..."
> > 
> > Which is no different than M3UA.
> > 
> > We can change optional to conditional against RC throughout.
> > 
> > --brian
> > 
> > 
> > Anzile, Christophe wrote:                                   
>                        (Fri, 08 Aug 2003 10:12:27)
> > > Brian,
> > > 
> > > are we supposed to look at M3UA IG when implementing SUA ?
> > > if yes, it would be nice to rename it.
> > > if no, it would be nice if John could clarify the SUA 
> draft especially the 4.3.4.3 section
> > > and use "conditional" instead of "optional" when it applies.
> > > 
> > > 
> > > -----Original Message-----
> > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > Sent: Friday, August 08, 2003 9:07 AM
> > > To: Samuel Dur D. Jeyaseelan
> > > Cc: Anzile, Christophe; Valerie Gastaud; Sigtran
> > > Subject: Re: [Sigtran] SUA - RC in CLDT
> > > 
> > > 
> > > Samuel,
> > > 
> > > The M3UA IG section 3.5 changes "optional" to 
> "conditional" everywhere
> > > for RC to indicate this explicitly.
> > > 
> > > --brian
> > > 
> > > Samuel Dur D. Jeyaseelan wrote:                           
>                           (Fri, 08 Aug 2003 01:58:42)
> > > > 
> > > > Everybody,
> > > > 
> > > > RC is a mandatory field when an ASP serves more than one AS.
> > > > A single ASP ACTIVE message without RC can not be used 
> to active 
> > > > multiple ASes across a common SCTP association.RFC does 
> not explicitely
> > > > say that RC is mandatory when an ASP serves
> > > > multiple ASes across a common association.But it is implied.
> > > > 
> > > > RFC has given a flexibility that RC is an optional 
> field when it serves
> > > > a single AS.
> > > > 
> > > > Say an example, an ASP1 serves multiple ASes and has 
> been connected to 
> > > > SGP1.If RC is an optional parameter to activate all 
> ASes, the potential
> > > > problem is, while sending DATA messages to ASP1, 
> > > > 
> > > > 1) How does ASP1 relate the DATA message with an appropriate AS?
> > > > 
> > > > 2) Suppose AS2 goes down, How does AS2 indicate this to 
> SGP1?(remeber 
> > > >    RC has not been communicated between SGP1 and AS2)
> > > > 
> > > > 3) Suppose SGP1 wants to put AS1 in DOWN state for some kind of
> > > >    configuration purpose, How does SGP1 communicate 
> this with AS1 without 
> > > >    RC?
> > > > 
> > > > RFC implicitely says that RC is a mandatory field when 
> an ASP serves
> > > > more than one ASes.
> > > > 
> > > > --Samuel
> > > > 
> > > >   Alcatel USA, Inc.                  Internet:
> > > > <userid>@ssd.usa.alcatel.com
> > > >   1000 Coit Road, Plano, Texas 75075
> > > >   ******* The opinions expressed are not those of 
> Alcatel USA, Inc. *******
> > > > 
> > > > On Fri, 8 Aug 2003, Brian F. G. Bidulock wrote:
> > > > 
> > > > > Anzile,,
> > > > > 
> > > > > Anzile, Christophe wrote:                             
>                              (Thu, 07 Aug 2003 11:24:09)
> > > > > > Brian (& Valerie),
> > > > > > 
> > > > > > Please do not make RC mandatory in ASPAC, or you'll 
> have strong side effects on the draft..
> > > > > > This is not consistent at all with what's written 
> in the draft page 92, ie
> > > > > >  [ it is not necessary for the ASP to 
> > > > > >    include all Routing Contexts of interest in a 
> single ASP Active 
> > > > > >    message, thus requesting to become active in all 
> Routing Contexts at 
> > > > > >    the same time.  Multiple ASP Active messages MAY 
> be used to activate 
> > > > > >    within the Application Servers independently, or 
> in sets.  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. ]
> > > > > > 
> > > > > > -> This is clear that if no RC is present in the 
> ASPAC, it should be considered as a wildcard
> > > > > > for all AS statically configured in the SG.. 
> > > > > 
> > > > > No, that is not what it means.  If RC is not 
> included, only a single AS can
> > > > > exist for the SCTP association.
> > > > > 
> > > > > 
> > > > > > In return, SG should send back all RCs activated in 
> the ASPAC-ACK msg.
> > > > > 
> > > > > No.  If there is no RC in ASPAC there may be no RC in 
> ASPAC Ack.
> > > > > 
> > > > > > 
> > > > > > -> This is why RC is therefore mandatory in CLDT/CLDR.
> > > > > 
> > > > > Don't think so...
> > > > > 
> > > > > --brian
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Christophe.
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Thursday, August 07, 2003 9:18 AM
> > > > > > To: Valerie Gastaud
> > > > > > Cc: Sigtran
> > > > > > Subject: Re: [Sigtran] SUA - RC in CLDT
> > > > > > 
> > > > > > 
> > > > > > Valerie,
> > > > > > 
> > > > > > SUA had RC mandatory in all messages.  This was 
> just a cut and paste error
> > > > > > from "common UA procedures".  The SUA draft should 
> be corrected to make RC
> > > > > > mandatory in ASPAC.  Although it may make some 
> sense to M2UA and even M3UA
> > > > > > to have RC optional in ASPAC, it makes little sense 
> in SUA.  This is why
> > > > > > RC is mandatory in all messages in SUA.
> > > > > > 
> > > > > > --brian
> > > > > > 
> > > > > > Valerie Gastaud wrote:                              
>                                (Wed, 06 Aug 2003 15:33:59)
> > > > > > > 
> > > > > > > Why is RC mandatory in the SUA data messages 
> (CLDT/CLDR + class2 messages)?
> > > > > > > This is not consistent with M3UA and this is not 
> consistent with the SUA
> > > > > > > ASPAC message in which the RC is optional.
> > > > > > > In case of static provisioning of RK, if an SGP 
> receives an ASPAC w/o RC, it
> > > > > > > won't be able to insert the RC in the CLDT.
> > > > > > > 
> > > > > > > Valerie
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > Sigtran mailing list
> > > > > > > [email-masked]
> > > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > > 
> > > > > > -- 
> > > > > > Brian F. G. Bidulock
> > > > > > [email-masked]
> > > > > > http://www.openss7.org/
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Sigtran mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > 
> > > > > -- 
> > > > > Brian F. G. Bidulock
> > > > > [email-masked]
> > > > > http://www.openss7.org/
> > > > > 
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > > 
> > > 
> > > -- 
> > > Brian F. G. Bidulock
> > > [email-masked]
> > > http://www.openss7.org/
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ world; the unreasonable one persists in  ¦
> http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
>                         ¦ Therefore  all  progress  depends on the ¦
>                         ¦ unreasonable man. -- George Bernard Shaw ¦
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 

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

---

From: "Barry Nagelberg" <[email-masked]>
Date: Thu, 2 Oct 2003 09:00:28 -0400

John,

This was definitely NOT agreed to for M3UA. It does not appear in the M3UA
IGv5, and the sentiment on the list was decidedly AGAINST this change.

Barry Nagelberg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Thursday, October 02, 2003 5:57 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sigtran] SUA - RC in CLDT

Hi all,

John

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 2 Oct 2003 13:52:16 -0600

Barry,

Which time.  Look back on this thread where we decidedly agreed to make this
change.

--brian

Barry Nagelberg wrote:                                                               (Thu, 02 Oct 2003 09:00:28)

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