RE: SG view of the ASP

Ilie,

> -----Original Message-----
> From: Ilie Glib [mailto:[email protected]]
> Sent: Friday, February 10, 2006 1:19 PM
> To: Tolga Asveren
> Cc: [email protected]
> Subject: Re: [Sigtran] SG view of the ASP
>
>
> Tolga,
>
> I do not like mentioning of any ASes, because it may look like it is
> allowed to have multiple associations from an ASP (ASP_ID) towards the
> same SGP, provided that each association serves different ASes.
[TOLGA]Not mentioning about AS would require *all* ASPs interacting with the
SG to have a unique id in the whole ASP set. Considering that those ASPs
could be operated by different organizations, this may not be practical.
OTOH, I believe to expect ASPs serving a specific AS to be assigned a unique
Id among themselves is not a unrealistic expectation.

Other than that, I understand your concern and I agree that multiple
associations between the saem ASP and SGP are not a good thing.
>
> Regards
>
> Ilie
>
> On 2/10/06, Tolga Asveren <[email protected]> wrote:
> > Ilie,
> >
> > > -----Original Message-----
> > > From: Ilie Glib [mailto:[email protected]]
> > > Sent: Friday, February 10, 2006 12:39 PM
> > > To: Tolga Asveren
> > > Cc: [email protected]
> > > Subject: Re: [Sigtran] SG view of the ASP
> > >
> > >
> > > Hello Tolga,
> > >
> > > First sentence
> > >
> > > >       The optional ASP Identifier parameter contains a
> unique value that
> > > >       is locally significant among the ASPs that support an AS.
> > >
> > > looks confusing because of "AS" at the end. ASP_UP can be sent before
> > > any knowledge about ASes is available in SG. Therefore ASP ID shall
> > > have SG or SGP uniqueness scope. I would prefer SGP scope, to fit the
> > > IPSP-IPSP traffic case best.
> > [TOLGA]I think the idea was to coordinate the ASP-Id among ASPs
> serving a
> > specific AS in a way -which is impelementation dependent-,
> where each ASP is
> > assigned a unique ASP-Id. Once this is done on ASP side, I don't see why
> > knowledge about SG side is necessary but I may be missing something.
> > >
> > > In case of IPSP-IPSP, all remote SUA peers of an IPSP shall have
> > > different ASP_IDs.
> > >
> > > Regards
> > >
> > > Ilie
> > >
> > > On 2/10/06, Tolga Asveren <[email protected]> wrote:
> > > > I agree that a clarification could be useful. What about
> the following:
> > > >
> > > >    ASP Identifier: 32-bit unsigned integer
> > > >
> > > >       The optional ASP Identifier parameter contains a
> unique value that
> > > >       is locally significant among the ASPs that support an AS.
> > > >
> > > >       This parameter identifies the physical ASP that is
> using this SCTP
> > > >       association when the SCTP endpoint address used by
> ASP is dynamic,
> > > >         e.g. where ASP is using an ephemeral SCTP port.
> > > >
> > > >       The SGP should save the ASP Identifier to be used, if
> necessary,
> > > >       with the Notify message (see Section 3.8.2).
> > > >
> > > > All ASPAC/ASPUP etc... procedures are considering ASP and SGP
> > > as signaling
> > > > peers. I don't see why we should try to change the signaling
> > > semantics for
> > > > ASPSM/ASPTM to apply between ASP and SG rather than between
> ASP and SGP.
> > > >
> > > >    thanks,
> > > >    tolga
> > > > > -----Original Message-----
> > > > > From: [email protected] [mailto:[email protected]]On
> > > > > Behalf Of Barry Nagelberg
> > > > > Sent: Friday, February 10, 2006 11:41 AM
> > > > > To: [email protected]
> > > > > Subject: RE: [Sigtran] SG view of the ASP
> > > > >
> > > > >
> > > > > All,
> > > > >
> > > > > There seems to be a consensus on the list that an SG with 2 SGPs
> > > > > should be aware that there is one physical ASP with 2
> > > > > SCTP associations (one to SGP1 and one to SGP2), and not assume
> > > > > that there are 2 ASPs. The consensus also seems to be
> > > > > that the method of informing the SG should be via the ASP Id
> > > > > param in the ASPUP msg.
> > > > >
> > > > > I am OK with this consensus, but if we want to adopt this
> > > > > consensus we must update the spec in regard to the definition
> > > > > of the ASP Id param. It currently says:
> > > > >
> > > > > <snip>
> > > > >    ASP Identifier: 32-bit unsigned integer
> > > > >
> > > > >       The optional ASP Identifier parameter contains a unique
> > > value that
> > > > >       is locally significant among the ASPs that support an
> > > AS.  The SGP
> > > > >       should save the ASP Identifier to be used, if
> > > necessary, with the
> > > > >       Notify message (see Section 3.8.2).
> > > > > <snip>
> > > > >
> > > > > This description is misleading, in that it implies that the only
> > > > > use for the ASP Id is in the NTFY msg. In fact, this is
> > > > > the ONLY use described in the entire spec for the ASP Id param.
> > > > >
> > > > > I suggest the following text for this param:
> > > > >
> > > > > <snip>
> > > > >    ASP Identifier: 32-bit unsigned integer
> > > > >
> > > > >       The optional ASP Identifier parameter contains a unique
> > > value that
> > > > >       is locally significant among the ASPs that support an AS.
> > > > >
> > > > >       This parameter identifies the physical ASP that is
> > > using this SCTP
> > > > >       association, in the case where an ASP is using more than one
> > > > >       association to communicate with the SG.
> > > > >
> > > > >       The SGP should save the ASP Identifier to be used,
> if necessary,
> > > > >       with the Notify message (see Section 3.8.2).
> > > > > <snip>
> > > > >
> > > > > Barry Nagelberg
> > > > > Adax, Inc.
> > > > >
> > > > > -----Original Message-----
> > > > > From: [email protected] [mailto:[email protected]]On
> > > > > Behalf Of Samuel Dur D. Jeyaseelan
> > > > > Sent: Friday, February 10, 2006 4:49 AM
> > > > > To: [email protected]
> > > > > Subject: RE: [Sigtran] SG view of the ASP
> > > > >
> > > > >
> > > > >
> > > > > Few comments inline.
> > > > >
> > > > >   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 Thu, 9 Feb 2006, Munnaluru, Krishna wrote:
> > > > >
> > > > > > The ASP is currently sending the ASP UP message with the
> > > same ASP Id to
> > > > > > both SGPs.
> > > > > >
> > > > > > As per the SG guys suggestion we temporarily changed the
> > > ASP trafficmode
> > > > > > in the ASP ACTIVE message to loadsharing and this problem
> > > goes away. But
> > > > > > we see another problem.
> > > > > >
> > > > > > The administrator on the ASP side decides to take down the SCTP
> > > > > > association with SGP2. The ASP sends ASP DOWN message to
> > > the SGP2. Then
> > > > > > the SGP2 responds with ASP DOWN ACK. So far everything
> > > looks good. But
> > > > > > then immediately the SGP1 sends a NOTIFY with the
> > > status=ASP Failure and
> > > > > > includes the Routing Context value. Why is the SGP1 sending
> > > this NOTIFY
> > > > > > and what is the expected behavior of the ASP upon receiving
> > > the NOTIFY
> > > > > > from the SGP1? The SG is sending the NOTIFY because it
> > > treats the ASP as
> > > > > > two separate ASPs and so it thinks that it is notifying
> to the other
> > > > > > ASP.
> > > > > >
> > > > > > I think it came down to the way SG was designed - "The SG
> > > treating each
> > > > > > association as a separate ASP as supposed to just one
> ASP with two
> > > > > > associations".  Is this the general way a SG behaves
> (or designed)?
> > > > > > Should it not treat an ASP as just one rather than two?
> > > > > >
> > > > > > Please provide some input so that I can confirm my
> > > understanding of the
> > > > > > M3UA protocol.
> > > > > It seems to be a problem with SG's implementation.
> following are the
> > > > > drawbacks with the SG you are using.
> > > > >
> > > > > 1.SG views two physical ASPs, eventhough you have one
> physical ASP.
> > > > >   In override traffic mode,as per your mail an ASP has
> registered with
> > > > >   two SGPs(SGP1 and SGP2) using the same ASP id in the
> ASP_UP message
> > > > >   then ASP sends ACTIVE message to SGP1 so whole AS becomes
> > > active at SG.
> > > > >
> > > > >   When SGP2 receives ACTIVE message, SGP1 sends
> NTFY(ALT_ASP_ACT) with
> > > > >   the same ASP id. This is not a correct behaviour of
> > > handling override
> > > > >   traffic mode. If the complete physical ASP goes down, then
> > > > >   alternate(standby) ASP should be able to send ACTIVE
> > > message but you can
> > > > >   not achieve this with your current configuration.
> > > > >
> > > > > 2.NTFY messages ALT_ASP_ACTIVE and ASP_FAILURE have ASP id
> > > but the same
> > > > >   ASP id is used in other SGPs.
> > > > >
> > > > > --Samuel
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Krishna
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email protected]]
> > > > > > Sent: Thursday, February 09, 2006 12:21 PM
> > > > > > To: Munnaluru, Krishna
> > > > > > Cc: [email protected]
> > > > > > Subject: Re: [Sigtran] SG view of the ASP
> > > > > >
> > > > > > Krishna,
> > > > > >
> > > > > > I suppose you could try adding ASP Id to the ASP Up
> message and see
> > > > > > if the SG recognizes the ASP as one.
> > > > > >
> > > > > > However, as Ille suggests, perhaps the problem is the
> SG's traffic
> > > > > > mode (rather than the AS's traffic mode).
> > > > > >
> > > > > > If the SG really believes that the ASP is two distinct
> > > ASPs, it should
> > > > > > be sending a NOTIFY("Alternate ASP Active") from SGP1.  If
> > > it does not,
> > > > > > IMO it is just a bug, so, perhaps the SG does not truly
> > > support Active/
> > > > > > Standby mode.
> > > > > >
> > > > > > --brian
> > > > > >
> > > > > >
> > > > > > Munnaluru, Krishna wrote:                    (Thu, 09 Feb
> > > 2006 11:34:46)
> > > > > > > Brian,
> > > > > > >
> > > > > > > This is how it is affecting my expected behavior.
> > > > > > >
> > > > > > > Note: Currently I have only one ASP but in future I
> > > intend to add a
> > > > > > > standby ASP. Hence I use the trafficmode=override in
> the messages.
> > > > > > Also
> > > > > > > the desired behavior is that the ASP to laodshare the
> > > traffic going to
> > > > > > > the SG among the two SGPs.
> > > > > > >
> > > > > > > The problem showed up during the following scenario:
> > > > > > >
> > > > > > > The ASP comes up, establishes associations and sends ASP
> > > UP message
> > > > > > > (ASPIdentifier = 10007) to both SGPs for which the SGPs
> > > respond with
> > > > > > ASP
> > > > > > > UP ACK.
> > > > > > >
> > > > > > > The ASP sends ASP ACTIVE (trafficmode=override) with a
> > > routing context
> > > > > > > for the AS to the SGP1 and the SGP1 responds with ASP
> > > ACTIVE ACK. The
> > > > > > > status on the SG shows that the AS is active on SGP1 and
> > > inactive on
> > > > > > > SGP2.
> > > > > > >
> > > > > > > Later the ASP sends ASP ACTIVE (trafficmode=override)
> > > with the same
> > > > > > > routing context to the SGP2 and the SGP2 responds with
> > > ASP ACTIVE ACK.
> > > > > > > The status on the SG shows that the AS is active on SGP2
> > > and inactive
> > > > > > on
> > > > > > > SGP1. I was expecting the AS to be active on both SGPs
> > > since the ASP
> > > > > > had
> > > > > > > sent ASP ACTIVE to both SGPs.  This was not what I
> was expecting.
> > > > > > >
> > > > > > > The explanation given by the Third party SG team is that
> > > since they
> > > > > > > treat association from SGP1 to ASP as one ASP (ASP1) and the
> > > > > > association
> > > > > > > from SGP2 to ASP as a separate ASP (ASP2), they are over
> > > writing the
> > > > > > > status when the SGP2 received the ASP ACTIVE message
> from the ASP.
> > > > > > They
> > > > > > > suggest that I put the trafficmode=loadshare and that
> > > would solve the
> > > > > > > problem.  So I am really confused.
> > > > > > >
> > > > > > > Hope this helps.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Krishna
> > > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Sigtran mailing list
> > > > > [email protected]
> > > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email protected]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > >
> > >
> > > --
> > > Ilie
> > >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
>
> --
> Ilie
>