idnits 2.17.1 draft-liu-anima-grasp-distribution-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 31, 2016) is 2733 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) == Missing Reference: 'TBD' is mentioned on line 147, but not defined == Unused Reference: 'RFC2119' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'I-D.du-anima-an-intent' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-autonomic-network-definitions' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'I-D.pritikin-anima-bootstrapping-keyinfra' is defined on line 339, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-07 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-05) exists of draft-du-anima-an-intent-04 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Liu 3 Internet-Draft S. Jiang 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 4, 2017 October 31, 2016 7 Information Distribution over GRASP 8 draft-liu-anima-grasp-distribution-03 10 Abstract 12 This document discusses the requirement of information distribution 13 capability in autonomic networks. Ideally, the autonomic network 14 should support distributing some information which is generated/ 15 injected at an arbitrary autonomic node and be distributed among the 16 whole autonomic domain. This docuemnt specifically proposes to 17 achive this goal based on the GRASP (A Generic Autonomic Signaling 18 Protocol), and specifies additional node behavior. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 4, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Information Distribution Scenarios . . . . . . . . . . . . . 3 56 2.1. Whole Domain Distribution . . . . . . . . . . . . . . . . 3 57 2.2. Selective Distribution . . . . . . . . . . . . . . . . . 3 58 2.3. Incremental Distribution . . . . . . . . . . . . . . . . 3 59 3. Distribution Requirements . . . . . . . . . . . . . . . . . . 3 60 3.1. Identifying Autonomic Domain Boundary . . . . . . . . . . 3 61 3.2. Arbitrary Injecting Point . . . . . . . . . . . . . . . . 4 62 3.3. Avoiding Loops . . . . . . . . . . . . . . . . . . . . . 4 63 3.4. Selective Flooding . . . . . . . . . . . . . . . . . . . 4 64 3.5. Point-to-Point Distribution . . . . . . . . . . . . . . . 4 65 3.6. Verification of Distributed Information . . . . . . . . . 4 66 3.7. Conflict Handling . . . . . . . . . . . . . . . . . . . . 4 67 4. Distribution Function and Behavior Specification . . . . . . 5 68 4.1. Using GRASP Flood Synchronization Message . . . . . . . . 5 69 4.2. Using GRASP Synchronization Message . . . . . . . . . . . 5 70 4.3. Selective Flooding . . . . . . . . . . . . . . . . . . . 5 71 4.3.1. Selecting Cretiria . . . . . . . . . . . . . . . . . 5 72 4.3.2. Node Behavior . . . . . . . . . . . . . . . . . . . . 6 73 4.4. Conflict Handling . . . . . . . . . . . . . . . . . . . . 6 74 4.5. Distribution Source Authentication . . . . . . . . . . . 6 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 80 8.2. Informative References . . . . . . . . . . . . . . . . . 7 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 In an autonomic network, sometimes the nodes need to share a set of 86 common information. One typical case is the Intent Distribution 87 which is briefly discussed in Section 4.5 of 88 [I-D.behringer-anima-reference-model]. However, the distribution 89 should be a general function that one autonomic node should support, 90 rather than a specific mechanism dedicated for Intent. This document 91 firstly analyzes several basic information distribution scenarios 92 (Section 2), and then discusses the technical requirements 93 (Section 3) that one autonomic node needs to fulfill. 95 This document proposes to achieve distribution function based on the 96 GRASP (A Generic Autonomic Signaling Protocol) [I-D.ietf-anima-grasp] 97 . GRASP already provides some capability to support part of the 98 distribution function. Along with that, this document also proposes 99 some additional functionality. Detailed design is described in 100 Section 4. 102 2. Information Distribution Scenarios 104 2.1. Whole Domain Distribution 106 Once the information is input to the autonomic network, the node that 107 firstly handle the information MUST be able to distribute it to all 108 the other nodes in the autonomic domain. 110 The distributed information might not relevant to every autonomic 111 node, but it is flooded to all the devices. 113 2.2. Selective Distribution 115 When one node receive the information, it only replicates it to the 116 neighbors that fit for a certain of conditions. This could reduce 117 some unnecessary signaling amplification. 119 However, this scenario implies there needs to be corresponding 120 mechanisms to represent the conditions and to judge which neighbors 121 fit for the conditions. Please refer to Section 4.3.2 (selective 122 flooding behavior). 124 2.3. Incremental Distribution 126 The distribution only goes to the nodes that newly get online. This 127 might mostly happen between neighbors. 129 The incremental distribution could also be a sub scenario of the 130 whole domain distribution. When one node is doing the whole domain 131 distribution, it is possible that some of its neighbors are sleeping/ 132 off-line, so when the neighbors get online again, the node should do 133 incremental distribution of the previous whole domain distributed 134 information. 136 3. Distribution Requirements 138 3.1. Identifying Autonomic Domain Boundary 140 The domain boundary devices are supposed to know themselves as 141 boundary. When the distribution messages come to the devices, they 142 do not distribute them outside the domain. 144 3.2. Arbitrary Injecting Point 146 The distributed information SHOULD be injected at any autonomic node 147 within the domain (or within a specific set of nodes [TBD]). 149 3.3. Avoiding Loops 151 There should be a mechanism to prevent the distributed information to 152 travel around the domain again and again, so that there would not be 153 a large amount of redundant packets troubling the network. 155 3.4. Selective Flooding 157 When one node receive the information, it only floods it to the 158 neighbors that fit for a certain of rules. 160 3.5. Point-to-Point Distribution 162 One node only distributes the information to another node. This is 163 for the incremental distribution scenario. 165 3.6. Verification of Distributed Information 167 o Information integrity verification 169 The receiving node SHOULD be able to verify whether the 170 distributed information is from the certain node. In other 171 words, it needs to make sure the information hasn't been 172 modified. 174 o Source authorization verification 176 Even the information integrity was verified, the distributed 177 information might still be invalid, since the distribution 178 source might not have the right to distribute such information 179 that it just exceeds its authority. 181 3.7. Conflict Handling 183 As long as it supports arbitrary point of injecting distribution, 184 there is possibility that two nodes advertise the same information 185 but with conflict attribute(s). Hence, there should be a mechanism 186 to handle the conflict. 188 4. Distribution Function and Behavior Specification 190 This section specifies using certain GRASP messages for distribution, 191 and also specifies the distribution behavior in an autonomic node. 193 4.1. Using GRASP Flood Synchronization Message 195 It is natural to use the GRASP Flood Synchronization message for 196 distribution, since the Flood Synchronization behavior specified in 197 GRASP is identical to the the whole domain distribution scenario 198 described in Section 2.1. And the Flood Synchronization naturally 199 fits for "Arbitrary Injection Point" and "Avoiding Loops" 200 requirements. 202 4.2. Using GRASP Synchronization Message 204 It is natural to use the GRASP Synchronization message for Point-to- 205 Point distribution. The two behavior is identical. 207 4.3. Selective Flooding 209 4.3.1. Selecting Cretiria 211 When doing selective flooding, the distributed information needs to 212 contain the cretiria for nodes to judge which interfaces should be 213 sent the distributed information and which are not. Specifically, 214 the cretiria contains: 216 o Matching condition: a set of matching rules. 218 o Matching object: the object that the match condition would be 219 applied to. For example, the matching object could be node itself 220 or its neighbors. 222 o Action: what behavior the node needs to do when the matching 223 object matches or failed the matching condition. For example, the 224 action could be forwarding or discarding the distributed message. 226 Example: 228 o Matching condition: "Device role=IPRAN_RSG" 230 o Matching objective: "Neighbors" 232 o Action: "Forward" 234 This example means: only distributing the information to the 235 neighbors who are IPRAN_RSG. 237 4.3.2. Node Behavior 239 1) The distribution initial node Includes the Selecting Cretiria 240 information in the message that carries the distributed information. 242 2) The recieving node decides the action according to the Selecting 243 Cretiria carried in the message. 245 2-1 When the Matching Object is "Neighbors", then the node matches 246 the relevant information of its neighbors to the Matching 247 Condition. If the node finds one neighbor matches the Matching 248 Condition, then it forwards the distributed messge to the 249 neighbor. If not, the node discards forwarding the message to the 250 neighbor. 252 2-2 When the Matching Object is the node itself, then the node 253 matches the relevant information of its own to the Matching 254 Condition. If the node finds itself matches the Matching 255 Condition, then it forwards the distributed messge to its 256 neighbors; if not, the node discards forwarding the message to the 257 neighbors. 259 4.4. Conflict Handling 261 The distribution information needs to include timestamps or version 262 information. When conflict happens, the node only accepts the latest 263 information. 265 4.5. Distribution Source Authentication 267 The distribution source authentication could be done at multiple 268 layers: 270 o Outer layer authentication: the GRASP communication is within ACP 271 (Autonomic Control Plane, 272 [I-D.behringer-anima-autonomic-control-plane] ). This is the 273 default GRASP behavior. 275 o Inner layer authentication: the GRASP communication might not be 276 within a protected channel, then there should be embedded 277 protection in distribution information itself. Public key 278 infrastructure might be involved in this case. 280 5. Security Considerations 282 TBD. 284 6. IANA Considerations 286 No IANA assignment is needed. 288 7. Acknowledgements 290 This document is inherited from [I-D.ietf-anima-grasp] and 291 [I-D.behringer-anima-reference-model]. So thanks all the 292 contributors of the two work items. 294 This document was produced using the xml2rfc tool [RFC2629]. 296 8. References 298 8.1. Normative References 300 [I-D.ietf-anima-grasp] 301 Bormann, C., Carpenter, B., and B. Liu, "A Generic 302 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 303 grasp-07 (work in progress), September 2016. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 311 DOI 10.17487/RFC2629, June 1999, 312 . 314 8.2. Informative References 316 [I-D.behringer-anima-autonomic-control-plane] 317 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 318 Autonomic Control Plane", draft-behringer-anima-autonomic- 319 control-plane-03 (work in progress), June 2015. 321 [I-D.behringer-anima-reference-model] 322 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 323 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 324 for Autonomic Networking", draft-behringer-anima- 325 reference-model-04 (work in progress), October 2015. 327 [I-D.du-anima-an-intent] 328 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 329 Behringer, "ANIMA Intent Policy and Format", draft-du- 330 anima-an-intent-04 (work in progress), July 2016. 332 [I-D.irtf-nmrg-autonomic-network-definitions] 333 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 334 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 335 Networking - Definitions and Design Goals", draft-irtf- 336 nmrg-autonomic-network-definitions-07 (work in progress), 337 March 2015. 339 [I-D.pritikin-anima-bootstrapping-keyinfra] 340 Pritikin, M., Richardson, M., Behringer, M., and S. 341 Bjarnason, "Bootstrapping Key Infrastructures", draft- 342 pritikin-anima-bootstrapping-keyinfra-02 (work in 343 progress), July 2015. 345 Authors' Addresses 347 Bing Liu 348 Huawei Technologies 349 Q14, Huawei Campus 350 No.156 Beiqing Road 351 Hai-Dian District, Beijing 100095 352 P.R. China 354 Email: leo.liubing@huawei.com 356 Sheng Jiang 357 Huawei Technologies 358 Q14, Huawei Campus 359 No.156 Beiqing Road 360 Hai-Dian District, Beijing 100095 361 P.R. China 363 Email: jiangsheng@huawei.com