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

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jun 2021 20:59:53 -0400

WG, after some thinking, I have revised this document from problem statement
to a proposed solution.

The short of it is that the problem is multicast/broadcast, such as done for
ND, DAD and GRASP-DULL.   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.

So the problem isn't ACP operation (IKEv2, IPsec, TCP for BRSKI onboarding),
but GRASP-DULL discovery!   This was my thought a few weeks ago.

My answer is to embed the GRASP DULL CBOR inside an LLDP TLV.
The only only issue is that each GRASP M_FLOOD message contains a session-id,
which I think needs to change upon each M_FLOOD that is sent.  It would be
better for LLDP, as I understand it, if each message could be identical,
unless there is an actual change to the contents.
(Annoyingly, "session-id" does not appear in RFC8990 Section 2.7 on Session
Identifier)

I can't identify an impact of not changing it when the LLDP is retransmitted.

[email-masked] wrote:
    > Title:		Autonomic Control Plane design for Layer-Two Switched Networks
    > Document date:	2021-06-15
    > Group:		Individual Submission
    > Pages:		6

(it got shorter!)

    > Html:           https://www.ietf.org/archive/id/draft-richardson-anima-l2-friendly-acp-02.html

    > Abstract:
    > This document proposes a design for an L2 aware Autonomic Control
    > Plane that can be deployed easily to layer-two (Ethernet) switched
    > technologies that are common on Campus/Enterprise network
    > architectures.

    > This document leverages the hop-by-hop announcement used in LLDP, but
    > runs bulk data over normal IPv6 Link-Local unicast ethernet frames.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Jun 2021 14:29:05 +1200

I think this works. Is there an established API for accessing LLDP?

One comment:

> Unicast traffic between two control plane CPUs

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.

Regards
   Brian Carpenter

On 16-Jun-21 12:59, Michael Richardson wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jun 2021 22:38:27 -0400

> 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.

    > 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?
Do you think that telling people to turn off DAD and NS is enough?
I guess they should turn off MLD as well.

Is there some IPv6 LL operational aspect that I've forgotten that would
require multicast?  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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Jun 2021 16:08:37 +1200

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

> I guess they should turn off MLD as well.

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

> 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

Ack
   Brian