Re: [ieee-ietf-coord] [Anima] Use of LLDP in draft-richardson-anima-ipv6-lldp

Michael Richardson <> Mon, 27 April 2020 20:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7B923A1BD3; Mon, 27 Apr 2020 13:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VM-81icuxrZA; Mon, 27 Apr 2020 13:14:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6EA123A1BD2; Mon, 27 Apr 2020 13:14:22 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 54A2738981; Mon, 27 Apr 2020 16:12:29 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 258F310E; Mon, 27 Apr 2020 16:14:21 -0400 (EDT)
From: Michael Richardson <>
to: "anima\" <>,
CC: "Rob Wilton \(rwilton\)" <>,, Pascal Thubert <>
In-Reply-To: <19580.1588014159@localhost>
References: <> <19580.1588014159@localhost>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Mon, 27 Apr 2020 16:14:21 -0400
Message-ID: <4979.1588018461@localhost>
Archived-At: <>
Subject: Re: [ieee-ietf-coord] [Anima] Use of LLDP in draft-richardson-anima-ipv6-lldp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Management-level discussions between IEEE and IETF on topics of interest to both SDOs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Apr 2020 20:14:26 -0000

Michael Richardson <> wrote:
    rob> [As an individual] Would it be possible to carry some static
    rob> information in LLDP that could be used to setup the autonomic control
    rob> plane outside of LLDP?  This would presumably require bridges to have
    rob> some minimal support for a native IPv6 host stack.  The issue of not
    rob> forwarding IPv6 packets for an interface in L2 mode could potentially
    rob> be mitigated by targeting the IPv6 packets to the peer interface MAC
    rob> address, or possibly use the "Nearest Bridge group multicast MAC
    rob> address" (i.e. 01-80-C2-00-00-0E)?

There are other constructions possible, but a lot of this depends upon ASIC
forwarding plane details to which I am not privy.  If there are datasheets
that I can refer to that do not require NDAs, I would be very happy to do
my own homework here.  {Not a VLSI designer, but I played one on TV back in 2000}

It has been my assumption that LLDP is not forwarded within L2 switch fabric
ASICs because of the ethernet-type.

I'm told that this is *definitely* how 802.1X port-control is implemented.
It would be great to confirm this with vendors of silicon.

In discussions about this document, it has been suggested, as you suggest
above, that using 01-80-C2-00-00-0E multicast address may be in fact how many
fabrics exempt LLDP frames from being forwarded.

What would happen if we used IPv6 0x86DD with this destination?

The goal is that it would *NEVER* get forwarded, no MATTER HOW MISCONFIGURED
the switch has become. With great power (SDN), comes new ways to screw up.
{Assume some first-term co-op's code got "devops" shipped to the SDN controller}

This channel is how one recovers, so ideally, this channel works when the
switch fabric is in it's boot-up default configuration.   Maybe I'm being
naive and ridiculous: the LLDP is just configured really early by the control
plane, but presumably it is also well protected against getting broken.

    rob> This would presumably require bridges to have
    rob> some minimal support for a native IPv6 host stack.

We are assuming that an IPv6 stack is easy to fit into the control plane CPU
of even the smallest switch controller.
We have multiple instances (open source: Contiki, OpenWSN, RIOT-OS, plus
multiple vendor stacks) of the v6-stack *AND* routing protocol (RFC6550-RPL)
fitting into less than 64K of code space, and only a few kilobytes of ram.
Meanwhile, many switches now have 64G of ram and Quad-Xeons...

To be clear: I ideally want the option to *AVOID* *ALL* of the NPUs, packet
classifiers, CAMs that like to parse v4 and v6 frames at high speed.
Toerless would like the ACP to optionally *use* them, and there a good
argument for this, and the ACP is a mesh network, and *can* have multiple
channels, both slow and fast between nodes, with the faster one taking all
the management traffic, unless/until it fails.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-