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

Toerless Eckert <tte@cs.fau.de> Tue, 16 February 2021 17:49 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 BE2223A0D4E for <anima@ietfa.amsl.com>; Tue, 16 Feb 2021 09:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-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 0B3vlp_ZK45o for <anima@ietfa.amsl.com>; Tue, 16 Feb 2021 09:49:22 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 1CAF03A0D62 for <anima@ietf.org>; Tue, 16 Feb 2021 09:48:47 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0024E548056; Tue, 16 Feb 2021 18:48:41 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id ECB82440163; Tue, 16 Feb 2021 18:48:41 +0100 (CET)
Date: Tue, 16 Feb 2021 18:48:41 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Anima WG <anima@ietf.org>
Message-ID: <20210216174841.GC48871@faui48f.informatik.uni-erlangen.de>
References: <136aa329-41a5-8b65-ef9e-fadf089696eb@gmail.com> <704b66e9-d41c-f7e9-7e4b-f2d934ec9158@gmail.com> <PR3PR07MB68265F26A2CFB818D9CFDFBCF3C30@PR3PR07MB6826.eurprd07.prod.outlook.com> <20210128160356.GB54347@faui48f.informatik.uni-erlangen.de> <17274.1611866107@localhost> <20210211201910.GA48871@faui48f.informatik.uni-erlangen.de> <18842.1613083225@localhost> <69bf6786-8969-ea45-3188-a18976c42b70@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <69bf6786-8969-ea45-3188-a18976c42b70@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/h9Kp5hBNKkmEAOIwuTabax4IqBA>
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: Tue, 16 Feb 2021 17:49:25 -0000

On Fri, Feb 12, 2021 at 05:04:40PM +1300, Brian E Carpenter wrote:
> >     > Forget using multicast MAC destinations. Maybe i can find the time
> >     > trying to remember all the horrible things that could go wrong with it.
> > 
> > okay.
> 
> As long as you remember that we will always be emulating multicast for discovery and flooding. There really isn't any mathematically possible way round that, even if the only solution is replicast.

Link-local multicast is fine for DULL grasp, i just wouldn't want to overload
the semantic of the multicast address for the punt="break L2 domain" function of th
ACP L2 switch.

Full mesh of ACP secure channels to emulate L2 multicast should be well enough defined
in ACPdraft. If we get ACP capable L2 switches, then that full-mesh problem wouldn't
even arise anymore.

More interestingly though is to make sure that whatever we do to make the solution 
more resilient (by being able to operate independent of STB), we should also make sure
that it does not prohibit HW forwarding if/when nodes implement this. I am not very
confident though that campus/Metro equipment will get HW IPsec any time soon, so
that would leave the open question of how to utilize MacSec. 

The trick is not trying to take too many steps at once but ensure that we don't close doors on them.

Cheers
    Toerless