Re: [Anima] draft-richardson-anima-l2-friendly-acp-02.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 16 June 2021 04:08 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 6F2A43A49C0 for <anima@ietfa.amsl.com>; Tue, 15 Jun 2021 21:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 W5xp3R_QW5GK for <anima@ietfa.amsl.com>; Tue, 15 Jun 2021 21:08:43 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948933A49BF for <anima@ietf.org>; Tue, 15 Jun 2021 21:08:43 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id g4so955023pjk.0 for <anima@ietf.org>; Tue, 15 Jun 2021 21:08:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OrmlzUvKlKVCRJQBvBlVGrUjKj4kbeVTdBfm0qHan48=; b=Jgu9XD4UhuJ1g9QmUV5M1z9fzt2lcWH6iY7dKX2nb7guEfbUxWTR5yevXVNIOnFdlV bz1Q/wQTw2wCNC4Taa+u526XgdVIY1rc9y1w9hVF2/UxUWozvI8X4huuQNUSOQTH5NE0 gacaaWeHLGDayTuCVWHdz3szw4auP1545asrmXD2/Pmvgl8XC+BSuWJGXkcnpxfmcgeR kqw47dWEhZAPWmKfRw9lP05WPGXu/8bychm3oHV/nX1TzQ3i3bNwX+Efo/6y/9m/mgMI fvRhxc9ZoqN29lQGUvj3CE/c+JYB1hXJu5T/PDdwpr8TYdo8gEmTcIdWRBCS8RAeI0Lu bLJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OrmlzUvKlKVCRJQBvBlVGrUjKj4kbeVTdBfm0qHan48=; b=fIrzZqgrL6ux8M4QOGQX/GYCXoyZyUaI/Qla2FF/pon3eHpwW+YvZrlmQ4oBo3N65R EsFU8M9XY7dSYnnlO648A3GdYPuyOF3CpxHlbTEQct+MxwB0Y3l5vjo4nYvJhfUVSmVO iRzrtxB4DTGieca96rt8MuV/SgcXXcP9IC/sub4t1hFkmu/tEXk7ILVKNBPfgXPcv2ry nNqKxQVjw8Q/BajOvjl6os5hYyDm4fRgBKs+ABeQ9PV8diGg82ECQlU+bTqC/Uq1mM8L w7I+Hmuff/QBoDPr/ZMwVrvhPtFE/xneFdacgPZd0PNhB5J3B2+ZYPrqliTm43hcOKYh 0tKw==
X-Gm-Message-State: AOAM533yVI2va5eJ/DfhlCfJum5/3yRpy/U0HjkTWsKNwLFB5/pFEfXt R3gbe45r+sLdDV8wL99f+YzNJEXiuAGgsw==
X-Google-Smtp-Source: ABdhPJyUhK13KlWxSdJQt7MaWBITgPddwFP87dhhuPRJ72KcP52Hx1QSwVWhi5ne3Yb2ZkoMhj7GlQ==
X-Received: by 2002:a17:90a:7d06:: with SMTP id g6mr2835029pjl.91.1623816522211; Tue, 15 Jun 2021 21:08:42 -0700 (PDT)
Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id u10sm562431pfh.123.2021.06.15.21.08.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jun 2021 21:08:41 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: anima@ietf.org
References: <162379258217.7432.3992272301775615539@ietfa.amsl.com> <6920.1623805193@localhost> <b6acc0f8-7feb-fdec-d992-f4037fc41b70@gmail.com> <1333.1623811107@localhost>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <91b98679-cf1a-e12e-0067-ae2a98f7905b@gmail.com>
Date: Wed, 16 Jun 2021 16:08:37 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <1333.1623811107@localhost>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/xWY7MzE2rM7QXGcnpwt_qBNhKtc>
Subject: Re: [Anima] draft-richardson-anima-l2-friendly-acp-02.txt
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, 16 Jun 2021 04:08:47 -0000

On 16-Jun-21 14:38, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>     > I think this works. Is there an established API for accessing LLDP?
> 
> Not that I know of.
>     There is https://github.com/intel/openlldp which seems more current than
>     the 2013-era Sourceforge project.
> 
> When using it, there is IPC from a CLI tool to the daemon to get/set info.
> For all I know, it interfaces to snmpd on *nix machines as well.
> 
> HOWEVER, I suspect that in control plane CPUs, that it's all vendor
> proprietary anyway.  I hope that openlldp will "just work" on the 8-port
> Zyxel switch that I have that boot openwrt.
> 
>     > One comment:
> 
>     >> Unicast traffic between two control plane CPUs
>     >> should not be a problem, so actual ACP traffic could be sent just fine,
>     >> as
>     >> long as it is only unicast.
> 
>     > Some ACP traffic will be multicast, of course, but *over* the unicast
>     > pt2pt links that carry the ACP VRF. So yes, it's unicast from the
>     > link's PoV.
> 
> Yes.
> Do you think that the document should beat people over the head about this?

Well, I think it needs to be spelled out. It certainly wasn't instantly
obvious to me (I mean a year or two ago).

> Do you think that telling people to turn off DAD and NS is enough?
> I guess they should turn off MLD as well.

Well, they might want to do regular data plane operations, no?

> Is there some IPv6 LL operational aspect that I've forgotten that would
> require multicast?  

I'm only aware of RA/NS/DAD stuff. Might be worth asking on v6ops.

> Until I revised the document this afternoon, I was
> convinced that I was going to have to add some attributes to the M_FLOOD
> announcement to make up for stuff that would normally arrive by NS/NA.
> 
> In looking at things, the only thing I knew I needed was the peer's L2
> address, and that's already there in the LLDP source address.  It could be
> that it's hard to get at though, so we might want to keep that in mind.

Ack
   Brian