idnits 2.17.1 draft-ietf-pce-manageability-requirements-03.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 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 477. 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 (February 19, 2008) is 5910 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: February 19, 2008 6 Expires: August 19, 2008 8 Inclusion of Manageability Sections in PCE Working Group Drafts 10 draft-ietf-pce-manageability-requirements-03.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 3.3 Liveness Detection and Monitoring 283 Liveness detection and monitoring apply both to the control plane and 284 the data plane. 286 Mechanisms for detecting faults in the control plane or for 287 monitoring its liveness are usually built into the control plane 288 protocols or inherited from underlying data plane or forwarding plane 289 protocols. These mechanisms do not typically require additional 290 management capabilities, but are essential features for the protocol 291 to be useable and manageable. Therefore, this section SHOULD 292 highlight the mechanisms in the new protocol or protocol extensions 293 that are required in order to ensure liveness detection and 294 monitoring within the protocol. 296 Further, when a control plane fault is detected, there is often a 297 requirement to coordinate recovery action through management 298 applications or at least to record the fact in an event log. This 299 section SHOULD identify the management actions expected when the 300 protocol detects a control plane fault. 302 Where the protocol is responsible for establishing data or user plane 303 connectivity, liveness detection and monitoring usually need to be 304 achieved through other mechanisms. In some cases, these mechanisms 305 already exist within other protocols responsible for maintaining 306 lower layer connectivity, but it will often be the case that new 307 procedures are required so that failures in the data path can be 308 detected and reported rapidly allowing remedial action to be taken. 309 This section SHOULD refer to other mechanisms that are assumed to 310 provide monitoring of data plane liveness, and SHOULD identify 311 requirements for new mechanisms as appropriate. 313 This section SHOULD describe the need for liveness and detection 314 monitoring, SHOULD highlight existing tools, SHOULD identify 315 requirements and specifications for new tools (as appropriate for 316 the level of the document being written), and SHOULD describe the 317 coordination of tools with each other, with management applications, 318 and with the base protocol being specified. 320 3.4 Verifying Correct Operation 322 An important function that Operations and Management (OAM) can 323 provide is a toolset for verifying the correct operation of a 324 protocol. This may be achieved to some extent through access to 325 information and data models that report the status of the protocol 326 and the state installed on network devices. But it may also be 327 valuable to provide techniques for testing the effect that the 328 protocol has had on the network by sending data through the network 329 and observing its behavior. 331 Thus, this section SHOULD include details of how the correct 332 operation of the protocols described by the Internet-Draft can be 333 tested, and in as far as the Internet-Draft impacts on the operation 334 of the network, this section SHOULD include a discussion about how 335 the correct end-to-end operation of the network can be tested, and 336 how the correct data or forwarding plane function of each network 337 element can be verified. 339 There may be some overlap between this section and that describing 340 liveness detection and monitoring since the same tools may be used in 341 some cases. 343 3.5 Requirements on Other Protocols and Functional Components 345 The text in this section SHOULD describe the requirements that the 346 new protocol puts on other protocols and functional components, as 347 well as requirements from other protocols that have been considered 348 in designing the new protocol. This is pertinent to manageability 349 because those other protocols may already be deployed and 350 operational, and because those other protocols also need to be 351 managed. 353 It is not appropriate to consider the interaction between the new 354 protocol and all other protocols in this section, but it is important 355 to identify the specific interactions that are assumed for the 356 correct functioning of the new protocol or protocol extensions. 358 3.6 Impact on Network Operation 360 The introduction of a new protocol or extensions to an existing 361 protocol may have an impact on the operation of existing networks. 362 This section SHOULD outline such impacts (which may be positive) 363 including scaling concerns and interactions with other protocols. 365 For example, a new protocol that doubles the number of active, 366 reachable addresses in use within a network might need to be 367 considered in the light of the impact on the scalability of the IGPs 368 operating within the network. 370 A very important feature that SHOULD be addressed in this section is 371 backward compatibility. If protocol extensions are being introduced, 372 what impact will this have on a network that has an earlier version 373 of the protocol deployed? Will it be necessary to upgrade all nodes 374 in the network? Can the protocol versions operate side by side? Can 375 the new version of the protocol be tunneled through the old version? 377 Can existing services be migrated without causing a traffic hit or is 378 a 'maintenance period' required to perform the upgrade? What are the 379 configuration implications for the new and old protocol variants? 381 Where a new protocol is introduced, issues similar to backward 382 compatibility may exist and SHOULD be described. How is migration 383 from an old protocol to the new protocol achieved? Do existing 384 protocols need to be interfaced to the new protocol? 386 3.7 Other Considerations 388 Anything that is not covered in one of the recommended subsections 389 described above, but which is needed to understand the manageability 390 situation SHOULD be covered in an additional section. This may be a 391 catch-all section named 'Other Considerations', or may be one or more 392 additional optional sections as described in Section 2.3. 394 4. IANA Considerations 396 This document does not introduce any new codepoints or name spaces 397 for registration with IANA. It makes no request to IANA for action. 399 Internet-Drafts SHOULD NOT introduce new codepoints or name spaces 400 or requests for IANA action within the Manageability Considerations 401 section. 403 5. Manageability Considerations 405 This document defines Manageability Considerations sections 406 recommended for inclusion in all PCE Working Group Internet-Drafts. 407 As such, the whole document is relevant to manageability. 409 Note that the impact of the application of this document to Internet- 410 Drafts produced within the PCE Working Group should be that PCE 411 protocols and associated protocols are designed and extended with 412 manageability in mind. This should result in more robust and more 413 easily deployed protocols. 415 However, since this document does not describe any specific protocol, 416 protocol extensions, or protocol usage, no manageability 417 considerations need to be discussed here. 419 (This is an example of a null Manageability Considerations section.) 421 6. Security Considerations 423 This document is a BCP and describes the format and content of future 424 Internet-Drafts. As such it introduces no new security concerns. 426 However, there is a clear overlap between security, operations, and 427 management. The manageability aspects of security SHOULD be covered 428 within the mandatory Security Considerations of each Internet-Draft. 429 New security considerations introduced by the Manageability 430 Considerations section MUST be covered in the Security Considerations 431 section. 433 Note that fully designing a protocol before it is implemented 434 (including designing the manageability aspects) is likely to result 435 in a more robust protocol. That is a benefit to network security. 436 Retrofitting manageability to a protocol can make the protocol more 437 vulnerable to security attacks including through the new 438 manageability facilities. Therefore, the use of this document is 439 RECOMMENDED in order to help ensure the security of all protocols to 440 which it is applied. 442 7. Acknowledgements 444 This document is based on earlier work exploring the need for 445 Manageability Considerations sections in all Internet-Drafts 446 produced within the Routing Area of the IETF. That document was 447 produced by Avri Doria and Loa Andersson working with the current 448 author. Their input was both sensible and constructive. 450 Peka Savola provided valuable feedback on an early versions of the 451 original document. Thanks to Bert Wijnen, Dan Romascanu, David 452 Harrington, Lou Berger, Spender Dawkins, Tom Petch, Matthew Meyer, 453 and Dimitri Papdimitriou for their comments. 455 8. Intellectual Property Considerations 457 The IETF takes no position regarding the validity or scope of any 458 Intellectual Property Rights or other rights that might be claimed to 459 pertain to the implementation or use of the technology described in 460 this document or the extent to which any license under such rights 461 might or might not be available; nor does it represent that it has 462 made any independent effort to identify any such rights. Information 463 on the procedures with respect to rights in RFC documents can be 464 found in BCP 78 and BCP 79. 466 Copies of IPR disclosures made to the IETF Secretariat and any 467 assurances of licenses to be made available, or the result of an 468 attempt made to obtain a general license or permission for the use of 469 such proprietary rights by implementers or users of this 470 specification can be obtained from the IETF on-line IPR repository at 471 http://www.ietf.org/ipr. 473 The IETF invites any interested party to bring to its attention any 474 copyrights, patents or patent applications, or other proprietary 475 rights that may cover technology that may be required to implement 476 this standard. Please address the information to the IETF at 477 ietf-ipr@ietf.org. 479 9. References 481 9.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 9.2. Informative References 488 [RFC3060] B. Moore, et al., Policy Information Model Version1 489 Specification, RFC 3060, February 2001. 491 [RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM) 492 Extensions", RFC 3460, January 2003. 494 [RFC3444] Pras, A., and Schoenwaelder, J., "On the Difference 495 between Information Models and Data Models", RFC 3444, 496 January 2003. 498 [OPS-OAM] Harrington, D., "Guidelines for Considering Operations and 499 Management of New Protocols", draft-harrington-operations- 500 and-management", work in progress. 502 [PCE-POLICY] Bryskin, I., Papadimitriou, P. and Berger, L., "Policy- 503 Enabled Path Computation Framework", draft-ietf-pce- 504 policy-enabled-path-comp, work in progress. 506 10. Author's Address 508 Adrian Farrel 509 Old Dog Consulting 510 EMail: adrian@olddog.co.uk 512 11. Full Copyright Statement 514 Copyright (C) The IETF Trust (2008). 516 This document is subject to the rights, licenses and restrictions 517 contained in BCP 78, and except as set forth therein, the authors 518 retain all their rights. 520 This document and the information contained herein are provided on an 521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 523 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 524 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 525 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 528 Appendix A - Example Manageability Considerations Sections 530 Readers are referred to the following documents for example 531 Manageability Considerations sections that received positive comments 532 during IESG review: 534 Farrel, A., Vasseur, J.P., and Ash., J., "A Path Computation Element 535 (PCE)-Based Architecture", RFC 4655, August 2006. 537 J.L. Le Roux, Ed., "Requirements for Path Computation Element (PCE) 538 Discovery", RFC 4674, October 2006. 540 Le Roux, J.L., Vasseur, J.P., Ikejiri, Y., and Zhang, R., "OSPF 541 Protocol Extensions for Path Computation Element (PCE) Discovery", 542 RFC 5088, January 2008. 544 Le Roux, J.L. and Vasseur, J.P. "Path Computation Element (PCE) 545 Communication Protocol (PCEP)", draft-ietf-pce-pcep, work in 546 progress. 548 Oki, E., Le Roux, J.L., and Farrel, A. "Framework for PCE-Based 549 Inter-Layer MPLS and GMPLS Traffic Engineering", draft-ietf-pce- 550 inter-layer-frwk, work in progress. 552 This list may be extended in future versions of this document.