idnits 2.17.1 draft-carpenter-anima-grasp-config-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 September 2021) is 946 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-eckert-anima-grasp-dnssd-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA B.E. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Standards Track 21 September 2021 5 Expires: 25 March 2022 7 GRASP Configuration Management Objective 8 draft-carpenter-anima-grasp-config-00 10 Abstract 12 This document specifies a technical objective for dynamic 13 configuration of the GeneRic Autonomic Signaling Protocol (GRASP) 14 defined by RFC 8990. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 25 March 2022. 33 Copyright Notice 35 Copyright (c) 2021 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Format of the GRASP Objective . . . . . . . . . . . . . . . . 2 52 4. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 5. Implementation Status [RFC Editor: please remove] . . . . . . 4 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 55 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 9.2. Informative References . . . . . . . . . . . . . . . . . 5 60 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 5 61 A.1. Draft-00 . . . . . . . . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 The GeneRic Autonomic Signaling Protocol (GRASP) is specified in 67 [RFC8990]. It has a few parameters that might need configuration to 68 non-standard values, but since any form of manual configuration is to 69 be avoided in an autonomic network, this document describes how GRASP 70 can configure itself within a given autonomic network. For the 71 general model of such a network, see [RFC8993]. 73 The method is for an authoritative source in the autonomic network, 74 most likely associated with the Network Operations Center (NOC), to 75 use GRASP's flooding mechanism to periodically distribute a GRASP 76 objective (as defined in [RFC8990]) to all GRASP nodes in that 77 network. Each node will then validate the contents of the objective 78 as much as possible, and then apply any relevant configuration 79 changes locally. 81 2. Terminology 83 The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", 84 "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT 85 RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be 86 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only 87 when, they appear in all capitals, as shown here. 89 3. Format of the GRASP Objective 91 The formal definition of the GRASP objective is as follow, defined in 92 fragmentary CDDL [RFC8610]. 94 objective = ["GraspConfig", objective-flags, loop-count, objective-value] 96 loop-count = 0..255 ; as in the GRASP specification 97 objective-flags /= ; as in the GRASP specification 99 objective-value /= { 1*gc-element } 101 gc-element = ( gc-element-codepoint => gc-element-value ) 102 gc-element-codepoint = uint 103 gc-element-value = any 105 Initially, the following codepoints are defined: 107 gc-element-codepoint //= ( &(sender:0) => ipv6-address ) 108 ipv6-address = bytes .size 16 110 This provides the address of the original sender of the flooded 111 objective. 113 gc-element-codepoint //= ( &(sender-loop-count:1) => 1..255 ) 115 This provides the original loop count at the sender, so that the 116 receiver can compute how many hops the flood has taken. 118 gc-element-codepoint //= ( &(grasp-version:2) => 1..255 ) 120 At the moment there is only one version of GRASP. This element is 121 reserved for possible future use. 123 gc-element-codepoint //= ( &(max-multicast:3) => 1..65535 ) 124 gc-element-codepoint //= ( &(max-unicast:4) => 1..65535 ) 126 These elements can be used to change the default maximum message 127 sizes for multicast and unicast GRASP messages respectively. The 128 sizes *MUST NOT* be reduced below the default specified by [RFC8990]. 130 4. Validation 132 Upon receipt of a changed configuration element, each GRASP node 133 *MUST* validate it to the extent possible. The sender and sender- 134 loop-count elements may be used as part of the validation process. 136 5. Implementation Status [RFC Editor: please remove] 138 An experimental Autonomic Service Agent (ASA) supporting the 139 "GraspConfig" objective has been added to the Python prototype 140 implementation of GRASP. This ASA periodically checks for the 141 flooded objective and reconfigures GRASP's multicast and unicast 142 maximum message sizes accordingly. Another experimental ASA has been 143 implemented to periodically flood the "GraspConfig" objective as 144 would be done by a NOC, based on a JSON file expressing the required 145 configuration. No problems were observed while running these two 146 ASAs at the same time as other GRASP operations. Code is on Github 147 (https://github.com/becarpenter/graspy). 149 6. IANA Considerations 151 This document defines a new GRASP Objective Option name, 152 "GraspConfig". The IANA is requested to add this to the GRASP 153 Objective Names Table registry defined by [RFC8990] (if approved). 155 Open issue: Should IANA also register the gc-element-codepoints? (A 156 similar registration is described in [I-D.eckert-anima-grasp-dnssd] 157 for the proposed "SRV." group of GRASP objectives. Another option 158 would be to change "GraspConfig" to "SRV.GraspConfig".) 160 7. Security Considerations 162 The security considerations of [RFC8990] apply. 164 8. Acknowledgements 166 TBD 168 9. References 170 9.1. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, 174 DOI 10.17487/RFC2119, March 1997, 175 . 177 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 178 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 179 May 2017, . 181 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 182 Definition Language (CDDL): A Notational Convention to 183 Express Concise Binary Object Representation (CBOR) and 184 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 185 June 2019, . 187 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 188 Autonomic Signaling Protocol (GRASP)", RFC 8990, 189 DOI 10.17487/RFC8990, May 2021, 190 . 192 9.2. Informative References 194 [I-D.eckert-anima-grasp-dnssd] 195 Eckert, T., Boucadair, M., Jacquenet, C., and M. H. 196 Behringer, "DNS-SD Compatible Service Discovery in GeneRic 197 Autonomic Signaling Protocol (GRASP)", Work in Progress, 198 Internet-Draft, draft-eckert-anima-grasp-dnssd-02, 12 July 199 2021, . 202 [RFC8993] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, 203 L., and J. Nobre, "A Reference Model for Autonomic 204 Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021, 205 . 207 Appendix A. Change Log 209 A.1. Draft-00 211 * Original version 213 Author's Address 215 Brian E. Carpenter 216 The University of Auckland 217 School of Computer Science 218 PB 92019 219 Auckland 1142 220 New Zealand 222 Email: brian.e.carpenter@gmail.com