Re: 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."

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran