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

[Michael Richardson <[e-mail]>]

Michael Richardson <[e-mail]> wrote:
    > 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

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.

    >> 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 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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-