idnits 2.17.1 draft-kkoushik-snmp-context-map-mib-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (2010-03-07) is 5136 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-bfd-mib-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Thomas D. Nadeau 2 Intended status: Informational BT 3 Expires: Nov 2010 A S Kiran Koushik 4 Cisco Systems Inc. 6 Creation Date: 2010-03-07 8 SNMP Context Mapping MIB 10 draft-kkoushik-snmp-context-map-mib-02.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright (c) 2010 IETF Trust and the persons identified as the document 34 authors. All rights reserved. 36 Abstract 38 This document defines a MIB module to manage the usage of SNMP 39 contexts. Specically, within for an SNMP agent which implements 40 multiple copies/instances of some other MIB module, this MIB module 41 provides a mapping between SNMP Contexts and the individual instances 42 of that other MIB module. 44 Table of Contents 46 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. SNMP Context mapping feature - High-Level Picture . . . . . 3 49 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 3 50 5. Object Definitions . . . . . . . . . . . . . . . . . . . . . 4 51 6. Security Considerations . . . . . . . . . . . . . . . . . . 11 52 7. Example of usage . . . . . . . . . . . . . . . . . . . . . . 11 53 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 54 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 56 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 57 8.2 Informative References. . . . . . . . . . . . . . . . . . . . 13 58 9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 13 59 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 13 60 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 62 1. Introduction 64 With the advent of newer technologies, an increasing number of 65 technologies which used to be defined such that only one instance 66 could exist within a device, are now being implemented at a 67 different granularity such that multiple copies/instances can exist 68 in one device at the same time. 70 An excellent example for this behavior is with the 71 OSPF-MIB(RFC 1850). When it was originally designed, there was no 72 concept of multiple OSPF instances running on the same system and 73 there was no built-in mechanism to handle such circumstances. 75 However according to Section 4.1.1 of RFC 4577, a PE router that 76 attaches to more than one OSPF domain must run an independent 77 instance of OSPF for each domain. Each OSPF instance is associated 78 to a VRF(see section 3 of RFC4364. This means that OSPF-MIB must 79 now support multiple VRF contexts and within each context the 80 objects in the OSPF-MIB can be indexed by the same OID but 81 represent different data. 83 One way to overcome this issue would be to update the OSPF-MIB to 84 have an additional variable in the INDEX clause. This would require 85 depreacting and re-defining just about all objects in the MIB; 86 in effect, a modified copy of the original MIB. This change can 87 be severely disadvantageous to existing deployments. 89 MPLS-LSR-STD-MIB[RFC3813], [BFD-MIB], BGP-MIB[RFC4273], [ISIS-MIB] 90 and IP-FORWARD-MIB[RFC4292] are other MIBs which are also affected 91 in the same way. 92 Another example is with the BRIDGE-MIB[RFC4188] where each Bridge 93 entity in a system can contain different subsets of data indexed 94 by the same OID. 96 A better way to overcome the issue is to use multiple SNMP contexts 97 (see section 3.3.1 of RFC 3411). However, as and when significant 98 usage is made of SNMP contexts (e.g., for multiple MIBs and/or 99 multiple domains), then there is a need for the contexts themselves 100 to be manageable. This document defines management information 101 for this purpose. 103 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in BCP 14, RFC 2119 108 [RFC2119]. 110 2. Terminology 112 This document uses terminology from the document describing the MPLS 113 architecture [RFC3031] and from the document describing MPLS Layer-3 114 VPNs (L3VPN) [RFC4364], as well as the SNMP architecture [RFC3411]. 116 Throughout this document, the use of the terms "Provider Edge (PE) 117 and Customer Edge (CE)" or "PE/CE" will be replaced by "PE" in all 118 cases except when a network device is a CE when used in the carrier's 119 carrier model. 121 3. SNMP Context mapping feature - High-Level Picture: 123 The use of SNMP contexts as a solution to the problem of 124 accessing SNMP MIBs on a per-context basis 125 requires no modifications to existing MIBs. Instead, this solution 126 requires that the Network Management Station (NMS) or any other 127 manager desiring to manage an agent, be made aware that a 128 VPN Identifier or a Bridge Identifier or some other data 129 distinguishing identifier can be mapped to a SNMP Context field 130 for every request. 132 The MIB presented in this draft can be used to map a vacmContextName 133 into any data distinguishing identifier which can retrieve data from 134 the appropriate instance. 136 Every SNMPv3 operation acts within the context of an SNMP Context. 137 The name of that SNMP Context is carried in the message header 138 and serves as part of the naming structure of MIB objects (see 139 section 3.3.1 of RFC 3411). When all of an agent's management 140 information is in the same SNMP Context, then the name of that 141 Context need only be used implicitly. In contrast, when multiple 142 SNMP Contexts are in use, then the name of a particular Context 143 must be used explicitly to determine which items of management 144 information are referenced by which OIDs. 146 For older versions of SNMP, a mapping between the SNMP community and 147 the SNMP context can be maintained using the SNMP-COMMUNITY-MIB. 149 4. Protocol Operations 150 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 152 TBD 154 5. Object Definitions 156 SNMP-CONTEXT-MAPPING-MIB DEFINITIONS ::= BEGIN 158 IMPORTS 159 MODULE-IDENTITY, 160 OBJECT-TYPE 161 FROM SNMPv2-SMI 163 SnmpAdminString 164 FROM SNMP-FRAMEWORK-MIB 166 MODULE-COMPLIANCE, 167 OBJECT-GROUP 168 FROM SNMPv2-CONF 170 RowStatus, 171 StorageType 172 FROM SNMPv2-TC 173 PwIndexType 174 FROM PW-TC-STD-MIB 176 snmpContextMappingMIB MODULE-IDENTITY 177 LAST-UPDATED "200802140000Z" 178 ORGANIZATION "Cisco Systems Inc." 179 CONTACT-INFO " 180 Kiran Koushik A S 181 Email: kkoushik@cisco.com 183 Thomas Nadeau 184 Email: thomas.nadeau@bt.com 186 Chinna Pellacuru 187 Email: pcn@cisco.com 189 " 190 DESCRIPTION 191 " 192 Copyright (C) The IETF Trust (2008). The initial 193 version of this MIB module was published in RFC XXXX. 194 -- RFC Editor: Please replace XXXX with RFC number & remove 195 -- this note. 197 For full legal notices see the RFC itself or see: 198 http://www.ietf.org/copyrights/ianamib.html 200 A single SNMP agent sometimes needs to support multiple 201 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 203 instances of the same MIB module, and does so through the 204 use of multiple SNMP contexts. This typically occurs because 205 the technology has evolved to have extra dimension(s), i.e., 206 one or more extra data and/or identifier values which are 207 different in the different contexts, but were not defined in 208 INDEX clause(s) of the original MIB module. In such cases, 209 network management applications need to know the specific 210 data/identifier values in each context, and this MIB module 211 provides mapping tables which contain that information. 213 Within a network there can be multiple Virtual Private 214 Networks (VPNs) configured using Virtual Routing and 215 Forwarding Instances (VRFs). Within a VPN there can be 216 multiple topologies when Multi-topology Routing (MTR) is 217 used. Also, Interior Gateway Protocols (IGPs) can have 218 multiple protocol instances running on the device. 220 With MTR routing and VRFs, a router now needs to support 221 multiple instances of several existing MIB modules, and 222 this can be achieved if the router's SNMP agent provides 223 access to each instance of the same MIB module via a 224 different SNMP context (see Section 3.1.1 of RFC 3411). 225 For MTR routing and VRFs, a different SNMP context is needed 226 depending on one or more of the following: the VRF, the 227 topology-identifier, and the routing protocol instance. 228 In other words, the router's management information can be 229 accessed through multiple SNMP contexts where each such 230 context represents a specific VRF, a specific 231 topology-identifier, and/or a specific routing protocol 232 instance. This MIB module provides a mapping of each such 233 SNMP context to the corresponding VRF, the corresponding 234 topology, and the corresponding routing protocol instance. 235 Some SNMP contexts are independent of VRFs, independent of 236 a topology, or independent of a routing protocol instance, 237 and in such a case, the mapping is to the to the zero length 238 string. 240 We have also added the mapping to dot1dBasePort from BRIDGE-MIB 241 and the vplsConfigIndex from VPLS-MIB as we feel that these 242 data distinguishing identifiers will be applicable to a 243 larger subset of the MIBs that are already defined. 244 Similarly a mapping from the PwIndex from PWE3-PW-TC-MIB to the 245 dot1dBasePort from BRIDGE-MIB has been defined here. 247 As technology evolves more we may need additional 248 identifiers to identify the context. Then we would need 249 to add those additional identifiers into the mapping. 250 We must caution that since there are huge number MIB modules 251 defined, if even a small fraction of them needs to have 252 multiple instances in SNMP contexts, then what this 253 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 255 paragaph proposes will NOT scale. We request the MIB 256 users to judiciously choose the data distinguishing identifiers 257 which map to a SNMP context. 259 Copyright (C) The IETF Trust (2008). This version 260 of this MIB module is part of RFC XXX; see the RFC 261 itself for full legal notices. 262 -- RFC Ed.: replace XXX with actual RFC number & remove this 263 -- note 264 " 266 REVISION "200802140000Z" 267 DESCRIPTION 268 "Initial version of the MIB module." 269 ::= { experiment xxx } 271 snmpContextMappingMIBObjects OBJECT IDENTIFIER 272 ::= { snmpContextMappingMIB 1 } 273 snmpContextMappingMIBConformance OBJECT IDENTIFIER 274 ::= { snmpContextMappingMIB 2 } 276 snmpContextMappingTable OBJECT-TYPE 277 SYNTAX SEQUENCE OF SNMPContextMappingEntry 278 MAX-ACCESS not-accessible 279 STATUS current 280 DESCRIPTION 281 "This table contains information on which 282 snmpContextMappingVacmContextName is mapped to 283 which VRF, topology, and routing protocol instance. 285 This table is indexed by SNMP VACM context. 287 Configuring a row in this table for an SNMP context 288 does not require that the context be already defined, 289 i.e., a row can be created in this table for a context 290 before the corresponding row is created in RFC 3415's 291 vacmContextTable. 293 To create a row in this table, a manager must set 294 snmpContextMappingRowStatus to either 'createAndGo' or 295 'createAndWait'. 297 To delete a row in this table, a manager must set 298 snmpContextMappingRowStatus to 'destroy'." 299 ::= { snmpContextMappingMIBObjects 1 } 301 snmpContextMappingEntry OBJECT-TYPE 302 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 304 SYNTAX SNMPContextMappingEntry 305 MAX-ACCESS not-accessible 306 STATUS current 307 DESCRIPTION 308 "Information relating to a single mapping of 309 snmpContextMappingVacmContextName to the corresponding VRF, 310 the corresponding topology, and the corresponding routing 311 protocol instance." 312 INDEX { snmpContextMappingVacmContextName } 313 ::= { snmpContextMappingTable 1 } 315 SNMPContextMappingEntry ::= 316 SEQUENCE { 317 snmpContextMappingVacmContextName SnmpAdminString, 318 snmpContextMappingVrfName SnmpAdminString, 319 snmpContextMappingTopologyName SnmpAdminString, 320 snmpContextMappingProtoInstName SnmpAdminString, 321 snmpContextMappingBridgePort Unsigned32, 322 snmpContextMappingVplsIndex Unsigned 32, 323 snmpContextMappingStorageType StorageType, 324 snmpContextMappingRowStatus RowStatus, 325 snmpContextMappingACType INTEGER, 326 snmpContextMappingPwIndex pwIndexType 328 } 330 snmpContextMappingVacmContextName OBJECT-TYPE 331 SYNTAX SnmpAdminString (SIZE(0..32)) 332 MAX-ACCESS not-accessible 333 STATUS current 334 DESCRIPTION 335 "The vacmContextName given to the SNMP context. 337 This is a human readable name identifying a particular 338 SNMP VACM context at a particular SNMP entity. 339 The empty contextName (zero length) represents the 340 default context." 341 ::= { snmpContextMappingEntry 1 } 343 snmpContextMappingVrfName OBJECT-TYPE 344 SYNTAX SnmpAdminString (SIZE(0..32)) 345 MAX-ACCESS read-create 346 STATUS current 347 DESCRIPTION 348 "The value of an instance of this object identifies 349 the name given to the VRF to which the SNMP context 350 is mapped to. 352 This is typically a human-readable string. This is 353 the same ASCII string used in the router's console 354 interface to refer to this VRF. 356 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 358 When the value of this object is the zero length 359 string it indicates that the SNMP context is independent 360 of any VRF." 361 DEFVAL { ''H } -- the zero length string 362 ::= { snmpContextMappingEntry 2 } 364 snmpContextMappingTopologyName OBJECT-TYPE 365 SYNTAX SnmpAdminString (SIZE(0..32)) 366 MAX-ACCESS read-create 367 STATUS current 368 DESCRIPTION 369 "The value of an instance of this object identifies 370 the name given to the topology to which the SNMP 371 context is mapped to. 373 This is typically a human-readable string. This is 374 the same ASCII string used in the router's console 375 interface to refer to this topology. 377 When the value of this object is the zero length 378 string it indicates that the SNMP context is independent 379 of any topology." 380 DEFVAL { ''H } -- the zero length string 381 ::= { snmpContextMappingEntry 3 } 383 snmpContextMappingProtoInstName OBJECT-TYPE 384 SYNTAX SnmpAdminString (SIZE(0..32)) 385 MAX-ACCESS read-create 386 STATUS current 387 DESCRIPTION 388 "The value of an instance of this object identifies 389 the name given to the protocol instance to which the 390 SNMP context is mapped to. 392 This is typically a human-readable string. This is 393 the same ASCII string used in the router's console 394 interface to refer to this protocol instance. 396 When the value of this object is the zero length 397 string it indicates that the SNMP context is independent 398 of any protocol instance." 399 DEFVAL { ''H } -- the zero length string 400 ::= { snmpContextMappingEntry 4 } 402 snmpContextMappingBridgePort OBJECT-TYPE 403 SYNTAX Unsigned32 404 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 406 MAX-ACCESS read-create 407 STATUS current 408 DESCRIPTION 409 "When snmpContextMappingACType is set to interface(1), 410 The value of an instance of this object identifies 411 the dot1dBasePort to which the 412 SNMP context is mapped to. 414 When the value of this object is zero 415 it indicates that the SNMP context is independent 416 of dot1dBasePort." 417 DEFVAL { 0 } 418 REFERENCE "RFC 4188 - Section 4." 419 ::= { snmpContextMappingEntry 5 } 421 snmpContextMappingVplsIndex OBJECT-TYPE 422 SYNTAX Unsigned32 423 MAX-ACCESS read-create 424 STATUS current 425 DESCRIPTION 426 "The value of an instance of this object identifies 427 vplsConfigIndex to which the SNMP context is mapped to. 429 When the value of this object is zero 430 it indicates that the SNMP context is independent 431 of vplsConfigIndex." 432 DEFVAL { 0 } 433 REFERENCE "draft-ietf-l2vpn-vpls-mib-00.txt" 434 ::= { snmpContextMappingEntry 6 } 436 snmpContextMappingStorageType OBJECT-TYPE 437 SYNTAX StorageType 438 MAX-ACCESS read-create 439 STATUS current 440 DESCRIPTION 441 "The storage type for this conceptual row. 443 Conceptual rows having the value 'permanent' need not 444 allow write-access to any columnar objects in the row." 445 DEFVAL { nonVolatile } 446 ::= { snmpContextMappingEntry 7 } 448 snmpContextMappingRowStatus OBJECT-TYPE 449 SYNTAX RowStatus 450 MAX-ACCESS read-create 451 STATUS current 452 DESCRIPTION 453 "This object facilitates the creation, modification, or 455 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 457 deletion of a conceptual row in this table." 458 ::= { snmpContextMappingEntry 8 } 460 snmpContextMappingACType OBJECT-TYPE 461 SYNTAX INTEGER { 462 interface (1), 463 pseudoWire (2) 464 } 465 MAX-ACCESS read-create 466 STATUS current 467 DESCRIPTION 468 "The value of an instance of this object identifies 469 whether this context is applicable to an 470 attachmentCircuit which is an interface or a pseudoWire. 472 If the value of this object is interface(1), then the 473 snmpContextMappingBridgePort identifies the dot1dBasePort 474 to which this context maps to. 475 If the value of this object is pseudoWire(2), then the 476 snmpContextMappingPwIndex identifies the dot1dBasePort 477 to which this context maps to. 478 When the value of snmpContextMappingVplsIndex is 0, then 479 this object is not relevant." 480 ::= { snmpContextMappingEntry 9 } 482 snmpContextMappingPwIndex OBJECT-TYPE 483 SYNTAX PwIndexType 484 MAX-ACCESS read-create 485 STATUS current 486 DESCRIPTION 487 "When snmpContextMappingACType is set to pseudoWire(2), 488 the value of an instance of this object identifies 489 the PwIndex to which the SNMP context is mapped to. 490 The dot1dBasePort to which this PwIndex maps to is 491 defined in snmpContextMappingBridgePort. 493 When the value of snmpContextMappingVplsIndex is zero 494 it indicates that the SNMP context is independent 495 of snmpContextMappingPwIndex." 496 ::= { snmpContextMappingEntry 10 } 498 -- Conformance 500 snmpContextMappingMIBCompliances 501 OBJECT IDENTIFIER ::= { snmpContextMappingMIBConformance 1 } 503 snmpContextMappingMIBGroups 504 OBJECT IDENTIFIER ::= { snmpContextMappingMIBConformance 2 } 505 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 507 -- Compliance 509 snmpContextMappingMIBCompliance MODULE-COMPLIANCE 510 STATUS current 511 DESCRIPTION 512 "The compliance statement for entities which implement 513 the SNMP-CONTEXT-MAPPING-MIB." 514 MODULE 515 MANDATORY-GROUPS { 516 snmpContextMappingDataGroup 517 } 519 OBJECT snmpContextMappingVrfName 520 MIN-ACCESS read-only 521 DESCRIPTION "Write access is not required." 523 OBJECT snmpContextMappingTopologyName 524 MIN-ACCESS read-only 525 DESCRIPTION "Write access is not required." 527 OBJECT snmpContextMappingProtoInstName 528 MIN-ACCESS read-only 529 DESCRIPTION "Write access is not required." 531 OBJECT snmpContextMappingBridgePort 532 MIN-ACCESS read-only 533 DESCRIPTION "Write access is not required." 535 OBJECT snmpContextMappingVplsIndex 536 MIN-ACCESS read-only 537 DESCRIPTION "Write access is not required." 539 OBJECT snmpContextMappingStorageType 540 MIN-ACCESS read-only 541 DESCRIPTION "Write access is not required." 543 OBJECT snmpContextMappingRowStatus 544 MIN-ACCESS read-only 545 DESCRIPTION "Create/delete/modify access to the 546 snmpContextMappingTable is not required." 548 ::= { snmpContextMappingMIBCompliances 1 } 549 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 551 -- Units of Conformance 553 snmpContextMappingDataGroup OBJECT-GROUP 554 OBJECTS { 555 snmpContextMappingVrfName, 556 snmpContextMappingTopologyName, 557 snmpContextMappingProtoInstName, 558 snmpContextMappingBridgePort, 559 snmpContextMappingVplsIndex, 560 snmpContextMappingStorageType, 561 snmpContextMappingRowStatus, 562 snmpContextMappingACType, 563 snmpContextMappingPwIndex 564 } 565 STATUS current 566 DESCRIPTION 567 "The collection of objects providing the context 568 mapping data between the SNMP context to the 569 VRF, topology, protocol instance, bridge port, 570 and VPLS index." 571 ::= { snmpContextMappingMIBGroups 1 } 572 END 574 6. Security Considerations 576 The MIB module described in this document in association with 577 SNMP-COMMUNITY-MIB and SNMPv3 framework is useful for accessing 578 subsets of data based on various data distinguishing identifiers. 580 There are objects in this MIB which are configurable via SNMP. 581 If these are configured incorrectly, there can be potential 582 data access violations. 584 There are a number of management objects defined in these MIB modules 585 with a MAX-ACCESS clause of read-write and/or read-create. Such 586 objects may be considered sensitive or vulnerable in some network 587 environments. The support for SET operations in a non-secure 588 environment without proper protection can have a negative effect on 589 network operations. These are the tables and objects and their 590 sensitivity/vulnerability. 592 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 594 7. Example of usage: 596 In snmpContextMappingTable: 598 snmpContextMappingContextName "contextA"{Index} 599 snmpContextMappingVrfName "customerA" 600 snmpContextMappingTopologyName "" 601 snmpContextMappingProtoInstName "" 602 snmpContextMappingBridgePort 0 603 snmpContextMappingVplsIndex 0 604 snmpContextMappingStorageType (2)volatile 605 snmpContextMappingRowStatus 1(active) 607 snmpContextMappingContextName "contextB"{Index} 608 snmpContextMappingVrfName "customerB" 609 snmpContextMappingTopologyName "" 610 snmpContextMappingProtoInstName "" 611 snmpContextMappingBridgePort 0 612 snmpContextMappingVplsIndex 0 613 snmpContextMappingStorageType (2)volatile 614 snmpContextMappingRowStatus 1(active) 616 In ospfHostTable from RFC 1850: 618 [For OSPF Instance on VRF "customerA"] 620 ospfHostIpAddress "1.2.3.4"{Index} 621 ospfHostTOS 8 {Index} 622 ospfHostMetric "ab" 623 ospfHostStatus "1(enabled)" 624 ospfHostAreaID "1.1.1.1" 626 [For OSPF Instance on VRF "customerB"] 628 ospfHostIpAddress "1.2.3.4"{Index} 629 ospfHostTOS 8 {Index} 630 ospfHostMetric "ab" 631 ospfHostStatus "1(enabled)" 632 ospfHostAreaID "1.1.1.2" 634 In the above case, we can use the context mapping to distinguish 635 data between different OSPF instances eventhough the OID indexes 636 are the same. 638 8. References 640 8.1. Normative References 641 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 643 [RFC4273] Willis, S.,et all, "Definitions of Managed Objects 644 for the Fourth Version of the Border Gateway Protocol 645 (BGP-4) using SMIv2", RFC 4273, July 1994. 647 [RFC4292] Haberman, B., "IP Forwarding Table MIB", 648 RFC 4292, Apr 2006 650 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, March 1997. 653 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 654 Label Switching Architecture", RFC 3031, January 2001. 656 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 657 Architecture for Describing Simple Network Management 658 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 659 December 2002. 661 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 662 "Multiprotocol Label Switching (MPLS) Label Switching 663 (LSR) Router Management Information Base (MIB)", RFC 3813, 664 June 2004. 665 [RFC4188] Norseth, K., and Bell, E., "Definitions of Managed 666 Objects for Bridges", RFC 4188, Sept 2006. 668 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 669 Networks (VPNs)", RFC 4364, February 2006. 671 [BFD-MIB] Nadeau, T., and Ali, Z., "Bidirectional Forwarding 672 Detection Management Information Base", 673 draft-ietf-bfd-mib-03.txt, Oct 2006. 675 [ISIS-MIB] Parker, J., "Management Information Base for IS-IS", 676 draft-ietf-isis-mib-04.txt, Dec 2002. 678 8.2. Informative References 679 draft-kkoushik-snmp-context-map-mib-02 Mar 07, 2010 681 9. Acknowledgments 683 We would like to thank Keith McCloghrie for his insightful 684 comments and expert suggestions. 686 We would also like to thank Chinna Narasimha Reddy and Madhavi. 688 Rohit Mediratta has contributed to the VPLS updates to this 689 draft and we would like to thank him for that. 691 10. IANA Considerations 693 -- (Note to RFC-Editor:) 694 -- We request that you assign contiguous RFC numbers to the 695 -- IANA is requested to root MIB objects in the MIB module 696 -- contained in this document under the transmission subtree. 697 -- 699 11. Authors' Addresses 701 Thomas D. Nadeau 702 BT 703 BT Centre 704 81 Newgate Street 705 EC1A 7AJ 706 London 707 Email: tom.nadeau@bt.com 709 A S Kiran Koushik 710 Cisco Systems Inc 711 12515 Research Blvd, Bldg 4 712 Austin TX 78759 713 Email: kkoushik@cisco.com 715 Full Copyright Statement 717 Copyright (c) 2010 IETF Trust and the persons identified as the 718 document authors. All rights reserved. 720 This document is subject to BCP 78 and the IETF Trust's Legal 721 Provisions Relating to IETF Documents 722 (http://trustee.ietf.org/license-info) 723 in effect on the date of publication of this document. Please 724 review these documents carefully, as they describe your rights and 725 restrictions with respect to this document. Code Components 726 extracted from this document must include Simplified BSD License 727 text as described in Section 4.e of the Trust Legal Provisions and 728 are provided without warranty as described in the Simplified BSD 729 License.