idnits 2.17.1 draft-ietf-pce-manageability-requirements-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 485. 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 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2008) is 5665 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Farrel 3 Internet Draft Old Dog Consulting 4 Intended Status: Best Current Practice 5 Created: October 15, 2008 6 Expires: April 15, 2008 8 Inclusion of Manageability Sections in PCE Working Group Drafts 10 draft-ietf-pce-manageability-requirements-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be 32 accessed at http://www.ietf.org/shadow.html. 34 Abstract 36 It has often been the case that manageability considerations have 37 been retrofitted to protocols after they have been specified, 38 standardized, implemented, or deployed. This is sub-optimal. 40 Similarly, new protocols or protocol extensions are frequently 41 designed without due consideration of manageability requirements. 43 This document specifies the recommendation for all new 44 Internet-Drafts in the PCE Working Group to include a 45 "Manageability Considerations" section, and gives guidance on what 46 that section should contain. 48 1. Introduction 50 When new protocols or protocol extensions are developed, it is often 51 the case that not enough consideration is given to the manageability 52 of the protocols or to the way in which they will be operated in the 53 network. The result is that manageability considerations are only 54 understood once the protocols have been implemented and sometimes not 55 until after they have been deployed. 57 The resultant attempts to retrofit manageability mechanisms are not 58 always easy or architecturally pleasant. Furthermore, it is possible 59 that certain protocol designs make manageability particularly hard to 60 achieve. 62 Recognizing that manageability is fundamental to the utility and 63 success of protocols designed within the IETF, and that simply 64 defining a MIB module does not necessarily provide adequate 65 manageability, this document defines recommendations for the 66 inclusion of Manageability Considerations sections in all Internet- 67 Drafts produced within the PCE Working Group. Meeting these 68 recommendations will ensure that proper consideration is given to the 69 support of manageability at all stages of the protocol development 70 process from Requirements and Architecture, through Specification and 71 Applicability. 73 It is clear that the presence of such a section in an Internet-Draft 74 does not guarantee that the protocol will be well-designed or 75 manageable. However, the inclusion of this section will ensure that 76 the authors have the opportunity to consider the issues, and by 77 reading the material in this document they will gain some guidance. 79 This document is developed within the PCE Working Group. It is hoped 80 that other working groups in the Routing Area and in other Areas will 81 benefit from the experiences generated in the PCE Working Group and 82 will consider adopting similar requirements. Expanding the scope to 83 cover all protocols developed within the IETF is an issue for the 84 IESG and for IETF consensus. [OPS-OAM] presents work in progress 85 within the Operations Area to give general guidance for considering 86 Operations and Management (OAM) of new protocols. 88 The remainder of this document describes what subsections are needed 89 within a Manageability Considerations section, and gives advice and 90 guidance about what information should be contained in those 91 subsections. 93 1.1. Requirements Notation 95 This document is not a protocol specification. Nevertheless, the key 96 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 97 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 98 are to be interpreted as described in [RFC2119] in order that the 99 contents of a manageability considerations section can be clearly 100 understood. 102 1.2. What is Manageability? 104 In this context, "manageability" is used to refer to the interactions 105 between a network operator (a human or an application) and the 106 network components (hosts, routers, switches, applications, and 107 protocols) performed to ensure the correct operation of the network. 109 Manageability issues are often referred to under the collective 110 acronym, FCAPS. This stands for: 112 - Fault management 113 - Configuration 114 - Accounting 115 - Performance 116 - Security. 118 Conventionally, Security is already covered in Internet-Drafts in its 119 own Security Considerations section, and this document does not in 120 any way diminish the need for that section. Indeed, as pointed out in 121 Section 6, a full consideration of other aspects of manageability may 122 increase the text that should be supplied in the Security 123 Considerations section. 125 The author of a Manageability Considerations section should certainly 126 consider all aspects of FCAPS. He should reflect on how the 127 manageability of a new protocol impacts the manageability and 128 operation of the entire network. Specific optional subsections (see 129 Section 2.3) should be added as necessary to describe features of 130 FCAPS that are pertinent but which are not covered by the recommended 131 subsections. More discussion of what manageability is and what may be 132 included in a Manageability Considerations section can be found in 133 [OPS-OAM]. 135 As part of documenting the manageability considerations for a new 136 protocol or for protocol extensions, the author should consider that 137 one of the objectives of specifying protocols within the IETF is to 138 ensure interoperability of implementations. This interoperability 139 extends to the manageability function so that it is an ideal that 140 there should be implementation independence between management 141 applications and managed entities. This may be promoted by the use 142 of standardized management protocols, and by the specification of 143 standard information models. 145 Note that in some contexts reference is made to the term "management 146 plane". This is used to describe the exchange of management messages 147 through management protocols (often transported by IP and IP 148 transport protocols) between management applications and the managed 149 entities such as network nodes. The management plane may use distinct 150 addressing schemes, virtual links or tunnels, or a physically 151 separate management control network. The management plane should be 152 seen as separate from, but possibly overlapping with, the control 153 plane in which signaling and routing messages are exchanged, and the 154 forwarding plane (sometimes called the data plane or user plane) in 155 which user traffic is transported. 157 2. Presence and Placement of Manageability Considerations Sections 159 2.1. Null Manageability Considerations Sections 161 In the event that there are no manageability requirements for the an 162 Internet-Draft, the draft SHOULD still contain a Manageability 163 Considerations section. The presences of this section indicates to 164 the reader that due consideration has been given to manageability, 165 and that there are no (or no new) requirements. 167 In this case, the section SHOULD contain a simple statement such as 168 "There are no new manageability requirements introduced by this 169 document," and SHOULD briefly explain why that is the case with a 170 summary of manageability mechanisms that already exist. 172 Note that a Null Manageability Considerations section may take some 173 effort to compose. It is important to demonstrate to the reader that 174 no additional manageability mechanisms are required, and it is often 175 hard to prove that something is not needed. A Null Manageability 176 Considerations section SHOULD NOT consist only of the simple 177 statement that there are no new manageability requirements. 179 If an Internet-Draft genuinely has no manageability impact, it should 180 be possible to construct a simple Null Manageability Considerations 181 section that explains why this is the case. 183 2.2. Recommended Subsections 185 If the Manageability Considerations section is not null, it SHOULD 186 contain at least the following subsections. Guidance on the content 187 of these subsections can be found in Section 3 of this document. 189 - Control of Function Through Configuration and Policy 190 - Information and Data Models, e.g. MIB modules 191 - Liveness Detection and Monitoring 192 - Verifying Correct Operation 193 - Requirements on Other Protocols and Functional Components 194 - Impact on Network Operation 196 In the event that one or more of these subsections is not relevant, 197 it SHOULD still be present, and SHOULD contain a simple statement 198 explaining why the subsection is not relevant. That is, null 199 subsections are allowed, and each should be formed following the 200 advice in Section 2.1. 202 2.3. Optional Subsections 204 The list of subsections above is not intended to be prescriptively 205 limiting. Other subsections can and SHOULD be added according to 206 the requirements of each individual Internet-Draft. If a topic does 207 not fit comfortably into any of the subsections listed, the authors 208 should be relaxed about adding new subsections as necessary. In time, 209 if an optional subsection is found to be common across many 210 Internet-Drafts, it may be added to the list in Section 2.2 in a 211 future revision of this document. 213 2.4. Placement of Manageability Considerations Sections 215 The Manageability Considerations Section SHOULD be placed immediately 216 before the Security Considerations section in any Internet-Draft. 218 3. Guidance on the Content of Subsections 220 This section gives guidance on the information to be included in each 221 of the recommended subsections listed above. Note that, just as other 222 subsections may be included, so additional information MAY also be 223 included in these subsections. 225 3.1 Control of Function Through Configuration and Policy 227 This subsection describes the functional elements that may be 228 controlled through configuration and/or policy. 230 For example, many protocol specifications include timers that are 231 used as part of operation of the protocol. These timers often have 232 default values suggested in the protocol specification and do not 233 need to be configurable. But it is often the case that the protocol 234 requires that the timers can be configured by the operator to ensure 235 specific behavior by the implementation. 237 Even if all configurable items have been described within the body of 238 the document, they SHOULD be identified in this subsection, but a 239 reference to another section of the document is sufficient if there 240 is a full description elsewhere. 242 Other protocol elements are amenable to control through the 243 application of local or network-wide policy. It is not the intention 244 that this subsection should give details of policy implementation 245 since that is covered by more general policy framework specifications 246 such as [RFC3060] and [RFC3460]. And specific frameworks for policy 247 as applicable within protocol or functional architectures are also 248 normally covered in separate documents, for example, [PCE-POLICY]. 250 However, this section SHOULD identify which protocol elements are 251 potentially subject to policy, and should give guidance on the 252 application of policy for successful operation of the protocol. 253 Where this material is already described within the body of the 254 document, this subsection SHOULD still identify the issues and 255 reference the other sections of the document. 257 3.2 Information and Data Models 259 This subsection SHOULD describe the information and data models 260 necessary for the protocol or the protocol extensions. This includes, 261 but is not necessarily limited to, the MIB modules developed 262 specifically for the protocol functions specified in the document. 264 Where new or extended MIB modules are recommended, it is helpful if 265 this section can give an overview of the items to be modeled by the 266 MIB modules. This does not require an object-by-object description of 267 all of the information that needs to be modeled, but could explain 268 the high-level 'object groupings' (perhaps to the level of suggesting 269 the MIB tables), and certainly should explain the major manageable 270 entities. For example, a protocol specification might include 271 separate roles for 'sender' and 'receiver,' and might be broken into 272 a 'session' and individual 'transactions'; if so, this section could 273 list these functionalities as separate manageable entities. 275 [RFC3444] may be useful in determining what information to include in 276 this section. 278 The description in this section can be by reference where other 279 documents already exist. 281 It should be noted that the significance of MIB modules may be 282 decreasing, but there is still a requirement to consider the managed 283 objects necessary for successful operation of the protocol or 284 protocol extensions. This means that due consideration should be 285 given not only to what objects need to be managed, but also to what 286 management model should be used. There are now several options 287 including the MIB/SNMP model, and the Netconf model being developed 288 by the NETMOD working group [YANG]. 290 3.3 Liveness Detection and Monitoring 292 Liveness detection and monitoring apply both to the control plane and 293 the data plane. 295 Mechanisms for detecting faults in the control plane or for 296 monitoring its liveness are usually built into the control plane 297 protocols or inherited from underlying data plane or forwarding plane 298 protocols. These mechanisms do not typically require additional 299 management capabilities, but are essential features for the protocol 300 to be useable and manageable. Therefore, this section SHOULD 301 highlight the mechanisms in the new protocol or protocol extensions 302 that are required in order to ensure liveness detection and 303 monitoring within the protocol. 305 Further, when a control plane fault is detected, there is often a 306 requirement to coordinate recovery action through management 307 applications or at least to record the fact in an event log. This 308 section SHOULD identify the management actions expected when the 309 protocol detects a control plane fault. 311 Where the protocol is responsible for establishing data or user plane 312 connectivity, liveness detection and monitoring usually need to be 313 achieved through other mechanisms. In some cases, these mechanisms 314 already exist within other protocols responsible for maintaining 315 lower layer connectivity, but it will often be the case that new 316 procedures are required so that failures in the data path can be 317 detected and reported rapidly allowing remedial action to be taken. 318 This section SHOULD refer to other mechanisms that are assumed to 319 provide monitoring of data plane liveness, and SHOULD identify 320 requirements for new mechanisms as appropriate. 322 This section SHOULD describe the need for liveness and detection 323 monitoring, SHOULD highlight existing tools, SHOULD identify 324 requirements and specifications for new tools (as appropriate for 325 the level of the document being written), and SHOULD describe the 326 coordination of tools with each other, with management applications, 327 and with the base protocol being specified. 329 3.4 Verifying Correct Operation 331 An important function that Operations and Management (OAM) can 332 provide is a toolset for verifying the correct operation of a 333 protocol. This may be achieved to some extent through access to 334 information and data models that report the status of the protocol 335 and the state installed on network devices. But it may also be 336 valuable to provide techniques for testing the effect that the 337 protocol has had on the network by sending data through the network 338 and observing its behavior. 340 Thus, this section SHOULD include details of how the correct 341 operation of the protocols described by the Internet-Draft can be 342 tested, and in as far as the Internet-Draft impacts on the operation 343 of the network, this section SHOULD include a discussion about how 344 the correct end-to-end operation of the network can be tested, and 345 how the correct data or forwarding plane function of each network 346 element can be verified. 348 There may be some overlap between this section and that describing 349 liveness detection and monitoring since the same tools may be used in 350 some cases. 352 3.5 Requirements on Other Protocols and Functional Components 354 The text in this section SHOULD describe the requirements that the 355 new protocol puts on other protocols and functional components, as 356 well as requirements from other protocols that have been considered 357 in designing the new protocol. This is pertinent to manageability 358 because those other protocols may already be deployed and 359 operational, and because those other protocols also need to be 360 managed. 362 It is not appropriate to consider the interaction between the new 363 protocol and all other protocols in this section, but it is important 364 to identify the specific interactions that are assumed for the 365 correct functioning of the new protocol or protocol extensions. 367 3.6 Impact on Network Operation 369 The introduction of a new protocol or extensions to an existing 370 protocol may have an impact on the operation of existing networks. 371 This section SHOULD outline such impacts (which may be positive) 372 including scaling concerns and interactions with other protocols. 374 For example, a new protocol that doubles the number of active, 375 reachable addresses in use within a network might need to be 376 considered in the light of the impact on the scalability of the IGPs 377 operating within the network. 379 A very important feature that SHOULD be addressed in this section is 380 backward compatibility. If protocol extensions are being introduced, 381 what impact will this have on a network that has an earlier version 382 of the protocol deployed? Will it be necessary to upgrade all nodes 383 in the network? Can the protocol versions operate side by side? Can 384 the new version of the protocol be tunneled through the old version? 386 Can existing services be migrated without causing a traffic hit or is 387 a 'maintenance period' required to perform the upgrade? What are the 388 configuration implications for the new and old protocol variants? 389 Where a new protocol is introduced, issues similar to backward 390 compatibility may exist and SHOULD be described. How is migration 391 from an old protocol to the new protocol achieved? Do existing 392 protocols need to be interfaced to the new protocol? 394 3.7 Other Considerations 396 Anything that is not covered in one of the recommended subsections 397 described above, but which is needed to understand the manageability 398 situation SHOULD be covered in an additional section. This may be a 399 catch-all section named 'Other Considerations', or may be one or more 400 additional optional sections as described in Section 2.3. 402 4. IANA Considerations 404 This document does not introduce any new codepoints or name spaces 405 for registration with IANA. It makes no request to IANA for action. 407 Internet-Drafts SHOULD NOT introduce new codepoints or name spaces 408 or requests for IANA action within the Manageability Considerations 409 section. 411 5. Manageability Considerations 413 This document defines Manageability Considerations sections 414 recommended for inclusion in all PCE Working Group Internet-Drafts. 415 As such, the whole document is relevant to manageability. 417 Note that the impact of the application of this document to Internet- 418 Drafts produced within the PCE Working Group should be that PCE 419 protocols and associated protocols are designed and extended with 420 manageability in mind. This should result in more robust and more 421 easily deployed protocols. 423 However, since this document does not describe any specific protocol, 424 protocol extensions, or protocol usage, no manageability 425 considerations need to be discussed here. 427 (This is an example of a null Manageability Considerations section.) 429 6. Security Considerations 431 This document is a BCP and describes the format and content of future 432 Internet-Drafts. As such it introduces no new security concerns. 434 However, there is a clear overlap between security, operations, and 435 management. The manageability aspects of security SHOULD be covered 436 within the mandatory Security Considerations of each Internet-Draft. 437 New security considerations introduced by the Manageability 438 Considerations section MUST be covered in the Security Considerations 439 section. 441 Note that fully designing a protocol before it is implemented 442 (including designing the manageability aspects) is likely to result 443 in a more robust protocol. That is a benefit to network security. 444 Retrofitting manageability to a protocol can make the protocol more 445 vulnerable to security attacks including through the new 446 manageability facilities. Therefore, the use of this document is 447 RECOMMENDED in order to help ensure the security of all protocols to 448 which it is applied. 450 7. Acknowledgements 452 This document is based on earlier work exploring the need for 453 Manageability Considerations sections in all Internet-Drafts 454 produced within the Routing Area of the IETF. That document was 455 produced by Avri Doria and Loa Andersson working with the current 456 author. Their input was both sensible and constructive. 458 Peka Savola provided valuable feedback on an early versions of the 459 original document. Thanks to Bert Wijnen, Dan Romascanu, David 460 Harrington, Lou Berger, Spender Dawkins, Tom Petch, Matthew Meyer, 461 and Dimitri Papdimitriou for their comments. 463 8. Intellectual Property Considerations 465 The IETF takes no position regarding the validity or scope of any 466 Intellectual Property Rights or other rights that might be claimed to 467 pertain to the implementation or use of the technology described in 468 this document or the extent to which any license under such rights 469 might or might not be available; nor does it represent that it has 470 made any independent effort to identify any such rights. Information 471 on the procedures with respect to rights in RFC documents can be 472 found in BCP 78 and BCP 79. 474 Copies of IPR disclosures made to the IETF Secretariat and any 475 assurances of licenses to be made available, or the result of an 476 attempt made to obtain a general license or permission for the use of 477 such proprietary rights by implementers or users of this 478 specification can be obtained from the IETF on-line IPR repository at 479 http://www.ietf.org/ipr. 481 The IETF invites any interested party to bring to its attention any 482 copyrights, patents or patent applications, or other proprietary 483 rights that may cover technology that may be required to implement 484 this standard. Please address the information to the IETF at 485 ietf-ipr@ietf.org. 487 9. References 489 9.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, March 1997. 494 9.2. Informative References 496 [RFC3060] B. Moore, et al., Policy Information Model Version1 497 Specification, RFC 3060, February 2001. 499 [RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM) 500 Extensions", RFC 3460, January 2003. 502 [RFC3444] Pras, A., and Schoenwaelder, J., "On the Difference 503 between Information Models and Data Models", RFC 3444, 504 January 2003. 506 [OPS-OAM] Harrington, D., "Guidelines for Considering Operations and 507 Management of New Protocols", draft-ietf-opsawg-operations- 508 and-management", work in progress. 510 [PCE-POLICY] Bryskin, I., Papadimitriou, P. and Berger, L., "Policy- 511 Enabled Path Computation Framework", draft-ietf-pce- 512 policy-enabled-path-comp, work in progress. 514 [YANG] M. Bjorklund (Ed.), "YANG - A data modeling language for 515 NETCONF", draft-ietf-netmod-yang, work in progress. 517 10. Author's Address 519 Adrian Farrel 520 Old Dog Consulting 521 EMail: adrian@olddog.co.uk 523 11. Full Copyright Statement 525 Copyright (C) The IETF Trust (2008). 527 This document is subject to the rights, licenses and restrictions 528 contained in BCP 78, and except as set forth therein, the authors 529 retain all their rights. 531 This document and the information contained herein are provided on an 532 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 533 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 534 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 535 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 536 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 537 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 539 Appendix A - Example Manageability Considerations Sections 541 Readers are referred to the following documents for example 542 Manageability Considerations sections that received positive comments 543 during IESG review: 545 Farrel, A., Vasseur, J.P., and Ash., J., "A Path Computation Element 546 (PCE)-Based Architecture", RFC 4655, August 2006. 548 J.L. Le Roux, Ed., "Requirements for Path Computation Element (PCE) 549 Discovery", RFC 4674, October 2006. 551 Le Roux, J.L., Vasseur, J.P., Ikejiri, Y., and Zhang, R., "OSPF 552 Protocol Extensions for Path Computation Element (PCE) Discovery", 553 RFC 5088, January 2008. 555 Le Roux, J.L. and Vasseur, J.P. "Path Computation Element (PCE) 556 Communication Protocol (PCEP)", draft-ietf-pce-pcep, work in 557 progress. 559 Oki, E., Le Roux, J.L., and Farrel, A. "Framework for PCE-Based 560 Inter-Layer MPLS and GMPLS Traffic Engineering", draft-ietf-pce- 561 inter-layer-frwk, work in progress. 563 This list may be extended in future versions of this document.