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

"Brian F. G. Bidulock" <bidulock@openss7.com> Mon, 10 April 2017 20:09 UTC

Return-Path: <bidulock@openss7.com>
X-Original-To: sigtran@ietfa.amsl.com
Delivered-To: sigtran@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC586129AE0 for <sigtran@ietfa.amsl.com>; Mon, 10 Apr 2017 13:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fAHvdFZR5DX for <sigtran@ietfa.amsl.com>; Mon, 10 Apr 2017 13:09:37 -0700 (PDT)
Received: from gw.openss7.com (gw.openss7.com [142.59.210.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F027129AD2 for <sigtran@ietf.org>; Mon, 10 Apr 2017 13:09:35 -0700 (PDT)
Received: from wilbur.pigworks.openss7.net (ns5.evil.openss7.net [192.168.9.5]) by gw.openss7.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id v3AK9X77020171; Mon, 10 Apr 2017 14:09:33 -0600
Received: from wilbur.pigworks.openss7.net (localhost [127.0.0.1]) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id v3AK9Xew031329; Mon, 10 Apr 2017 14:09:33 -0600
Received: (from brian@localhost) by wilbur.pigworks.openss7.net (8.14.3/8.14.3/Submit) id v3AK9WXg031328; Mon, 10 Apr 2017 14:09:32 -0600
Date: Mon, 10 Apr 2017 14:09:32 -0600
From: "Brian F. G. Bidulock" <bidulock@openss7.com>
To: Dan Gora <dan.gora@gmail.com>
Cc: bidulock@openss7.com, sigtran@ietf.org
Message-ID: <20170410200932.GB30907@openss7.org>
Reply-To: bidulock@openss7.com
Mail-Followup-To: Dan Gora <dan.gora@gmail.com>, bidulock@openss7.com, sigtran@ietf.org
References: <CAGyogRamDgU7fhwfS1rgQC19-vrxsjc-uZvQGwx0wpKB846zKA@mail.gmail.com> <20170410194119.GA30425@openss7.org> <20170410195104.GA30907@openss7.org> <CAGyogRZvaPevoocFE52NzW-6sL_Zhx9UkHe005V_LtrQs3+GKA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAGyogRZvaPevoocFE52NzW-6sL_Zhx9UkHe005V_LtrQs3+GKA@mail.gmail.com>
Organization: http://www.openss7.org/
Dsn-Notification-To: <bidulock@openss7.org>
X-Spam-To: <blockme@openss7.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sigtran/UG1BJgyt0OxT98mj_pT_uIl4MmY>
Subject: Re: [Sigtran] M3UA: Synchronizing DPC availability state between ASPs in the same AS
X-BeenThere: sigtran@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Signaling Transport <sigtran.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sigtran>, <mailto:sigtran-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sigtran/>
List-Post: <mailto:sigtran@ietf.org>
List-Help: <mailto:sigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sigtran>, <mailto:sigtran-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Apr 2017 20:09:39 -0000

Dan,

Please see comments below...

Dan Gora wrote:                    (Mon, 10 Apr 2017 17:00:12)
> 
> If we have to "fix" this, it seems like it should be safe to
> synchronize the states across all the active ASPs.  I cannot think of
> a scenario where a DPC would be available in ASP 1 via SG1, but not
> via ASP2 as long as both are connected and ASP-Active with the SG1
> since the SG1 has to synchronize it's state among all the SGPs in the
> SG.  Right?

Well, no.  We considered that an SG with multiple SGP might get
one or more SGPs partitioned from the others, and potentially
isolated from the network.  Although they are isolated, their
M3UA connections to the ASPs in the AS are still viable and
the unsolicited ASP Inactive Ack procedure might not be
necessary.  In that case, some SGP might send DUNA(*) while the
others still have available routes.  This was a major reason
for sending periodic DAUD to the SGP that sent the corresponding
DUNA, DRST, SCON.

-- 
Brian F. G. Bidulock
bidulock@openss7.com
http://www.openss7.com/