idnits 2.17.1 draft-ietf-bfd-tc-mib-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 7, 2010) is 4979 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: 'RFC2580' is mentioned on line 107, but not defined == Unused Reference: 'RFC3413' is defined on line 385, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Nadeau 2 Internet Draft BT 3 Intended status: Standards Track Z. Ali 4 Expires: March 6, 2010 Cisco Systems, Inc. 5 N. Akiya 6 Cisco Systems G.K. 7 September 7, 2010 9 Definitions of Textual Conventions (TCs) for 10 Bidirectional Forwarding Detection (BFD) Management 11 draft-ietf-bfd-tc-mib-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described 55 in Section 4.e of the Trust Legal Provisions and are provided 56 without warranty as described in the Simplified BSD License. 58 Abstract 60 This draft defines a Management Information Base (MIB) module which 61 contains Textual Conventions to represent commonly used Bidirectional 62 Forwarding Detection (BFD) management information. The intent is 63 that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD 64 related MIB modules that would otherwise define their own 65 representations. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. The Internet-Standard Management Framework . . . . . . . . . . 3 71 3. BFD Textual Conventions MIB Definitions . . . . . . . . . . . 3 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 6.2. Informative References . . . . . . . . . . . . . . . . . 8 77 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 79 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 This document defines a MIB module which contains Textual Conventions 84 for Bidirectional Forwarding Detection (BFD) protocols. These 85 Textual Conventions should be imported by MIB modules which manage 86 BFD protocols. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 For an introduction to the concepts of BFD, see [BFD], [BFD-1HOP] and 93 [BFD-MH]. 95 2. The Internet-Standard Management Framework 97 For a detailed overview of the documents that describe the current 98 Internet-Standard Management Framework, please refer to section 7 of 99 [RFC3410]. 101 Managed objects are accessed via a virtual information store, termed 102 the Management Information Base or MIB. MIB objects are generally 103 accessed through the Simple Network Management Protocol (SNMP). 104 Objects in the MIB are defined using the mechanisms defined in the 105 Structure of Management Information (SMI). This memo specifies a MIB 106 module that is compliant to the SMIv2, which is described in STD 58, 107 [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. 109 3. BFD Textual Conventions MIB Definitions 111 BFD-TC-STD-MIB DEFINITIONS ::= BEGIN 113 IMPORTS 114 MODULE-IDENTITY, mib-2, Unsigned32 115 FROM SNMPv2-SMI -- [RFC2578] 117 TEXTUAL-CONVENTION 118 FROM SNMPv2-TC; -- [RFC2579] 120 bfdTCStdMib MODULE-IDENTITY 121 LAST-UPDATED "201009071200Z" -- 7 September 2010 12:00:00 EST 122 ORGANIZATION "IETF Bidirectional Forwarding Detection 123 Working Group" 124 CONTACT-INFO 125 "Thomas D. Nadeau 126 BT 127 Email: tnadeau@lucidvision.com 129 Zafar Ali 130 Cisco Systems, Inc. 131 Email: zali@cisco.com 133 Nobo Akiya 134 Cisco Systems, G.K. 135 Email: nobo@cisco.com" 136 DESCRIPTION 137 "This MIB module defines TEXTUAL-CONVENTIONs for concepts 138 used in Bidirectional Forwarding Detection (BFD) 139 protocols." 140 REVISION "201009071200Z" -- 7 September 2010 12:00:00 EST 141 DESCRIPTION 142 "Initial version. Published as RFC xxxx." 143 -- RFC Ed.: RFC-editor pls fill in xxxx 144 ::= { mib-2 XXX } 145 -- RFC Ed.: assigned by IANA, see section 5 for details 147 BfdSessIndexTC ::= TEXTUAL-CONVENTION 148 DISPLAY-HINT "d" 149 STATUS current 150 DESCRIPTION 151 "An index used to uniquely identify BFD sessions." 152 SYNTAX Unsigned32 (1..4294967295) 154 BfdIntervalTC ::= TEXTUAL-CONVENTION 155 DISPLAY-HINT "d" 156 STATUS current 157 DESCRIPTION 158 "The BFD interval in microseconds." 159 SYNTAX Unsigned32 (0..4294967295) 161 BfdMultiplierTC ::= TEXTUAL-CONVENTION 162 DISPLAY-HINT "d" 163 STATUS current 164 DESCRIPTION 165 "The BFD failure detection multiplier." 166 SYNTAX Unsigned32 (1..255) 168 BfdDiagTC ::= TEXTUAL-CONVENTION 169 STATUS current 170 DESCRIPTION 171 "A common BFD diagnostic code." 172 SYNTAX INTEGER { 173 noDiagnostic(0), 174 controlDetectionTimeExpired(1), 175 echoFunctionFailed(2), 176 neighborSignaledSessionDown(3), 177 forwardingPlaneReset(4), 178 pathDown(5), 179 concatenatedPathDown(6), 180 administrativelyDown(7), 181 reverseConcatenatedPathDown(8) 182 } 184 BfdSessTypeTC ::= TEXTUAL-CONVENTION 185 STATUS current 186 DESCRIPTION 187 "BFD session type" 189 REFERENCE 190 "RFC5880, RFC5881, RFC5883" 191 SYNTAX INTEGER { 192 singleHop(1), 193 multiHopTotallyArbitraryPaths(2), 194 multiHopOutOfBandSignaling(3), 195 multiHopUnidirectionalLinks(4), 196 multiPointHead(5), 197 multiPointTail(6) 198 } 200 BfdSessOperModeTC ::= TEXTUAL-CONVENTION 201 STATUS current 202 DESCRIPTION 203 "BFD session operating mode" 204 REFERENCE 205 "RFC5880, Section 3.2" 206 SYNTAX INTEGER { 207 asyncModeWEchoFunction(1), 208 asynchModeWOEchoFunction(2), 209 demandModeWEchoFunction(3), 210 demandModeWOEchoFunction(4) 211 } 213 BfdCtrlDestPortNumberTC ::= TEXTUAL-CONVENTION 214 DISPLAY-HINT "d" 215 STATUS current 216 DESCRIPTION 217 "UDP destination port number of BFD control packets. 218 3784 represents single hop BFD session. 219 4784 represents multi hop BFD session. 220 However, syntax is left open to wider range of values 221 purposely for two reasons: 222 1. implementation uses non-compliant port number for 223 valid proprietary reason. 224 2. potential future extension drafts." 225 REFERENCE 226 "Port 3784 (RFC5881) and Port 4784 (RFC5883)" 227 SYNTAX Unsigned32 (0..65535) 229 BfdCtrlSourcePortNumberTC ::= TEXTUAL-CONVENTION 230 DISPLAY-HINT "d" 231 STATUS current 232 DESCRIPTION 233 "UDP source port number of BFD control packets. 234 However, syntax is left open to wider range of values 235 purposely for two reasons: 236 1. implementation uses non-compliant port number for 237 valid proprietary reason. 239 2. potential future extension drafts." 240 REFERENCE 241 "Port 49152..65535 (RFC5881)" 242 SYNTAX Unsigned32 (0..65535) 244 BfdSessStateTC ::= TEXTUAL-CONVENTION 245 STATUS current 246 DESCRIPTION 247 "BFD session state. State failing(5) is only applicable if 248 corresponding session is running in BFD version 0." 249 REFERENCE 250 "draft-katz-ward-bfd-02.txt, RFC5880" 251 SYNTAX INTEGER { 252 adminDown(1), 253 down(2), 254 init(3), 255 up(4), 256 failing(5) 257 } 259 BfdSessAuthenticationTypeTC ::= TEXTUAL-CONVENTION 260 STATUS current 261 DESCRIPTION 262 "BFD authentication type" 263 REFERENCE 264 "RFC5880, Sections 4.2 - 4.4" 265 SYNTAX INTEGER { 266 noAuthentication(-1), 267 reserved(0), 268 simplePassword(1), 269 keyedMD5(2), 270 meticulousKeyedMD5(3), 271 keyedSHA1(4), 272 meticulousKeyedSHA1(5) 273 } 275 BfdSessionAuthenticationKeyTC ::= TEXTUAL-CONVENTION 276 DISPLAY-HINT "1x " 277 STATUS current 278 DESCRIPTION 279 "BFD authentication key type. 281 A BfdSessionAuthenticationKeyTC is always interpreted within 282 the context of an BfdSessAuthenticationTypeTC value. Every 283 usage of the BfdSessionAuthenticationTypeTC textual 284 convention is required to specify the the 285 BfdSessionAuthenticationKeyTC object that provides the 286 context. It is suggested that the 287 BfdSessionAuthentcationTypeTC object be logically registered 288 before the object(s) that use the 289 BfdSessionAuthenticationKeyTC textual convention, if they 290 appear in the same logical row. 292 The value of a BfdSessionAuthenticationKeyTC must always be 293 consistent with the value of the associated 294 BfdSessionAuthencationTypeTC object. Attempts to set a 295 BfdSessionAuthenticationKeyTC object to a value inconsistent 296 with the associated BfdSessionAuthenticationTypeTC must fail 297 with an inconsistentValue error. 299 The following size constraints for a 300 BfdSessionAuthenticationKeyTC object are defined for the 301 associated BfdSessionAuthenticationTypeTC values show below: 303 noAuthentication(-1): SIZE(0) 304 reserved(0): SIZE(0) 305 simplePassword(1): SIZE(1..16) 306 keyedMD5(2): SIZE(16) 307 meticulousKeyedMD5(3): SIZE(16) 308 keyedSHA1(4): SIZE(20) 309 meticulousKeyedSHA1(5): SIZE(20) 311 When this textual convention is used as the syntax of an 312 index object, there may be issues with the limit of 128 313 sub-identifiers specified in SMIv2, STD 58. In this case, 314 the object definition MUST include a 'SIZE' clause to limit 315 the number of potential instance sub-identifiers; otherwise 316 the applicable constraints MUST be stated in the appropriate 317 conceptual row DESCRIPTION clauses, or in the surrounding 318 documentation if there is no single DESCRIPTION clause that 319 is appropriate." 320 REFERENCE 321 "RFC5880, Sections 4.2 - 4.4" 322 SYNTAX OCTET STRING(SIZE(0..252)) 324 END 326 4. Security Considerations 328 This module does not define any management objects. Instead, it 329 defines a set of textual conventions which may be used by other BFD 330 MIB modules to define management objects. 332 Meaningful security considerations can only be written in the MIB 333 modules that define management objects. Therefore, this document has 334 no impact on the security of the Internet. 336 5. IANA Considerations 338 The MIB module in this document uses the following IANA-assigned 339 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 341 Descriptor OBJECT IDENTIFIER value 342 ---------- ----------------------- 344 bfdTCStdMib { mib-2 XXX } 346 [Editor's Note (to be removed prior to publication): the IANA is 347 requested to assign a value for "XXX" under the 'mib-2' subtree and 348 to record the assignment in the SMI Numbers registry. When the 349 assignment has been made, the RFC Editor is asked to replace "XXX" 350 (here and in the MIB module) with the assigned value and to remove 351 this note.] 353 6. References 355 6.1. Normative References 357 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding 358 Detection (BFD)", RFC 5880, June 2010. 360 [BFD-1HOP] Katz, D. and D. Ward, "Bidirectional Forwarding 361 Detection (BFD) for IPv4 and IPv6 (Single Hop)", 362 RFC 5881, June 2010. 364 [BFD-MH] Katz, D. and D. Ward, "Bidirectional Forwarding 365 Detection (BFD) for Multihop Paths", RFC 5883, 366 June 2010. 368 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 369 Schoenwaelder, Ed., "Structure of Management Information 370 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 372 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 373 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 374 STD 58, RFC 2579, April 1999. 376 6.2. Informative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 382 "Introduction and Applicability Statements for Internet- 383 Standard Management Framework", RFC 3410, December 2002. 385 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 386 Management Protocol (SNMP) Applications", STD 62, 387 RFC 3413, December 2002. 389 Appendix A. Acknowledgments 391 We would like to thank David Ward and Jeffrey Haas for their comments 392 and suggestions. 394 Authors' Addresses 396 Thomas D. Nadeau 397 BT 398 BT Centre 399 81 Newgate Street 400 London EC1A 7AJ 401 United Kingdom 403 Email: tnadeau@lucidvision.com 405 Zafar Ali 406 Cisco Systems, Inc. 407 2000 Innovation Drive 408 Kanata, Ontario K2K 3E8 409 Canada 411 Email: zali@cisco.com 413 Nobo Akiya 414 Cisco Systems G.K. 415 Shinjuku Mitsui Building 416 2-1-1 Nishi-Shinjuku, Shinjuku-Ku 417 Tokyo 163-0409 418 Japan 420 Email: nobo@cisco.com