Re: [Anima] A reminder of why we need ANIMA

Toerless Eckert <tte@cs.fau.de> Wed, 28 October 2020 15:02 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 1BC333A0A5F for <anima@ietfa.amsl.com>; Wed, 28 Oct 2020 08:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.867
X-Spam-Level:
X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, LOTS_OF_MONEY=0.001, MILLION_USD=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 VJ6qmrjj_kLB for <anima@ietfa.amsl.com>; Wed, 28 Oct 2020 08:02:44 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78EEF3A0BFD for <anima@ietf.org>; Wed, 28 Oct 2020 08:02:18 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E3C99548054; Wed, 28 Oct 2020 16:02:12 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DB846440059; Wed, 28 Oct 2020 16:02:12 +0100 (CET)
Date: Wed, 28 Oct 2020 16:02:12 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Artur Hecker <Artur.Hecker@huawei.com>
Cc: Anima WG <anima@ietf.org>
Message-ID: <20201028150212.GA20823@faui48f.informatik.uni-erlangen.de>
References: <5f954608.1c69fb81.6337f.9df2SMTPIN_ADDED_MISSING@mx.google.com> <c8dde31e-f509-99b6-9e25-970d792df182@gmail.com> <0bc8be5831844875bf500d7002b69447@huawei.com> <20201028002022.GA18251@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20201028002022.GA18251@faui48f.informatik.uni-erlangen.de>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/QD6dMeRpwL7fxtTDajv8JvBpowg>
Subject: Re: [Anima] A reminder of why we need ANIMA
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: Wed, 28 Oct 2020 15:02:46 -0000

Some followup ponderings:

I was not even aware that the FCC publishes these fine reports. Very nice
as a tax payer (and user of 911 services) to see this level of transparency
for live & death impacting service oversight. I wonder if/how this is
handled in other countries.

These things happen regularily and hefty fines have to be paid. From quickly
googling, the last one i can find from 2015 was 17.5 million USD. This
is because the 911 service is affected. If it was not for FCC, these things
would not be publically known, because no operator likes to see things like
this published.

Having these events be reported on IP networks is i would think also a rather
new occurrance. I have not tracked and analyzed history, but 20 years ago,
i would not have expected the 911 service to run over an IP network. And back
then the TDMA/ATM networks always had some out-of-band network access,
even if it was modems over leased lines because there was not even in-band
management capabilities on a lot of (non-IP) equipment.

So, while pointing to a single incident may be anecdotal, i think it might
actually help sell the ACP, because these recurring fines add up to real
money, so improvement of network operations to provide even more than
five 9 of reliability should certainly be in everybody's interest for live
& death services, including the operators who could avoid fines then.

Cheers
    Toerless


On Wed, Oct 28, 2020 at 01:20:22AM +0100, Toerless Eckert wrote:
> Gee, christmas already in October ?
> 
> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/905f21becaa50760419c3ba28d8df4bb82e7a911/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/64d5f691f350984383eb573de01afdddaefe33ed/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt
> 
> Thanks Brian, Artur. That was the missing piece of marketing collateral for the RFC.
> 
> Cheers
>     Toerless
> 
> On Tue, Oct 27, 2020 at 01:49:08PM +0000, Artur Hecker wrote:
> > Brian, all
> > 
> > 
> > Great reference, thanks for sharing!
> > 
> > Quote: "engineers almost immediately recognized that they had misdiagnosed the problem.  However, they were unable to resolve the issue by restoring the link, because the network management tools required to do so remotely relied on the same paths they had just disabled???.
> > 
> > This is why we need an adaptive, virtually in-band control plane. Programmable, software-driven networks will strongly amplify this effect. To me, out-of-band control plane is a misconception of virtualization ???? (have 2 networks, use 1), and it must still be adaptive & omnipresent.
> > 
> > Also nice: recommendations of the Bureau to the operators. 
> > 
> > 
> > Artur
> > 
> > 
> > > -----Original Message-----
> > > From: Anima <anima-bounces@ietf.org> On Behalf Of Brian E Carpenter
> > > Sent: Sunday, October 25, 2020 7:40 PM
> > > To: Anima WG <anima@ietf.org>
> > > Subject: [Anima] A reminder of why we need ANIMA
> > > 
> > > Hi ANIMA,
> > > 
> > > I think the document below is a timely reminder of why we *need* truly
> > > autonomic networks that are not subject to human misconfiguration errors.
> > > Start reading at "Root Cause and Event Summary".
> > > 
> > >    Brian
> > > 
> > > -------- Forwarded Message --------
> > > Subject: how to misconfigurer ospf and take out your cellullar net
> > > Date: Sun, 25 Oct 2020 09:31:46 +0000
> > > From: jon.crowcroft@cl.cam.ac.uk
> > > 
> > > https://docs.fcc.gov/public/attachments/DOC-367699A1.docx
> > > 
> > > 
> > > jon
> > > 
> > > 
> > > _______________________________________________
> > > Anima mailing list
> > > Anima@ietf.org
> > > https://www.ietf.org/mailman/listinfo/anima
> > _______________________________________________
> > Anima mailing list
> > Anima@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima
> 
> -- 
> ---
> tte@cs.fau.de
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
tte@cs.fau.de