idnits 2.17.1 draft-yizhou-anima-l2-acp-based-ani-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2021) is 921 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Y. Li 3 Internet-Draft Y. Zhou 4 Intended status: Informational L. Shen 5 Expires: April 22, 2022 Huawei Technologies 6 October 19, 2021 8 Requirement and a Reference Model of L2 ACP based ANI 9 draft-yizhou-anima-l2-acp-based-ani-00 11 Abstract 13 This document discusses the scenarios, requirements and a reference 14 model of ANI (Autonomic Networking Infrastructure) to be constructed 15 in a layer 2 network using L2 Autonomic Control Plane (ACP) and the 16 related functions. It expands the applicability of ANI to L2 network 17 and maintains the same infrastructure. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 22, 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Scenarios requiring L2 ACP functions in ANI . . . . . . . . . 2 55 3. Requirements for L2 ACP and related functions in ANI . . . . 4 56 4. Reference Model of L2 ACP based Autonomic Node . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 7.2. Informative References . . . . . . . . . . . . . . . . . 7 62 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 [RFC8993] defines a generic set of functions of Autonomic Network 68 Infrastructure (ANI). It contains addressing and naming of autonomic 69 nodes, discovery, negotiation and synchronization functions, 70 distribution of information, reporting, feedback loops, and routing 71 inside the Autonomic Control Plane (ACP) [RFC8994]. The Autonomic 72 Service Agent (ASA) is the atomic entity of an autonomic function and 73 is instantiated on autonomic nodes. They use the services and data 74 structures of the underlying ANI via the API exposed. When ASAs 75 communicate with each other, they should use the Generic Autonomic 76 Signaling Protocol (GRASP) [RFC8990]. GRASP runs over a secure 77 substrate that is isolated from regular data plane traffic which is 78 known as Autonomic Control Plane (ACP). 80 Though the design concept of ANI is generic, the methods for 81 constructing an ACP and routing in ACP [RFC8994], discovery of 82 adjacent system [RFC8990] and interaction of GRASP message are all at 83 the network layer. This document discusses the scenarios and 84 requirements of a layer 2 (L2) ACP as an instance of a Generalized 85 ACP to implement part of ANI functions in L2 network. And it shows a 86 reference model to construct such L2 ACP and the related functions. 88 2. Scenarios requiring L2 ACP functions in ANI 90 Current ACP implementation in ANI uses IPv6 link-local address based 91 ACP tunnel, RPL as routing protocol in ACP and GRASP DULL to discover 92 the adjacent node. It is appropriate when the managed network is a 93 large campus, a multi-site network or a carrier network. However 94 there are some cases which require L2 ACP functions in ANI. The L2 95 ACP is used in such cases that the managed network is a reletively 96 small layer 2 network where the network nodes have no L3 physical 97 interfaces and the network manager would like to use and verify the 98 L2 topology and reachability first for some management purpose. 100 +-------+ 101 +--|core |--+ 102 | +-------+ | core switch 103 | | 104 | | 105 | | 106 | | 107 +-------+ +-------+ 108 | agg 1 |---- | agg 2 | L2 aggregation switch 109 +-------+ /+-------+ 110 | \ / | \ 111 | \ / | \ 112 | \ / | \ 113 | \ / | \ 114 | \ | \ 115 +-------+ / \ +-------+ +-------+ 116 | acc 1 |/ \| acc 2 | | acc 3 | L2 access switch 117 +-------+ +-------+ +-------+ 118 | | 119 | | 120 | | 121 | | 122 +-------+ +-------+ 123 | AP 1 | | AP 2 | wifi access point 124 +-------+ +-------+ 126 Figure 1: L2 Campus Network 128 In SOHO or SMB case, the network is not large and the network nodes 129 have less resource. They are pure layer 2 nodes or nodes to be 130 enrolled as layer 2 first to form the initial simple topology for 131 cabling verification. In this case, autonomic network management 132 with the layer 2 network nodes is required. Figure 1 shows a typical 133 example of layer 2 network. 135 For small branch, the number of hosts is usually less than 200, and 136 the number of WiFi AP and access switches are both less than 10. Two 137 layers of core and access switch topology is the most common 138 structure. For a small campus, the number of hosts is usually less 139 than 2000. Three layer structure, core, aggregation and access 140 switch topology with some redundancy, might be used. The number of 141 access switches and WiFi APs are in the order of dozens. The total 142 number of network nodes, including switches and APs, is usually less 143 than 200. 145 It is sometimes required to firstly form a local area network 146 disconnected from the Internet. A laptop or mobile phone connected 147 to a specific node, usually the top level gateway as the core switch 148 shown in Figure 1, can be used by the network manager to visualize 149 and verify the topology. 151 3. Requirements for L2 ACP and related functions in ANI 153 The generic basic functions of ANI are required for L2 network to be 154 compliant with the high level autonomic network and node structure. 156 The assumptions and requirements include, 158 1. IP addresses of the node and its interface may not be available 159 upfront. 161 2. L2 ACP construction can be based on L2 available information and/ 162 or mechanisms, such as MAC address, VLAN or physical port 163 information. It should not rely on the IP addresses of the 164 interface. 166 3. Adjacent node discovery should be carried as L2 frame. When 167 GRASP DULL is used, it should function without network layer 168 multicast. 170 4. It is desired to reuse GRASP messages as much as possible. GRASP 171 messages should be able to be carried by L2 transport substrate. 173 5. L2 ACP module should provide API to the upper layer to allow ASA 174 to invoke L2 based functions. 176 6. Physical connectivity and topology information should be able to 177 be collected via L2 ACP for verification. 179 7. Routing in L2 ACP should support L2 loop-free logical topology 180 creation. 182 8. Minimal manual configuration is required. However, L2 ACP can 183 assume some management VLAN ID is pre-configured and with a 184 password or encryption key if necessary for security concern. 186 9. Re-use of the existing well-known multicast MAC addresses is 187 desired. 189 4. Reference Model of L2 ACP based Autonomic Node 191 Figure 2 shows a reference model when L2 ACP and the related function 192 is present in ANI. 194 +-------+ +-------+ 195 | ASA 1 | | ASA 2 | 196 +-------+ +-------+ 197 ^ ^ 198 | | 199 - - - - - - - - - - - - - - - 200 API Invoke (L2/L3) 201 - - - - - - - - - - - - - - - 202 | | 203 | | 204 --------------------------------------------------------------- 205 | Autonomic Networking Infrastructure| 206 v v 207 +----------------------------------------------------------+ 208 | Basic ANI functions | 209 | - Data strcutures | 210 | - Discovery, negotiation and synchronization functions | 211 | - Information and Intent Distribution | 212 | - ... | 213 +----------------------------------------------------------+ 214 +---------+ +----------------------------------------------+ 215 | | |L2 ACP | 216 | | |- Neighbour Discovery with L2 GRASP DULL | 217 | L3 ACP | |- Addressing and reachability | 218 | | |- Topology collection and loop-free creation | 219 | | |- GRASP with L2 extension in L2 ACP | 220 +---------+ +----------------------------------------------+ 221 --------------------------------------------------------------- 222 OS Functions 223 --------------------------------------------------------------- 225 Figure 2: Model of an Autonomic Node with L2ACP 227 The conceptual API should allow the ASAs to communicate with other 228 ASAs by invoking a set of L2 transport based functions in the 229 underlying ANI. The semantics of data models expressed by the 230 invoked L2 APIs are expected to be consistent as much as possible 231 with the L3 API with the similar functions. 233 Generally L2 ACP provides the similar functions as L3 ACP without 234 requiring the L3 address and reachability as the transport substrate. 236 The DULL instance of GRASP is used to discover neighbours. It uses 237 the IPv6 link-local multicast address. In layer 2 network, L2 GRASP 238 DULL is expected to be sent without the requiring L3 addresses. One 239 of the possible way is to extend L2 control plane protocol to carry 240 GRASP information. Link Layer Discovery Protocol (LLDP) defined by 241 IEEE 802.1 can be a candidate of such a protocol as it is able to 242 discover L2 neighbour nodes and the related L2 information such as 243 the physical port information and VLAN IDs. 245 RPL is suggested as a routing protocol used in L3 ACP [RFC8994]. 246 Routing is mostly used for L3 network. RPL is not directly 247 applicable to run in L2 ACP. Therefore similar functions of topology 248 collection and loop-free topology creation is required for L2 ACP. 249 L2 ACP should have its own addressing and L2 reachability scheme to 250 securely reach L2 autonomic node. 252 5. Security Considerations 254 [Editor's notes: It is not completed. Further discussions are 255 needed.] 257 The network leverages the L2 ACP and the related functions are 258 usually small to medium size network in a single or very closed 259 physical locations. Therefore physical security to prevent access by 260 unauthorized persons can be used to protect against interlopers and 261 eavesdroppers. 263 6. IANA Considerations 265 No IANA action is required for this document so far. More 266 consideration will be required for future normative specification of 267 extensions of GRASP, LLDP and/or other protocols. 269 7. References 271 7.1. Normative References 273 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 274 Autonomic Signaling Protocol (GRASP)", RFC 8990, 275 DOI 10.17487/RFC8990, May 2021, 276 . 278 [RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, 279 L., and J. Nobre, "A Reference Model for Autonomic 280 Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, 281 . 283 7.2. Informative References 285 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 286 Autonomic Control Plane (ACP)", RFC 8994, 287 DOI 10.17487/RFC8994, May 2021, 288 . 290 Acknowledgements 292 TBD 294 Authors' Addresses 296 Yizhou Li 297 Huawei Technologies 299 Email: liyizhou@huawei.com 301 Yujing Zhou 302 Huawei Technologies 304 Email: zhouyujing3@huawei.com 306 Li Shen 307 Huawei Technologies 309 Email: kevin.shenli@huawei.com