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

From: "TOLGA ASVEREN" <[email-masked]>
Date: Thu, 6 Mar 2003 17:18:12 +0200

Hi Ken,

Please see some comments inline. BTW, I still think defining behaviour of
the SG, when there is isolation from NIF should be left as implementation
dependent (so, no 3.4 at all or at least please no MUST)

  Tolga

                    Ken Morneault                                                                         
                    <kmorneau@cisc       To:     [email-masked]                                         
                    o.com>               cc:                                                              
                    Sent by:             Subject:     [Sigtran] IG-03 Section 3.4 issue                   
                    sigtran-admin@                                                                        
                    ietf.org                                                                              

                    06.03.2003                                                                            
                    16:34                                                                                 

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.
[TOLGA]SGP might be isolated from NIF and SS7 world but based on
implementation, it might still route between two ASPs. In such a case, I
wouldn't consider sending ASPIA-ACK as a good solution, because it will
stop all traffic to/from that ASP.

  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.
[TOLGA]In 3.4 it is said that DUNA(*) will be generated when all SGPs are
isolated from NIF but still I don't consider DUNA(*) correct for the reason
given above. IMO, DUNA is better to be sent for destinations in SS7 domain
in such a case -when all SGPs are isolated from NIF-, so that ASP might
stop traffic to those destinations. Also depending on
scenario/implementation SGPs might be isolated from NIF at different times,
so could initiate ASPIA-ACK etc.. IMO, there are too many implementation
dependent decisions and dependencies here. Why do we want to define it?

  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

---

From: [email-masked]
Date: Thu, 6 Mar 2003 10:54:18 -0500

Hello All,

I agree with Brian's comments:
Sending INACTIVE-ACK is the correct action for a SGP experiencing 'partial'
failure.
Sending DOWN-ACK is the corrent action for a SGP experiencing 'complete'
failure.
Sending DUNA(*) is never the correct action for a SGP experiencing a
failure, since
this message is used to communicate MTP3 status information of the hosting
SG,
and this status is outside the scope of one SGP.

Regards,

Jeff

                      Ken Morneault                                                                                               
                      <kmorneau@cisco.         To:      [email-masked]                                                          
                      com>                     cc:                                                                                
                      Sent by:                 Subject: [Sigtran] IG-03 Section 3.4 issue                                         
                      sigtran-admin@ie                                                                                            
                      tf.org                                                                                                      

                      03/06/03 09:34                                                                                              
                      AM                                                                                                          

All:

Section 3.4