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

[Michael Richardson <[e-mail]>]

Michael Richardson <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-