Re: M3UA: Synchronizing DPC availability state between ASPs in the same AS

Hi David,

Thanks for your response...

On Mon, Apr 10, 2017 at 5:38 AM, David Laight <[email protected]> wrote:
>> Now this feels wrong to me.  There is nothing in the spec which
>> specifically states that the ASPs have to synchronize the destination
>> states between themselves just because they belong to the same AS.
>>
>> There is also numerous places (RFC 4666: 3.4.1 (DUNA) and 3.4.2)
>> where it says that the DUNA/DAVA message is sent to "all concerned
>> ASPs" and in 4.5.1 where it says:
> ...
>
> This is a difference between rfc 4666 and the older 3332.

Is it?  The only difference I can see in rfc 4666 in section 4.5.1 is
the addition of this paragraph:

   For the particular case that an ASP becomes active for an AS and
   destinations normally accessible to the AS are inaccessible,
   restricted, or congested, the SG MAY send DUNA, DRST, or SCON
   messages for the inaccessible, restricted, or congested destinations
   to the ASP newly active for the AS to prevent the ASP from sending
   traffic for destinations that it might not otherwise know that are
   inaccessible, restricted, or congested.  For the newly activating ASP
   from which the SGP has received an ASP Active message, these DUNA,
   DRST, and SCON messages MAY be sent before sending the ASP Active Ack
   that completes the activation procedure.

But RFC 3332 still doesn't really clearly state that the ASPs have to
synchronize their destination state within an AS.  On the contrary,
from 4.5.1 it still seems to imply that the SGP has to send DAVA/DUNA,
etc to _all_ "concerned" ASPs, not just one in an AS.

> AFAICT one major network equipment manufacturer has not updated their
> protocol stack to conform to rfc4666.
>
> We've a horrid bodge that detects the missing indications.

What missing indications are you referring to?  The missing NTFY
messages for the AS (section 5.1.1.1, etc..)?

thanks,
dan