enhancement: execute LLDP or liveness check with additional ether type - 802.1ad 0x88a8

[italovalcy]

Some ethernet carrier providers limit the frames that can be transported to only allow customer VLANs (traditional vlans based on 802.1q, with ethertype 0x8100). However, mef_eline leverages service VLANs (QinQ, based on 802.1ad and ether-type 0x88a8) to transport EVCs.

We should enhance our LLDP/liveness checks by adding additional frames to validate the forwarding of packets with ether-type 0x88a8, besides the tests on 0x8100 already done. We can do this in a slower pace. But it is very important to have this validation, especially to help network operators when activating new links.

[viniarck]

@italovalcy,

That'd be a relatively medium feature, each LLDP interface would need to specify which ethertype to use. If this were to be mutually exclusive either just use the current ethertype 0x8100 with the 3799 VLAN ID or ethertype 0x88a8 with the 3799 VLAN ID, then it could facilitate the implementation and much easier to maintain. Would that be sufficient? or would there be cases in practice where indeed it need to have more than one liveness session/channel per interface pair?

If the mutually exclusive option were to suffice, POST /api/kytos/of_lldp/v1/interfaces/enable/ could be augmented, since liveness completely piggybacks on the existing LLDP packets, which arguably would require a v2 (unless we just introduce an optional while not breaking v1 payloads), to also allow the protocol to be set. We could for instance allow an optional list to specify the ethertype:

{
    "interfaces": [
        "00:00:00:00:00:00:00:01:2",
        "00:00:00:00:00:00:00:02:2",
        "00:00:00:00:00:00:00:03:2",
        "00:00:00:00:00:00:00:02:3"
    ],
    "ethertypes": [
        33024,
        33024,
        34984,
        34984
    ]
}

This payload isn't ideal, so maybe going for a v2 might make sense, but let's first confirm the mutually exclusive option or not requirement to start considering the API. This probably deserves a lightweight new blueprint augmenting EP30

[viniarck]

@Ktmi could you help with this one? Especially since originally you also would work with BFD liveness on 2023.1, since this liveness here is also partly related to other future changes like using interruptions, so the earlier you start to get familiar with this part the better :)

Happy to contribute and review too.