Autonomic Control Plane challenges for Layer-Two Switched Networks

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 1 August 2021.¶

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

The creation and maintenance of the Autonomic Control Plane described in [I-D.ietf-anima-autonomic-control-plane] requires creation of hop-by-hop discovery of adjacent systems. There are Campus L2 systems that are not broadcast safe until they have been connected to their Software Defined Networking (SDN) controller. The use of the stable connectivity provided by [RFC8368] can provide the SDN connectivity required.¶

There is a bootstrap interlocking problem: the network may be unsafe for ACP discovery broadcasts without the support of Spanning Tree Protocol (STP) or similar mechanisms until configured, yet it can not be automatically configured until the ACP discovery (and onboarding process) is done. Meantime, because of STP complicated topological calculations, the convergence can be very slow for larger networks. This can delay on-boarding.¶

In addition, forming a campus-wide network by default and using enabling STP does not work. STP is not secure and could be easily spoofed by malicious or untrusted devices. On manually configured networks today, STP is turned off on "access" ports, and enabled only for trunk ports. But in an autonomic network, it is not possible to know a-priori which ports will be trunk ports, so STP would have to be on by default it is was to be used.¶

What is needed is a way to send IPv6 traffic between these L2 switching devices in a way that is never forwarded, regardless of how the network is eventually configured. This is not just an inital configuration problem: devices may be added and removed at any time, due to needed expansion of capacity, planned upgrades, or devices failures.¶

A previous version of this document had proposed to do this with LLDP, but this was an inappropriate use of LLDP. An analysis of switching fabric options revealed that there were also no particularly advantage to this "hack", as it did not save any fabric resources.¶

What is desired is another encapsulation that has the same forwarding properties as LLDP.¶

It is noted that EAPoL (Ethernet Type 0x888e) also has the desired properties.¶

The ISIS routing protocol also uses a specific EtherType, and some implementations have the desired property of never forwarding.¶

2. Functional Requirements

1. The encapsulation should be capable of transferring full-size (1280 byte) IPv6 packets.¶
2. The encapsulation should not be confused with standard unicase IPv6 Ethernet encapsulation using EtherType 0x86DD.¶
3. Even when in a very primitive "default" or power-on configuration, a switching fabric should never forward frames received on one port to any other port.¶
4. It should be possible to send these frames from the forwarding engine to some control plane system for specific processing. When doing so, the physical port number needs to be associated with the frame.¶
5. It should be possible for control plane daemons to send frames for transmission on any port, and to that port only, even if that port is part of a larger layer-2 domain.¶

3. Nice to have Functionality

1. As the ACP uses IPsec over IPv6-Link-Layer packets, if a switching fabric has accelerated hardware for IPsec ESP, then it would be desireable if the encapsulation format did not get in the way of doing that.¶
2. As the ACP forms a private layer-3 Virtual Routing Fabric (VRF) on top of the tunnels, if the switching fabric has accelerated support for this, then it would also be useful to be able to use it.¶

It is likely that many L2 switching fabrics may not support IPsec ESP, or L3 routing. It was always the case that the ACP might have to be implemented as a software fabric in a control plane CPU. This is not a significant hurdle, as the ACP is not intended to be used for customer data, only control plane communication, and often only as a last resort.¶

4. Possibilities

There are two things which distinguish LLDP, EAPoL and ISIS traffic from regular traffic.¶

The most obivous is the EtherType.¶

LLDP traffic also uses a destination multicast address: 01:80:c2:00:00:0e, 01:80:c2:00:00:03, or 01:80:c2:00:00:00. The use of this destination address facilitiates transmission of the traffic through unmanaged switches ("dumb ethernet switches"), as well as allowing for seperation of provider and customer traffic in provider bridged (IEEE 802.1ad) situations.¶

5. Privacy Considerations

YYY¶

6. Security Considerations

Unclear as yet.¶

7. IANA Considerations

None yet.¶

8. Acknowledgements

Paul Congdon was very helpful in understanding how LLDP was actually processed in production equipment.¶

9. Changelog

Document renamed, focus changed.¶

Contributors

Authors' Addresses