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

Toerless Eckert <tte@cs.fau.de> Tue, 16 February 2021 17:43 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 7ED0F3A0D29 for <anima@ietfa.amsl.com>; Tue, 16 Feb 2021 09:43:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 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, 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 YEKtER-CHfkO for <anima@ietfa.amsl.com>; Tue, 16 Feb 2021 09:43:26 -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 AE8D93A0D25 for <anima@ietf.org>; Tue, 16 Feb 2021 09:43:22 -0800 (PST)
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 F09C954804B; Tue, 16 Feb 2021 18:43:15 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E86D0440163; Tue, 16 Feb 2021 18:43:15 +0100 (CET)
Date: Tue, 16 Feb 2021 18:43:15 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Anima WG <anima@ietf.org>
Message-ID: <20210216174315.GB48871@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <18842.1613083225@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/XpSY3aMMTHvDCjFNp6MRcoCKTOo>
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:43:30 -0000

On Thu, Feb 11, 2021 at 05:40:25PM -0500, Michael Richardson wrote:
> 
> Toerless Eckert <tte@cs.fau.de> wrote:
>     > 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.
> 
> }   Predictable scaling requirements for ACP neighbors can most easily be
> }   achieved if in topologies such as these, ACP capable L2 switches can
> }   ensure that discovery messages terminate on them so that neighboring
> }   ACP routers and switches will only find the physically connected ACP
> }   L2 switches as their candidate ACP neighbors.
> 
> So, your solution is to have L2 switches not forward based upon L3 multicast addresses.

I can not parse this. Can you rephrase ?

> While this is deterministically mapped to a unique L2 multicast MAC,

What is "this" ? Sorry.... can not parse again.

> and maybe this can work...

> but, as you say below, that's not primarily how  the punt has worked in the past.

>     > 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.
> 
> okay.
> My only request is that we avoid adding a new thing to the list of per-port
> things, because they take up ASIC / NPU space.

Right.

>     > In my past implementation experience, the punt option that always works
>     > is one where you punt a specific ethertype.
> 
> Great, so one of the options I proposed is to have a new ethertype for
> IPv6-DULL messages, as you also say below.

My point was that its not only about the discovery packets. We also want to make
sure that the ACP secure channel packets could also go across blocked ports.

>     > 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.
> 
> I think that the IEEE/IETF liason can get us an ethertype, given an
> appropriate STD track draft. Tell me if that you think this is within the ANIMA WG's charter.

Different encap to make ANI more resilient. Sounds to me like perfectly in scope of
BRSKI/ACP extensions charter point.

I just think we shouldn't rush this but think it through well:

First of all, relying on a separate MAC address for ACP is the most eay way out.
But its not clear to me if thi works on every hardware. On the other hand, i can
see how i would always have a separate MAC address for ACP if for example i have classic
PC hardware and implement ACP on the BMC (e.g.: as extension to OpenBMC). But
many switches/routers also have a MAC address pool they can use.

Might make sense to just document that option (can't remember if i mentioned this
in ACPdraft). But nothing else to do.

When it comes to encapsulating across new ethertype, we need to make it extensible,
thats IEEE requirement for such a scarce resource. So we might even want to
ask around IETF for similar use-cases to have candidate other values for a
selector field for example.

Need to read through EAP over Ethernet to check what we could share. I forgot all about it.
But ultimatly, its going to be a small "selector-header" on top of the new ethertype
that we need to define.

I can see at least two selectors: ACP-secure-channel and Discovery (DULL-GRASP).

I have not thought about use-cases for e.g.: just BRSKI without ACP.

If you read up on the public slides i did eternities ago for my prior employer about that vendors
(somewhat proprietary) ACP implementation in the context of service provide ethernet services,
where a customer L2-ethernet service is multiplexed across a service provider L2VPN service, then those
type of service-edge nodes have all type of pain for discovery protocols such as CDP/LLDP,
e.g.: for their own instance and for the customer instance. So LLDP has explicit provisions
for this, and i have to find time to swap in the context of that stuff again. Much easier
if we had in-person IETFs and someone in the know like Norm Finn could remind me ;-))

As in: lets make sure that our selector field header could support the same flexibility
for those use-cases. At least to the extent that we know for a rev0 spec how many
"reserved/ignore" bits we need and then fill them in later.

Cheers
    Toerless

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



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