idnits 2.17.1 draft-ietf-pce-manageability-requirements-11.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 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 (September 27, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Farrel 2 Internet Draft Old Dog Consulting 3 Intended Status: Historic 4 Created: September 27, 2010 5 Expires: March 27, 2011 7 Inclusion of Manageability Sections in PCE Working Group Drafts 9 draft-ietf-pce-manageability-requirements-11.txt 11 Abstract 13 It has often been the case that manageability considerations have 14 been retrofitted to protocols after they have been specified, 15 standardized, implemented, or deployed. This is sub-optimal. 16 Similarly, new protocols or protocol extensions are frequently 17 designed without due consideration of manageability requirements. 19 The Operations Area has developed "Guidelines for Considering 20 Operations and Management of New Protocols and Protocol Extensions" 21 (RFC 5706), and those guidelines have been adopted by the PCE Working 22 Group. 24 Previously, the PCE Working Group used the recommendations contained 25 in this document to guide authors of Internet-Drafts on the contents 26 of "Manageability Considerations" sections in their work. This 27 document is retained for historic reference. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on January 14, 2011. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 1. Introduction 69 This document is produced for historic reference. 71 When new protocols or protocol extensions are developed, it is often 72 the case that not enough consideration is given to the manageability 73 of the protocols or to the way in which they will be operated in the 74 network. The result is that manageability considerations are only 75 understood once the protocols have been implemented, and sometimes 76 not until after they have been deployed. 78 The resultant attempts to retrofit manageability mechanisms are not 79 always easy or architecturally pleasant. Furthermore, it is possible 80 that certain protocol designs make manageability particularly hard to 81 achieve. 83 Recognizing that manageability is fundamental to the utility and 84 success of protocols designed within the IETF, and that simply 85 defining a MIB module does not necessarily provide adequate 86 manageability, this document was developed to define recommendations 87 for the inclusion of Manageability Considerations sections in all 88 Internet-Drafts produced within the PCE Working Group. It was the 89 intention that meeting these recommendations would ensure that proper 90 consideration was given to the support of manageability at all stages 91 of the protocol development process from Requirements and 92 Architecture, through Specification and Applicability. 94 It is clear that the presence of such a section in an Internet-Draft 95 does not guarantee that the protocol will be well-designed or 96 manageable. However, the inclusion of this section will ensure that 97 the authors have the opportunity to consider the issues, and by 98 reading the material in this document they will gain some guidance. 100 This document was developed within the PCE Working Group and was used 101 to help guide the authors and editors within the working group to 102 produce Manageability Considerations sections in the Internet-Drafts 103 and RFCs produced by the working group. 105 [RFC5706] presents general guidance from the IETF's Operations Area 106 for considering Operations and Management of new protocols and 107 protocol extensions. It has been adopted by the PCE Working Group to 108 provide guidance to editors and authors within the Working Group and 109 so this document is no longer required. However, the working group 110 considers that it will be useful to archive this document as Historic 111 for future reference. 113 1.1. Requirements Notation 115 This document is not a protocol specification. The key words "MUST", 116 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 117 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 118 interpreted as described in [RFC2119] in order that the contents of a 119 manageability considerations section can be clearly understood. 121 1.2. What is Manageability? 123 In this context, "manageability" is used to refer to the interactions 124 between a network operator (a human or an application) and the 125 network components (hosts, routers, switches, applications, and 126 protocols) performed to ensure the correct operation of the network. 128 Manageability issues are often referred to under the collective 129 acronym, FCAPS [X.700]. This stands for: 131 - Fault management 132 - Configuration 133 - Accounting 134 - Performance 135 - Security. 137 Conventionally, Security is already covered in Internet-Drafts in its 138 own Security Considerations section, and this document does not in 139 any way diminish the need for that section. Indeed, as pointed out in 140 Section 6, a full consideration of other aspects of manageability may 141 increase the text that should be supplied in the Security 142 Considerations section. 144 The author of a Manageability Considerations section should certainly 145 consider all aspects of FCAPS. The author should reflect on how the 146 manageability of a new protocol impacts the manageability and 147 operation of the entire network. Specific optional subsections (see 148 Section 2.3) should be added as necessary to describe features of 149 FCAPS that are pertinent but which are not covered by the recommended 150 subsections. More discussion of what manageability is and what may be 151 included in a Manageability Considerations section can be found in 152 [RFC5706]. 154 As part of documenting the manageability considerations for a new 155 protocol or for protocol extensions, the author should consider that 156 one of the objectives of specifying protocols within the IETF is to 157 ensure interoperability of implementations. This interoperability 158 extends to the manageability function so that it is an ideal that 159 there should be implementation independence between management 160 applications and managed entities. This may be promoted by the use 161 of standardized management protocols, and by the specification of 162 standard information models. 164 Note that in some contexts reference is made to the term "management 165 plane". This is used to describe the exchange of management messages 166 through management protocols (often transported by IP and by IP 167 transport protocols) between management applications and the managed 168 entities such as network nodes. The management plane may use distinct 169 addressing schemes, virtual links or tunnels, or a physically 170 separate management control network. The management plane should be 171 seen as separate from, but possibly overlapping with, the control 172 plane in which signaling and routing messages are exchanged, and the 173 forwarding plane (sometimes called the data plane or user plane) in 174 which user traffic is transported. 176 2. Presence and Placement of Manageability Considerations Sections 178 Note that examples of the sections described here can be found in the 179 documents listed in Appendix A. 181 2.1. Null Manageability Considerations Sections 183 In the event that there are no manageability requirements for the an 184 Internet-Draft, the draft SHOULD still contain a Manageability 185 Considerations section. The presences of this section indicates to 186 the reader that due consideration has been given to manageability, 187 and that there are no (or no new) requirements. 189 In this case, the section SHOULD contain a simple statement such as 190 "There are no new manageability requirements introduced by this 191 document," and SHOULD briefly explain why that is the case with a 192 summary of manageability mechanisms that already exist. 194 Note that a Null Manageability Considerations section may take some 195 effort to compose. It is important to demonstrate to the reader that 196 no additional manageability mechanisms are required, and it is often 197 hard to prove that something is not needed. A Null Manageability 198 Considerations section SHOULD NOT consist only of the simple 199 statement that there are no new manageability requirements. 201 If an Internet-Draft genuinely has no manageability impact, it should 202 be possible to construct a simple Null Manageability Considerations 203 section that explains why this is the case. 205 2.2. Recommended Subsections 207 If the Manageability Considerations section is not null, it SHOULD 208 contain at least the following subsections. Guidance on the content 209 of these subsections can be found in Section 3 of this document. 211 - Control of Function Through Configuration and Policy 212 - Information and Data Models, e.g. MIB modules 213 - Liveness Detection and Monitoring 214 - Verifying Correct Operation 215 - Requirements on Other Protocols and Functional Components 216 - Impact on Network Operation 218 In the event that one or more of these subsections is not relevant, 219 it SHOULD still be present, and SHOULD contain a simple statement 220 explaining why the subsection is not relevant. That is, null 221 subsections are allowed, and each should be formed following the 222 advice in Section 2.1. 224 2.3. Optional Subsections 226 The list of subsections above is not intended to be prescriptively 227 limiting. Other subsections can and SHOULD be added according to 228 the requirements of each individual Internet-Draft. If a topic does 229 not fit comfortably into any of the subsections listed, the authors 230 should be relaxed about adding new subsections as necessary. 232 2.4. Placement of Manageability Considerations Sections 234 The Manageability Considerations Section SHOULD be placed immediately 235 before the Security Considerations section in any Internet-Draft. 237 3. Guidance on the Content of Subsections 239 This section gives guidance on the information to be included in each 240 of the recommended subsections listed above. Note that, just as other 241 subsections may be included, so additional information MAY also be 242 included in these subsections. 244 3.1 Control of Function Through Configuration and Policy 246 This subsection describes the functional elements that may be 247 controlled through configuration and/or policy. 249 For example, many protocol specifications include timers that are 250 used as part of operation of the protocol. These timers often have 251 default values suggested in the protocol specification and do not 252 need to be configurable. But it is often the case that the protocol 253 requires that the timers can be configured by the operator to ensure 254 specific behavior by the implementation. 256 Even if all configurable items have been described within the body of 257 the document, they SHOULD be identified in this subsection, but a 258 reference to another section of the document is sufficient if there 259 is a full description elsewhere. 261 Other protocol elements are amenable to control through the 262 application of local or network-wide policy. It is not the intention 263 that this subsection should give details of policy implementation 264 since that is covered by more general policy framework specifications 265 such as [RFC3060] and [RFC3460]. And specific frameworks for policy 266 as applicable within protocol or functional architectures are also 267 normally covered in separate documents, for example, [RFC5394]. 269 However, this section SHOULD identify which protocol elements are 270 potentially subject to policy, and should give guidance on the 271 application of policy for successful operation of the protocol. 272 Where this material is already described within the body of the 273 document, this subsection SHOULD still identify the issues and 274 reference the other sections of the document. 276 3.2 Information and Data Models 278 This subsection SHOULD describe the information and data models 279 necessary for the protocol or the protocol extensions. This includes, 280 but is not necessarily limited to, the MIB modules developed 281 specifically for the protocol functions specified in the document. 283 Where new or extended MIB modules are recommended, it is helpful if 284 this section can give an overview of the items to be modeled by the 285 MIB modules. This does not require an object-by-object description of 286 all of the information that needs to be modeled, but could explain 287 the high-level 'object groupings' (perhaps to the level of suggesting 288 the MIB tables), and certainly should explain the major manageable 289 entities. For example, a protocol specification might include 290 separate roles for 'sender' and 'receiver,' and might be broken into 291 a 'session' and individual 'transactions'; if so, this section could 292 list these functionalities as separate manageable entities. 294 [RFC3444] may be useful in determining what information to include in 295 this section. 297 The description in this section can be by reference where other 298 documents already exist. 300 It should be noted that the significance of MIB modules may be 301 decreasing, but there is still a requirement to consider the managed 302 objects necessary for successful operation of the protocol or 303 protocol extensions. This means that due consideration should be 304 given not only to what objects need to be managed, but also to what 305 management model should be used. There are now several options 306 including the MIB/SNMP model, and the Netconf model being developed 307 by the NETMOD working group [YANG]. 309 3.3 Liveness Detection and Monitoring 311 Liveness detection and monitoring apply both to the control plane and 312 the data plane. 314 Mechanisms for detecting faults in the control plane or for 315 monitoring its liveness are usually built into the control plane 316 protocols or inherited from underlying data plane or forwarding plane 317 protocols. These mechanisms do not typically require additional 318 management capabilities, but are essential features for the protocol 319 to be usable and manageable. Therefore, this section SHOULD highlight 320 the mechanisms in the new protocol or protocol extensions that are 321 required in order to ensure liveness detection and monitoring within 322 the protocol. 324 Further, when a control plane fault is detected, there is often a 325 requirement to coordinate recovery action through management 326 applications or at least to record the fact in an event log. This 327 section SHOULD identify the management actions expected when the 328 protocol detects a control plane fault. 330 Where the protocol is responsible for establishing data or user plane 331 connectivity, liveness detection and monitoring usually need to be 332 achieved through other mechanisms. In some cases, these mechanisms 333 already exist within other protocols responsible for maintaining 334 lower layer connectivity, but it will often be the case that new 335 procedures are required so that failures in the data path can be 336 detected and reported rapidly allowing remedial action to be taken. 337 This section SHOULD refer to other mechanisms that are assumed to 338 provide monitoring of data plane liveness, and SHOULD identify 339 requirements for new mechanisms as appropriate. 341 This section SHOULD describe the need for liveness and detection 342 monitoring, SHOULD highlight existing tools, SHOULD identify 343 requirements and specifications for new tools (as appropriate for 344 the level of the document being written), and SHOULD describe the 345 coordination of tools with each other, with management applications, 346 and with the base protocol being specified. 348 3.4 Verifying Correct Operation 350 An important function that Operations and Management (OAM) can 351 provide is a toolset for verifying the correct operation of a 352 protocol. This may be achieved to some extent through access to 353 information and data models that report the status of the protocol 354 and the state installed on network devices. But it may also be 355 valuable to provide techniques for testing the effect that the 356 protocol has had on the network by sending data through the network 357 and observing its behavior. 359 Thus, this section SHOULD include details of how the correct 360 operation of the protocols described by the Internet-Draft can be 361 tested, and in as far as the Internet-Draft impacts on the operation 362 of the network, this section SHOULD include a discussion about how 363 the correct end-to-end operation of the network can be tested, and 364 how the correct data or forwarding plane function of each network 365 element can be verified. 367 There may be some overlap between this section and that describing 368 liveness detection and monitoring since the same tools may be used in 369 some cases. 371 3.5 Requirements on Other Protocols and Functional Components 373 The text in this section SHOULD describe the requirements that the 374 new protocol puts on other protocols and functional components, as 375 well as requirements from other protocols that have been considered 376 in designing the new protocol. This is pertinent to manageability 377 because those other protocols may already be deployed and 378 operational, and because those other protocols also need to be 379 managed. 381 It is not appropriate to consider the interaction between the new 382 protocol and all other protocols in this section, but it is important 383 to identify the specific interactions that are assumed for the 384 correct functioning of the new protocol or protocol extensions. 386 3.6 Impact on Network Operation 388 The introduction of a new protocol or extensions to an existing 389 protocol may have an impact on the operation of existing networks. 390 This section SHOULD outline such impacts (which may be positive) 391 including scaling concerns and interactions with other protocols. 393 For example, a new protocol that doubles the number of active, 394 reachable addresses in use within a network might need to be 395 considered in the light of the impact on the scalability of the IGPs 396 operating within the network. 398 A very important feature that SHOULD be addressed in this section is 399 backward compatibility. If protocol extensions are being introduced, 400 what impact will this have on a network that has an earlier version 401 of the protocol deployed? Will it be necessary to upgrade all nodes 402 in the network? Can the protocol versions operate side by side? Can 403 the new version of the protocol be tunneled through the old version? 405 Can existing services be migrated without causing a traffic hit or is 406 a 'maintenance period' required to perform the upgrade? What are the 407 configuration implications for the new and old protocol variants? 409 Where a new protocol is introduced, issues similar to backward 410 compatibility may exist and SHOULD be described. How is migration 411 from an old protocol to the new protocol achieved? Do existing 412 protocols need to be interfaced to the new protocol? 414 3.7 Other Considerations 416 Anything that is not covered in one of the recommended subsections 417 described above, but which is needed to understand the manageability 418 situation SHOULD be covered in an additional section. This may be a 419 catch-all section named 'Other Considerations', or may be one or more 420 additional optional sections as described in Section 2.3. 422 4. IANA Considerations 424 This document does not introduce any new codepoints or name spaces 425 for registration with IANA. It makes no request to IANA for action. 427 Internet-Drafts SHOULD NOT introduce new codepoints or name spaces 428 or requests for IANA action within the Manageability Considerations 429 section. 431 5. Manageability Considerations 433 This document defines Manageability Considerations sections 434 recommended for inclusion in all PCE Working Group Internet-Drafts. 435 As such, the whole document is relevant to manageability. 437 Note that the impact of the application of this document to Internet- 438 Drafts produced within the PCE Working Group should be that PCE 439 protocols and associated protocols are designed and extended with 440 manageability in mind. This should result in more robust and more 441 easily deployed protocols. 443 However, since this document does not describe any specific protocol, 444 protocol extensions, or protocol usage, no manageability 445 considerations need to be discussed here. 447 (This is an example of a null Manageability Considerations section.) 449 6. Security Considerations 451 This document is Historic and describes the format and content of 452 Internet-Drafts. As such it introduces no new security concerns. 454 However, there is a clear overlap between security, operations, and 455 management. The manageability aspects of security SHOULD be covered 456 within the mandatory Security Considerations of each Internet-Draft. 457 New security considerations introduced by the Manageability 458 Considerations section MUST be covered in the Security Considerations 459 section. 461 Note that fully designing a protocol before it is implemented 462 (including designing the manageability aspects) is likely to result 463 in a more robust protocol. That is a benefit to network security. 464 Retrofitting manageability to a protocol can make the protocol more 465 vulnerable to security attacks including through the new 466 manageability facilities. Therefore, the use of this document is 467 RECOMMENDED in order to help ensure the security of all protocols to 468 which it is applied. 470 7. Acknowledgements 472 This document is based on earlier work exploring the need for 473 Manageability Considerations sections in all Internet-Drafts 474 produced within the Routing Area of the IETF. That document was 475 produced by Avri Doria and Loa Andersson working with the current 476 author. Their input was both sensible and constructive. 478 Peka Savola provided valuable feedback on an early versions of the 479 original document. Thanks to Bert Wijnen, Dan Romascanu, David 480 Harrington, Lou Berger, Spender Dawkins, Tom Petch, Matthew Meyer, 481 Dimitri Papdimitriou, Stewart Bryant, and Jamal Hadi Salim for their 482 comments. 484 Thanks to the PCE working group for adopting the ideas contained in 485 this document and for including Manageability Considerations sections 486 in their Internet-Drafts and RFCs. 488 8. References 490 8.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997. 495 8.2. Informative References 497 [RFC3060] B. Moore, et al., Policy Information Model Version1 498 Specification, RFC 3060, February 2001. 500 [RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM) 501 Extensions", RFC 3460, January 2003. 503 [RFC3444] Pras, A., and Schoenwaelder, J., "On the Difference 504 between Information Models and Data Models", RFC 3444, 505 January 2003. 507 [RFC5394] Bryskin, I., Papadimitriou, P. and Berger, L., "Policy- 508 Enabled Path Computation Framework", RFC 5394, December 509 2008. 511 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 512 Management of New Protocols and Protocol Extensions", 513 RFC 5706, November 2009. 515 [X.700] CCITT Recommendation X.700 (1992), Management framework for 516 Open Systems Interconnection (OSI) for CCITT applications. 518 [YANG] M. Bjorklund (Ed.), "YANG - A data modeling language for 519 NETCONF", draft-ietf-netmod-yang, work in progress. 521 9. Author's Address 523 Adrian Farrel 524 Old Dog Consulting 525 EMail: adrian@olddog.co.uk 527 Appendix A - Example Manageability Considerations Sections 529 Readers are referred to the following documents for example 530 Manageability Considerations sections that received positive comments 531 during IESG review: 533 Farrel, A., Vasseur, J.P., and Ash., J., "A Path Computation Element 534 (PCE)-Based Architecture", RFC 4655, August 2006. 536 J.L. Le Roux, Ed., "Requirements for Path Computation Element (PCE) 537 Discovery", RFC 4674, October 2006. 539 Le Roux, J.L., Vasseur, J.P., Ikejiri, Y., and Zhang, R., "OSPF 540 Protocol Extensions for Path Computation Element (PCE) Discovery", 541 RFC 5088, January 2008. 543 Le Roux, J.L. and Vasseur, J.P. "Path Computation Element (PCE) 544 Communication Protocol (PCEP)", RFC 5440, March 2009. 546 Bradford R., Vasseur, J.P., and Farrel, A., "Preserving Topology 547 Confidentiality in Inter-Domain Path Computation Using a Key-Based 548 Mechanism", RFC 5520, April 2009. 550 Oki, E., Le Roux, J.L., and Farrel, A. "Framework for PCE-Based 551 Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 552 2009.