Subject: Re: [Sigtran] IG-03 Section 3.4 issue

From: "TOLGA ASVEREN" <[email-masked]>
Date: Fri, 7 Mar 2003 11:42:22 +0200

Samuel,

Tolga,

  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, 7 Mar 2003, TOLGA ASVEREN wrote:

>
> Samuel,
>
>
>
> Tolga,
>
> I can mention 2 cases.
>
> case 1) All NIFs are partially failed,this is very very rare case
>         But still sending ASP Inact Ack seems not to be an inefficient
>            method.Moreover basic aim is ASP should not be sending
messages
>            to SS7 nodes via partially failed SGPs, this is achieved by
>            sending ASP Inact Ack.
> [TOLGA]SGP can still route between ASPs. With ASPIA-ACK you are
preventing
> this, if NIF failure is global.
What does it mean 'SGP can still route between ASPs' ?
[TOLGA]That depending on implementation it still can route between
destinations in IP domain.

>
> case 2) Only a particular NIF is partially failed within a SGP.
>            Sending ASP Inact ack is an appropriate solution to handle
this
>            case.
> [TOLGA]Is it a MUST? If I drop the association to ASP will this be
"wrong"?
We can drop the association but when NIF becomes available, once again
ESTABLISH_SCTP,ASP_UP,REG,ASP_ACTIVE... these messages will be transmitted
between SGP and ASP. So i would suggest to send ASP Inact.
[TOLGA]Yes, you are free to do that and probably I also would do that but
IMO this is not a "MUST".
>
>            So why do you say to remove 3.4 IG?
> [TOLGA]Mainly because IMO what to do in such a case is implementation
> dependent. BTW, I disagree with the statement "SGP isolation from NIF".
SGP
> is the whole entity, maybe we better think of SGP-M3UA isolation from
NIF.
> I don't believe it is business of RFC to describe how and where one
> implements NIF and what to do during implementation dependent failure
> scenarios.
>
> --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, 7 Mar 2003, TOLGA ASVEREN wrote:
>
> >
> > Samuel,
> >
> >
> > Tolga,
> >
> > section 1.5.1
> >
> > says NIF is part of SGP which is an interface between MTP3 and M3UA.
> > Though it is an example in the RFC, i think still it holds good.
> > [TOLGA]In fact, I would think even the concept of isolation of SGP from
> NIF
> > for most implementations won't make sense, assuming that it will be
just
> a
> > functionality inside SGP entity. But again, this might be considered
> > implementation dependent.
> >
> > If your implementation has single NIF for all M3UA,then your point is
> > good to send DUNA(*) to all ASPs.
> > [TOLGA]Even in that case still not DUNA(*), just DUNA for destinations
in
> > traditional SS7 domain -assuming the implementation can route between
> ASPs
> > during NIF isolation, whatever NIF isolation means-. I believe it is
> better
> > to exclude 3.4 from IG.
> >
> > --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, 7 Mar 2003, TOLGA ASVEREN wrote:
> >
> > >
> > > Hi All,
> > >
> > > One small remark, 3.4 is about NIF isolation of the whole SG -all
SGPs-
> ,
> > > so if because of my implementation NIF isolation occurs always for
all
> > > SGPs, I wouldn't send ASPIA-ACK but DUNA for the destinations in SS7
> > domain
> > > -destinations which are not reachable because of NIF isolation-,
> because
> > > again depending on my implementation I can route between two ASPs
even
> > > during NIF ısolation. That all said, I still think all those are
> > > implementation dependent.
> > >
> > >     Tolga
> > >
> > >
> > > Hi all,
> > >
> > > I agree with Brian.
> > > If one or more SGP suffer a partial failure , then the SGP has to
send
> > > ASP Inactive Acks for all the concerned ASPs.So that the concerned
> > > ASPs will not route any messages to the SS7 destinations via the
> > partially
> > > failed SGP(s).
> > >
> > > --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 Thu, 6 Mar 2003, Ken Morneault wrote:
> > >
> > > >
> > > >
> > > > All:
> > > >
> > > > Brian has posted proposed changes to Section 3.4 of the IG
> > > > in December.  It would be useful to finish discussing his
> > > > proposed changes so that the IG can be updated and corrected
> > > > (if needed).
> > > >
> > > > Here are the original comments:
> > > >
> > > > Section 3.4
> > > >
> > > >   This section is against the concensus in the RFC.  The concensus
> was
> > > >   that if an SGP suffers a partial failure, it should send ASP
> Inactive
> > > >   Ack for the affected AS, and that if it should suffer a complete
> > > >   failure, it should send ASP Down Ack.
> > > >
> > > >   DUNA(*) is completely incorrect, particularly because the ASP is
> > > >   permitted to interpret DUNA(*) from one SGP to mean DUNA(*) from
> > > >   all SGPs in an SG.  SNMM are not per-SGP messages and were kept
> > > >   as indicating routing at SG scope.  Section 3.4 is in conflict
with
> > > >   this.
> > > >
> > > >   Pertinent passages in 4.3.4.2 permitting the unsolicited ASP Down
> > > >   Ack procedure are:
> > > >
> > > >     "If the ASP receives an ASP Down Ack without having sent an ASP
> > Down
> > > >      message, the ASP should now consider itself as in the ASP-DOWN
> > > state.
> > > >      If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE
> state,
> > > >      the ASP should then initiate procedures to return itself to
its
> > > >      previous state."
> > > >
> > > >   Pertinent passages in 4.3.4.4 permitting the unsolicited ASP
> Inactive
> > > >   Ack procedure are:
> > > >
> > > >     "...                If the ASP receives an ASP Inactive Ack
> without
> > > >      having sent an ASP Inactive message, the ASP should now
consider
> > > >      itself as in the ASP-INACTIVE state.  If the ASP was
previously
> in
> > > >      the ASP-ACTIVE state, the ASP should then initiate procedures
to
> > > >      return itself to its previous state."
> > > >
> > > >   Sending DUNA(*) for a partial failure at one SGP will result in
> > > >   MTP-PAUSE being issued to all MTP Users per section 4.5.2.1:
> > > >
> > > >     "At an ASP, upon receiving an SS7 Signalling Network Management
> > > (SSNM)
> > > >      message from the remote M3UA Peer, the M3UA layer invokes the
> > > >      appropriate primitive indications to the resident M3UA-Users.
> > Local
> > > >      management is informed."
> > > >
> > > >   making the IG Section 3.4. sending of DUNA(*) in an incorrect
> action.
> > > >   Partial failure of one SGP will wipe out traffic to all SGPs.
> > > >
> > > >   Sending DUNA(*) is also in conflict with section 4.5.2.1 which
> says:
> > > >
> > > >     "In the case where a local event has caused the unavailability
or
> > > >      congestion status of SS7 destinations, the M3UA layer at the
ASP
> > > >      SHOULD pass up appropriate indications in the primitives to
the
> > M3UA
> > > >      User, as though equivalent SSNM messages were received.  For
> > > example,
> > > >      the loss of an SCTP association to an SGP may cause the
> > > >      unavailability of a set of SS7 destinations.  MTP-PAUSE
> indication
> > > >      primitives to the M3UA User are appropriate."
> > > >
> > > >   Reword to use ASP Down Ack and ASP Inactive Ack for full or
partial
> > > >   failures of an SGP, as this was always the intended use of
> > unsolicited
> > > >   ASP Down Ack and ASP Inactive Ack.  Remove the MUST from both
DUNA
> (*)
> > > >   and DUNA so as to not conflict with the unsolicited procedures
and
> > the
> > > >   requirements of Sections 4.5.2.
> > > >
> > > >
> > > > _______________________________________________
> > > > Sigtran mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/sigtran
> > > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
> >
> >
> >
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> >
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>
>
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

_______________________________________________
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: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 7 Mar 2003 02:53:44 -0700

TOLGA,

TOLGA ASVEREN wrote:                                                                 (Fri, 07 Mar 2003 11:42:22)
> IMO this is not a "MUST".

Not a MUST, but the SGP SHOULD NOT drop the association because it has
a harmful effect.  The SGP SHOULD send ASPIA Ack or ASPDN Ack instead.

--brian

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