Subject: [Anima] Use of LLDP in draft-richardson-anima-ipv6-lldp

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 15 Apr 2020 15:55:03 +0000

Hi,

The use of LLDP in draft-richardson-anima-ipv6-lldp was raised on the IEEE-IETF coordination alias.

Paul Congdon (Chair of IEEE 802.1 Maintenance Task Group, and very familiar with LLDP) has reviewed and provided comments as an individual.

His opinion is that this would be a serious misuse of the LLDP protocol and cause problems for implementations.  The general expectation and design of LLDP is that the information contained in the PDUs is fairly static in nature and does not change frequently.  Assuming the IPv6 packets are intending to implement their own protocol and will be changing frequently, encapsulating an IPv6 packet inside an LLDP TLV would signal a change on each transmission and possibly cause an SNMP TRAP on each packet received by a traditional implementation.

I basically support Paul's comments here - I don't think that we should be trying to tunnel IPv6 traffic over LLDP.

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

Regards,
Rob

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Apr 2020 15:02:39 -0400

Thank you for the comments on draft-richardson-anima-ipv6-lldp.

I include them below completely, and I'll reply to this message and address
the points inline in a couple of emails.

Rob Wilton \(rwilton\) <rwilton=[email-masked]> wrote:
    > Paul Congdon (Chair of IEEE 802.1 Maintenance Task Group, and very
    > familiar with LLDP) has reviewed and provided comments as an
    > individual.

    > His opinion is that this would be a serious misuse of the LLDP protocol
    > and cause problems for implementations.  The general expectation and
    > design of LLDP is that the information contained in the PDUs is fairly
    > static in nature and does not change frequently.  Assuming the IPv6
    > packets are intending to implement their own protocol and will be
    > changing frequently, encapsulating an IPv6 packet inside an LLDP TLV
    > would signal a change on each transmission and possibly cause an SNMP
    > TRAP on each packet received by a traditional implementation.

Russ Housley <[email-masked]> also forwarded Paul's comments directly
to me:

Paul Congdon <[email-masked]> wrote:
> I've had a brief look at this draft.   My personal belief is that this is a
> gross miss-use of the LLDP protocol.  LLDP is NOT a general L2 transport
> protocol.   It is intended to exchange a 'relatively' static local database
> with neighbors.   When an LLDP agent receives a frame, it is supposed to
> compare what it received with what it received the last time and if
> anything is different, it will throw away all of the previous information,
> replace the database with the most recently received information and
> 'wake-up' the higher layers to process the changes.  The expectation (and
> design center for the protocol) is that things do NOT change frequently.
> Assuming the IPv6 packets are intending to implement their own protocol and
> will be changing frequently, encapsulating an IPv6 packet inside an LLDP
> TLV would signal a change on each transmission and possibly cause an SNMP
> TRAP on each packet received by a traditional implementation.   If I
> understand the use case correctly, the draft is seriously miss-using the
> protocol and I believe others within 802.1 would agree with me.

    rob> I basically support Paul's comments here - I don't think that we should
    rob> be trying to tunnel IPv6 traffic over LLDP.

    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)?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Apr 2020 15:57:44 -0400

> static in nature and does not change frequently.  Assuming the IPv6

I understand how this proposal is a bit distasteful, and I hope that we can
come up with some alternative ideas (see next email).

I don't know how LLDP efforts are split between forwarding plane and control
plane on all systems. In designs I have been involved with, all LLDP packets
go to the control plane CPU, and they are decapsulated there.

In such a system, the IPv6 TLV(s) would be removed before the database is
updated or compared, so a system that supports this proposal would never emit
spurious SNMP alerts.   If you take a look at the target use cases for the
ACP at: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#section-3
and all of https://www.rfc-editor.org/rfc/rfc8368.html
we are trying to create a stable replacement for out-of-band control.
Without this new channel there isn't a place for SNMP (or RESTCONF) traps to
travel over.

    >> TRAP on each packet received by a traditional implementation.

I understand your concern is for systems that do *not* implement this
extension, and that they might generate a stream of SNMP Traps due to
changes.  This is a valid concern, but it is not how the ACP would work.

The first part of the ACP process, described at:
  https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#section-6.3

is to send out "multicast" GRASP DULL messages.  I put multicast in quotes,
because really, we want to send one out on each physical link in the
identical way that LLDP sends out announcements.

We could, as Rob has suggested:

    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?

do exactly this.  The DULL message that I described above would go out with
RFC8138/RFC6282 header compression and a CBOR encoded GRASP AN_FLOOD message
be unchanging.
It's 82 bytes including the TLV overhead, with the CBOR message itself being
67 bytes, including two IPv6 addresses (32-bytes).
(I didn't count the mandatory ChassisID/Port ID or Time to Live TLVs)

(Unfortunately, identical, and also unfortunately, redundant with the source
IPv6 address, which LOWPAN_IPHC had already successfully compressed out. But,
this is ethernet not 802.15.4 so not a huge problem)

I put my spreadsheet calculation and HTML output at:
  http://www.sandelman.ca/SSW/ietf/anima/ipv6-LLDP/
[neither an attachment nor HTML will survive the IETF mailarchive, so I am
  not putting them inline]

So a system that does not implement this mechanism will see a single
additional TLV, which will not change over time.
Systems that do support this will be able to respond using the same channel,
and will know the sender supports this.

We could, as you suggest, just use LLDP to signal this, and that's the
subject of my next email.
If we did that, then we'd need only one TLV, and we'd drop the compressed
IPv6/UDP header, saving 9 bytes.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Apr 2020 16:14:21 -0400

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.