Re: M3UA AS override mode from SGP perspective

Evgenij,

Yes, I was responsible for those passages.  The SGP has little
choice but to accept messages from the previously active ASP
until it can or does react to the NOTIFY(Alternate ASP_Active).
Because the NOTIFY is not acknolwedged, the SGP cannot really
know when it is reasonable to stop accepting messages, and
therfore are typically set up to always accept them.  The
passages dictate the ASP behaviour, but allow the SGP to never
discard a message.  If the SGP design is so poor that it
discards messages in this case, for example, after dispatching
the Notify, then messages will be lost regardless of the ASP
behavior.  This is why I say that the SGP usually accepts
messages from an ASP even when it is not active.

--brian


Evgenij wrote:                             (Wed, 06 Oct 2010 15:56:39)
> 
>    Brian, I'm confused!
>    > 3. In override mode only one ASP in the AS can be receiving traffic
>    >   (usually all can send traffic).
>    Does it mean, that ASP can usually send traffic before sending ASP-AC
>    message?
>    The RFC4666 says:
>    If the SGP or IPSP receives any Data messages before an ASP Active
>    message is received, the SGP or IPSP MAY discard them.
>    ...
>    In the case of an Override mode AS, receipt of an ASP Active messageat
>    an SGP causes the (re)direction of all traffic for the AS to the ASP
>    that sent the ASP Active message.  Any previously active ASP in the AS
>    is now considered to be in the state ASP-INACTIVE and SHOULD no longer
>    receive traffic from the SGP within the AS.  The SGP or IPSP then MUST
>    send a Notify message ("Alternate ASP_Active") to the previously
>    active ASP in the AS and SHOULD stop traffic to/from that
>    ASP.  The ASP receiving this Notify MUST consider itself now in the
>    ASP-INACTIVE state, if it is not already aware of this via inter-ASP
>    communication with the Overriding ASP.
>    I thought that data exchange in override mode is normal only for one
>    ASP-SGP.
> 
-- 
Brian F. G. Bidulock
[email protected]
http://www.openss7.org/