Re: [Anima] ANIMA when there is a system-wide issue

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 19 December 2020 22:49 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071D13A0C1D for <anima@ietfa.amsl.com>; Sat, 19 Dec 2020 14:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6CVKtlI7hLnP for <anima@ietfa.amsl.com>; Sat, 19 Dec 2020 14:49:40 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528573A09FA for <anima@ietf.org>; Sat, 19 Dec 2020 14:49:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E09A8389BC; Sat, 19 Dec 2020 17:52:31 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xMD-mLX7Ecdv; Sat, 19 Dec 2020 17:52:31 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 42E0B389B8; Sat, 19 Dec 2020 17:52:31 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6486462C; Sat, 19 Dec 2020 17:49:37 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <laurent.ciavaglia@nokia.com>, Anima WG <anima@ietf.org>
In-Reply-To: <PR3PR07MB68265F26A2CFB818D9CFDFBCF3C30@PR3PR07MB6826.eurprd07.prod.outlook.com>
References: <136aa329-41a5-8b65-ef9e-fadf089696eb@gmail.com> <704b66e9-d41c-f7e9-7e4b-f2d934ec9158@gmail.com> <PR3PR07MB68265F26A2CFB818D9CFDFBCF3C30@PR3PR07MB6826.eurprd07.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 19 Dec 2020 17:49:37 -0500
Message-ID: <11695.1608418177@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/dMIAyy7cfBGrOp--ABSTOPbSZcQ>
Subject: Re: [Anima] ANIMA when there is a system-wide issue
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Dec 2020 22:49:42 -0000

"Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" wrote:
    > For the incident you refer here, how/where would you see ANIMA
    > components to have (helped) avoided the outage?
    > Could we expect ANIMA networks to provide better/longer data plane
    > operation in case of failed control plane/control plane functions?
    > Beyond the pure ability to do so, there is a gain/risk trade-off to let
    > a DP run out of sync of its CP.

ACP provides a backup DP/CP that allows one to get back to the primary CP so
that it can be fixed.

rfc8368 explains this.
here is the abstract:

Abstract

   Operations, Administration, and Maintenance (OAM), as per BCP 161,
   for data networks is often subject to the problem of circular
   dependencies when relying on connectivity provided by the network to
   be managed for the OAM purposes.

   Provisioning while bringing up devices and networks tends to be more
   difficult to automate than service provisioning later on.  Changes in
   core network functions impacting reachability cannot be automated
   because of ongoing connectivity requirements for the OAM equipment
   itself, and widely used OAM protocols are not secure enough to be
   carried across the network without security concerns.

   This document describes how to integrate OAM processes with an
   autonomic control plane in order to provide stable and secure
   connectivity for those OAM processes.  This connectivity is not
   subject to the aforementioned circular dependencies.



--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide