Re: What are the chances that SG may not send Notify messages to AS (M3UA)

Deepak,

I think others have assisted you with compelling responses 
already. However, I don't believe that there is a contradiction 
in RFC 4666.  If the AS state has changed there MUST be a Notify 
message. If an ASP is just joining the club of inactive ASPs,
(and this fact alone doesn't change the AS state), then it 
SHOULD receive a Notify message, so it can get on-board with
the current AS state.

Brian and David have already commented before me why the SHOULD 
in my paragraph above "ought to have been" a MUST.  The RFC 
might contradict useful practice, but I don't think it contradicts 
itself. The second paragraph would have been clearer with an
"Otherwise" (i.e. not causing an AS state change).

The scenario you describe (first of two ASPs moves from DOWN to 
INACTIVE) is such that the AS state changes, and so the first 
MUST above (first sentence of Section 4.3.4.5) applies, and
that Notify is compulsory, even with this single AS state 
change. Note however, that the ASP can infer this from its
receipt of an ASP-UP-Ack when in AS-DOWN state.

With thanks, from Chris Benson.

On Wed, 23 Dec 2009, Deepak Gunjal wrote:

>>  Date: Wed, 23 Dec 2009 12:39:16 +0530
>>  From: Deepak Gunjal <[email protected]>
>>  To: Chris Benson <[email protected]>
>>  Cc: "[email protected]" <[email protected]>
>>  Subject: RE: [Sigtran] What are the chances that SG may not send Notify
>>      messages to AS (M3UA)
>>  
>>  Hi Chris,
>>  
>>  
>>  
>>  Thanks for your detailed reply. From the same section, 2nd paragraph "When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular AS, a Notify message SHOULD be sent, by the ASP-UP receptor, after  sending the ASP-UP-ACK, in order to inform the ASP of the current AS state."
>>  
>>  
>>  
>>  Now as per the above statement when an ASP moves from ASP-DOWN to ASP-INACTIVE it seems that the Notify could be optional (SHOULD clause) and this is the cause of my doubt which a bit is an contradictory statement what has been written in the beginning of this section 4.3.4.5.
>>  
>>  
>>  
>>  Can you please confirm if there is some misinterpretation from my side?
>>  
>>  
>>  
>>  Thanks
>>  
>>  Deepak
>>  
>>  
>>  
>>  -----Original Message-----
>>  From: Chris Benson [mailto:[email protected]]
>>  Sent: Wednesday, December 23, 2009 1:13 AM
>>  To: Deepak Gunjal
>>  Cc: [email protected]
>>  Subject: Re: [Sigtran] What are the chances that SG may not send Notify messages to AS (M3UA)
>>  
>>  
>>  
>>  Deepak,
>>  
>>  
>>  
>>  I won't estimate "chances" numerically (!), but I'd like
>>  
>>  to point out that the Notify message concerning AS state
>>  
>>  change is NOT optional but IS compulsory.
>>  
>>  
>>  
>>  Section 4.3.4.5 "Notify Procedures" of RFC 4666 (same as RFC
>>  
>>  3332 here) states (in part):
>>  
>>  
>>  
>>     A Notify message reflecting a change in the AS state MUST
>>  
>>     be sent to all ASPs in the AS, except those in the ASP-DOWN
>>  
>>     state, with appropriate Status Information and any ASP
>>  
>>     Identifier of the failed ASP.  At the ASP, Layer Management
>>  
>>     is informed with an M-NOTIFY indication primitive.
>>  
>>  
>>  
>>  I don't see anything optional about this, even in IPSP mode
>>  
>>  described subsequently.  Those first three words "A Notify
>>  
>>  message" unambiguously refer to the M3UA encoding "on the wire"
>>  
>>  from the SGP side.  Indications that are internally generated
>>  
>>  (at the ASP) are distinguished by the name M-NOTIFY, in the
>>  
>>  second sentence above.
>>  
>>  
>>  
>>  Perhaps the implementation which you dispute is referring
>>  
>>  to other forms of the Notify message (such as Status Type
>>  
>>  "Other"), or perhaps there's a difference reagrding the
>>  
>>  time interval over which an AS is in the AS_PENDING state.
>>  
>>  I presume that this last (PENDING) mechanism is to stop
>>  
>>  unecessary oscillations between AS states as one ASP goes
>>  
>>  INACTIVE and another ACTIVE in raspid succession. But
>>  
>>  after a configurable time interval, the AS must leave
>>  
>>  the AS-PENDING state, and a NOTIFY must be generated
>>  
>>  by the SG side, if the longer term AS state has changed.
>>  
>>  
>>  
>>  Good luck with getting those "chances" down to zero.
>>  
>>  
>>  
>>  Chris Benson.
>>  
>>  
>>  
>>  On Wed, 23 Dec 2009, Deepak Gunjal wrote:
>>  
>>  
>>  
>>  >>  Date: Wed, 23 Dec 2009 00:20:28 +0530
>>  
>>  >>  From: Deepak Gunjal <[email protected]>
>>  
>>  >>  To: "[email protected]" <[email protected]>
>>  
>>  >>  Subject: [Sigtran] What are the chances that SG may not send Notify messages
>>  
>>  >>       to AS (M3UA)
>>  
>>  >>
>>  
>>  >>  Hi,
>>  
>>  >>
>>  
>>  >>
>>  
>>  >>
>>  
>>  >>  I want to know that if SG implementations can opt to not send the Notify message for AS state change?
>>  
>>  >>
>>  
>>  >>  As per the RFC 4666 sending Notify messages is a SHOULD clause which recommends but not mandate the sending of Notify message unless there are very strong reason to not implement recommended behavior.
>>  
>>  >>
>>  
>>  >>
>>  
>>  >>
>>  
>>  >>  In such cases the ASP implementations will be required to shield themselves from such implementations. Although I haven't faced such issue till now but I heard that one of the leading M3UA testing tool vendor has told that their implementation does not send Notify or it can send Notify may be after AS has gone through two or more state changes.
>>  
>>  >>
>>  
>>  >>
>>  
>>  >>
>>  
>>  >>  Please suggest.
>>  
>>  >>
>>  
>>  >>
>>  
>>  >>
>>  
>>  >>  Thanks and Regards
>>  
>>  >>
>>  
>>  >>  Deepak
>>  
>>  >>
>>  
>>  >>  ________________________________
>>  
>>  >>  "DISCLAIMER: This message is proprietary to Aricent 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. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
>>  
>>  >>
>>  
>>  ________________________________
>>  "DISCLAIMER: This message is proprietary to Aricent 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. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
>>