anima Working Group                                        M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Standards Track                                  W. Pan
Expires: 17 December 2021                            Huawei Technologies
                                                            15 June 2021


     Autonomic Control Plane design for Layer-Two Switched Networks
               draft-richardson-anima-l2-friendly-acp-02

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.

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 17 December 2021.

Copyright Notice

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










Richardson & Pan        Expires 17 December 2021                [Page 1]


Internet-Draft               l2-friendly-acp                   June 2021


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Onbording process . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Other constraints . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   5
     10.2.  Informative References . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The creation and maintenance of the Autonomic Control Plane described
   in [RFC8994] 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.









Richardson & Pan        Expires 17 December 2021                [Page 2]


Internet-Draft               l2-friendly-acp                   June 2021


   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.

   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.

   This document proposes using LLDP for what it is good at: announcing
   capabilities, while using normal EtherType 0x86DD IPv6 frames for the
   normal ACP transport.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Protocol

   A new TLV for LLDP is allocated and called the GRASP-DULL.  The
   contents of the new TLV are the payload of the normal [RFC8994] GRASP
   DULL M_FLOOD, AN_ACP message.

   The LLDP subsystem in the control plane CPU needs to forward these
   messages along to the ACP GRASP daemon, and it needs to also include
   the source MAC address (and port number) from which the LLDP message
   was received.

   The ACP GRASP daemon can see the origin IPv6 Link-Local address from
   the GRASP DULL packet, and can now create an IPv6 neighbour cache
   entry (NCE) for that combination.  By forcing this NCE entry, the
   node avoids the need to do an unsafe multicast IPv6 Neighbor
   Discovery.

   The node SHOULD unicast a Neighbor Advertisement to the corresponding
   node to establish that node's NCE.






Richardson & Pan        Expires 17 December 2021                [Page 3]


Internet-Draft               l2-friendly-acp                   June 2021


   At this point it is possible to initiate the right key management
   daemon (IKEv2, etc.) using unicast IPv6 datagrams that only need
   unicast Ethernet packets.

3.  Onbording process

   In addition to normal operation, devices need to be onboarding.
   [RFC8995] section 4.1.1 defines the AN_PROXY message to be used for a
   new pledge to discover which neighbors are willing to act as
   onboarding proxies.

   This M_FLOOD message will fit into the same GRASP DULL M_FLOOD
   message that contains the AN_ACP message.

   After discover of an eligible neighbour, onboarding proceeds with a
   TCP connection over IPv6 link-local addresses, using unicast Ethernet
   frames.

   A pledge that is in an L2 network that is broadcast unsafe MUST NOT
   do mDNS queries as described in [RFC8995] appendix B.

4.  Other constraints

   On broadcast unsafe L2 networks, IPv6 Duplicate Address Detection
   (DAD) MUST be turned off.  Only auto-configured IPv6 link-local
   addresses using SLAAC or stable-IID [RFC7217] may be used.

5.  Privacy Considerations

   The LLDP messages commonly contain information that uniquely
   identifies a specific piece of switching equipment.  The addition of
   the GRASP DULL message will also now reveal the link-local IPv6
   addresses of the device.  This additional information is either
   derived from ethernet addresses (so no new information), or will be
   derived using [RFC7217].

6.  Security Considerations

   Unclear as yet.

7.  IANA Considerations

   IANA is asked to allocate a TLV from the "IANA Link Layer Discovery
   Protocol (LLDP) TLV Subtypes" https://www.iana.org/assignments/ieee-
   802-numbers/ieee-802-numbers.xhtml#iana-lldp-tlv-subtypes

   for the GRASP DULL L2 announcement.




Richardson & Pan        Expires 17 December 2021                [Page 4]


Internet-Draft               l2-friendly-acp                   June 2021


8.  Acknowledgements

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

9.  Changelog

   1.  A specific LLDP method for announcement using normal IPv6
       datagrams described.

   2.  Document renamed, focus changed.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8994,
              DOI 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/info/rfc8994>.

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/info/rfc8995>.

10.2.  Informative References

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
              Control Plane for Stable Connectivity of Network
              Operations, Administration, and Maintenance (OAM)",
              RFC 8368, DOI 10.17487/RFC8368, May 2018,
              <https://www.rfc-editor.org/info/rfc8368>.



Richardson & Pan        Expires 17 December 2021                [Page 5]


Internet-Draft               l2-friendly-acp                   June 2021


Authors' Addresses

   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca


   Wei Pan
   Huawei Technologies

   Email: william.panwei@huawei.com







































Richardson & Pan        Expires 17 December 2021                [Page 6]