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

Toerless Eckert <tte@cs.fau.de> Thu, 11 February 2021 20:19 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 389EB3A1900 for <anima@ietfa.amsl.com>; Thu, 11 Feb 2021 12:19:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 lqpTAoIF1efL for <anima@ietfa.amsl.com>; Thu, 11 Feb 2021 12:19:17 -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 8B88E3A1901 for <anima@ietf.org>; Thu, 11 Feb 2021 12:19:16 -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 39458548045; Thu, 11 Feb 2021 21:19:10 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2B510440163; Thu, 11 Feb 2021 21:19:10 +0100 (CET)
Date: Thu, 11 Feb 2021 21:19:10 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Anima WG <anima@ietf.org>
Message-ID: <20210211201910.GA48871@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <17274.1611866107@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/OHMgwxfi1cfmsFhae-1OVURKEo8>
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: Thu, 11 Feb 2021 20:19:20 -0000

Michael:

The re-posted draft is a good reminder:

To me, the draft touches on a very important and hopefully lucrative topic, but i think
the text makes it very hard to figure out what's going on.

Let me try to summarize the situation from where i sit:

draft-ACP section 7. explains how to implement ACP on any low-end L2-only as well as
L2/L3 devices so that the device can operate ACP as if it was just an L3 device, while
in parallel operating unchanged on some or all ports as an L2 switch with STB:
ACP packets are software routed and software IPsec en/decrypted.

The magic to this is also explained, its simply to per-port-punt DULL GRASP packets
and later encapsulated ACP packets to CPU as it is done today for STP, CDP, LLDP,
EAPOL packets. The rest is then standard ACP implementation as on any L3 ACP device. 

The one possible gap for low-end hardware is the function:

  punt-to-cpu ACP packets from ports that are in STP blocked state.

In my past implementation experience, the punt option that always works is
one where you punt a specific ethertype. This is so because all the L2 switch
hardware was designed based on supporting 802.1x, and that is where LLDP and EAPOL
came into play and the minimum HW selector to decide between punt/forward/block
was simply ethertype.

Aka: The most simple extension we would need to drastically improve the ability for
ACP to get into lucrativee markets is to define an ACP encap using its own ethertype.
That is primarily an issue with finding i think 2000 USD and arguing with ethertype
registry owner about the long term value of that ethertype. We should simply make
sure that we build selectors into the encap to make it equal or better extensible
than EAPOL, so that we effectively have an IETF standards controlled equivalent
to EAPOL. There are IMHO a lot of good reasons not to use EAPOL:

- symmetric (ACP) vs. asymmeric (EAPOL use cases)
- control: IETF vs. IEEE
- risk/overhead: demux of such disjoined use-cases deeper into the packet such as different
   EAPOL sub-typing.

Forget using multicast MAC destinations. Maybe i can find the time trying to remember
all the horrible things that could go wrong with it.

The other option missing that may benefit discussion is to use a different unicast MAC
for ACP if the HW can punt-to-CPU a separate unicast-MAC. But it foregoes the big
benefit of the new ethertype option for us to be able to optimize the encap: aka:
remove the unnecessary overhead of an outer IPv6 encapsulation but simply run
native IPv6/IPsec packets across a new ethertype with maybe some extensibility
selector (as in EAPOL) before the IPv6/IPsec packet.

Cheers
    toerless