idnits 2.17.1 draft-ietf-l3vpn-vr-mib-04.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 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1187. ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 6) being 71 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (July 2005) is 6857 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: 'RFC3410' is mentioned on line 1075, but not defined == Missing Reference: 'RFC3411' is mentioned on line 131, but not defined == Unused Reference: 'RFC2571' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: 'VPNTCMIB' is defined on line 1110, but no explicit reference was found in the text == Unused Reference: 'RFC2685' is defined on line 1117, but no explicit reference was found in the text == Unused Reference: 'PPVPN-VR-AS' is defined on line 1128, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPNTCMIB' == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-vpn-vr-02 == Outdated reference: A later version (-02) exists of draft-ietf-l3vpn-as-vr-01 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Elwin Stelzer 2 draft-ietf-l3vpn-vr-mib-04.txt Corona Networks, Inc. 3 Expires: January 2006 4 Sam Hancock 5 ACM Systems 7 Benson Schliesser 8 SAVVIS Communications 10 Joseph Laria (Ed.) 11 Level Stream Research 13 July 2005 15 Virtual Router Management Information Base Using SMIv2 17 Status of this Memo 19 This document is an Internet-Draft. 21 By submitting this Internet-Draft, each author represents 22 that any applicable patent or other IPR claims of which he 23 or she is aware have been or will be disclosed, and any of 24 which he or she becomes aware will be disclosed, in 25 accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as 36 "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This document is a product of the IETF's Layer 3 Virtual Private 45 Network (l3vpn) working group. Comments should be addressed to WG's 46 mailing list at l3vpn@ietf.org. The charter for l3vpn may be found 47 at http://www.ietf.org/html.charters/l3vpn-charter.html 49 Abstract 51 This memo defines a portion of the Management Information Base (MIB) 52 for use with network management protocols in TCP/IP based internets. 53 In particular, it defines objects for managing networks using Virtual 54 Routers (VR). 56 Table of Contents 58 1.0 Terminology 59 2.0 Introduction 60 3.0 The Internet-Standard Management Framework 61 4.0 Overview of the Virtual Router MIB Module 62 4.1 SNMP Contexts for Management for Virtual Routers 63 4.2 VR Indexing 64 4.3 Creation and Deletion of VRs 65 4.4 Administrative and Operational Status of VRs 66 4.4.1 VR Routing Protocol Trigger 67 4.5 Binding interfaces to a VR 68 4.6 Setting per VR limits 69 4.7 Per VR Statistics 70 4.8 Traps 71 4.9 Usability Considerations 72 4.9.1 Multiple Agents 73 4.9.2 Provisioning vs. Monitoring 74 5.0 Sample VR MIB module Configuration Scenario 75 5.1 Creation of a VR 76 6.0 Definition of the Virtual Router MIB Module 77 7.0 Acknowledgments 78 8.0 Security Considerations 79 9.0 References 80 9.1 Normative References 81 9.2 Informative References 82 10.0 Authors' Addresses 83 11.0 Intellectual Property Considerations 84 12.0 Full Copyright Statement 85 13.0 IANA Considerations for L3VPN-VR-MIB module 87 1.0 Terminology 89 This document uses terminology defined in [PPVPN-FW] and [PPVPN-VR]. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 92 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in 94 RFC 2119, reference [RFC2119]. 96 2.0 Introduction 98 This memo defines a MIB module for the Virtual Router [PPVPN-VR, 99 PPVPN-VR-AS] model of Provider Provisioned VPNs [PPVPN-FW]. 101 Following are the goals, in defining this MIB module: 103 - To have a means for Service Providers to provision VPN service for 104 subscribers, at the PE device. 106 - To make the agent-side implementation simple, by not modifying the 107 existing standard MIB modules. 109 - Define all the gluing tables that are needed toward this end. 111 3.0 The Internet-Standard Management Framework 113 For a detailed overview of the documents that describe the current 114 Internet-Standard Management Framework, please refer to section 7 of 115 RFC 3410 [RFC3410]. 117 Managed objects are accessed via a virtual information store, termed 118 the Management Information Base or MIB. MIB module objects are 119 generally accessed through the Simple Network Management (SNMP) 120 Protocol. Objects in a MIB module are defined using the mechanisms 121 defined in the Structure of Management Information (SMI). This memo 122 specifies a MIB module that is compliant to the SMIv2, which is 123 described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] 124 and STD 58, RFC 2580 [RFC2580]. 126 4.0 Overview of the Virtual Router MIB Module 128 4.1 SNMP Contexts for Management for Virtual Routers 130 There is a need for a single agent to manage multiple Virtual Routers. 131 The Architecture for describing SNMP Management Frameworks [RFC3411] 132 provides a way to support such cases. 134 Managing multiple virtual routers requires that the PE management 135 plane be subdivided into logical VR management domains. In the VR 136 model of PPVPNs a single PE device may contain many virtual routers. 137 Different management entities SHOULD be able to manage specific 138 virtual routers and associated services. The Service Provider MUST be 139 able to manage all virtual routers and associated services. 141 Using SNMP contexts to group a collection of management information 142 provides the following benefits: 144 (1) Uses a standard framework defined by the IETF, allowing the 145 product to remain flexible to all implementations of virtual 146 router devices. 148 (a) Use SNMPv2c Community String's 150 (b) Use SNMPv3 contextName's 152 (2) Prevents vendors from having to modify the standard MIBs, 153 allowing the implementation to remain standards compliant. 155 (3) Provides a framework that will work for RIP, OSPF, IS-IS, BGP, 156 IP-FORWARDING, MPLS, and any other MIB module that can be 157 administratively grouped with a VR. 159 The SNMP context for the Virtual Router instance can be specified in 160 the VrConfigTable. The VrContextName columnar object is used to set 161 the SNMPv2c Community String or the SNMPv3 contextName for a given VR. 163 A virtual router context represents the set of MIB module objects that 164 could be administratively grouped within a VR. For example, each VR 165 would maintain its own instance of routing protocol MIB module tables. 166 However, the ADMIN context would contain single instances of objects 167 and tables that pertain to system wide configuration such as the Entity, 168 Interfaces, and ATM MIB modules. 170 A management system using the SNMP context of a particular virtual 171 router MUST be able to manage the virtual router without disrupting 172 other virtual routers in the same PE device. 174 For example, a PE can be subdivided into two 2 VRs running the OSPF 175 routing protocol. Each VR will maintain a unique instance of the 176 OSPF-MIB. Therefore, the ospfAreaTable of VR-A is distinct from the 177 ospfAreaTable of VR-B. 179 +-----------------------------------------------------------------+ 180 | +------------------------------------------------------------+ | 181 | | SNMP entity (including Engine, Applications) | | 182 | | | | 183 | | example contextNames: | | 184 | | | | 185 | | "vr01" "vr09" "admin" | | 186 | | --------- --------- ------------ | | 187 | | | | | | | 188 | +------|------------------|-------------------|--------------+ | 189 | | | | | 190 | +------|------------------|-------------------|--------------+ | 191 | | MIB | instrumentation | | | | 192 | | +---v------------+ +---v------------+ +----v-----------+ | | 193 | | | context=vr01 | | context=vr09 | | context=admin | | | 194 | | | | | | | | | | 195 | | | +------------+ | | +------------+ | | +------------+ | | | 196 | | | | OSPF MIB | | | | OSPF MIB | | | | VR MIB | | | | 197 | | | +------------+ | | +------------+ | | +------------+ | | | 198 | | | | | | | | | | 199 | | | +------------+ | | +------------+ | | +------------+ | | | 200 | | | | BGP MIB | | | | BGP MIB | | | | ATM MIB | | | | 201 | | | +------------+ | | +------------+ | | +------------+ | | | 202 | | | | | | | | | | 203 | | | +------------+ | | +------------+ | | +------------+ | | | 204 | | | | IP MIB | | | | IP MIB | | | | ENTITY MIB | | | | 205 | | | +------------+ | | +------------+ | | +------------+ | | | 206 | | | | | | | | | | 207 | | | +------------+ | | +------------+ | | +------------+ | | | 208 | | | | other MIB | | | | other MIB | | | | IF MIB | | | | 209 | | | +------------+ | | +------------+ | | +------------+ | | | 210 | | | ... | | ... | | ... | | | 211 +-----------------------------------------------------------------+ 213 Filtering mechanisms based on the SNMP context of a particular virtual 214 router may implemented to allow different management entities to manage 215 those objects and services provisioned the 'Admin' context. 217 4.2 VR Indexing 219 While the standard protocol MIB module tables are instantiated in the 220 context specified using SNMP contexts, there may be tables that are 221 defined with the VRID as index. 223 The VRID is of local significance to a particular PE device, and need 224 not be globally unique. Thus a particular VRID value assigned to a VR 225 in one PE device may indicate a different VR in another PE device. 227 The VRID has an Unsigned32 value, and this value is assigned by the 228 management station. To aid the management station in assigning a VRID 229 without conflict, the management station can get the 230 'NextAvailableVRID' from the PE device. 232 A SNMP manager SHOULD NOT assume global significance of any VRID value 233 other than 0. 235 For those MIB module tables instantiated in the virtual router context, 236 indexing can only be assumed unique for that particular VR. However 237 those indices in the "ADMIN" context are unique across the entire 238 system, including all VRs. 240 4.3 Creation and Deletion of VRs 242 The VR Config Table is used for this purpose. This is a read-create 243 table and adding an entry into this table will create a VR. Removing 244 an entry from this table marks the deletion of a VR. 246 VRID 0 is assigned to the Administrative VR, which exists by default, 247 and need not be created. Deletion of the Administrative VR will not be 248 permitted. The VRID of the Administrative VR (VRID 0) should be a 249 reserved VRID number. VRID 0 could be termed the "null VR" and it 250 could be the context that manages the resource pool of unattached 251 interfaces. Routing would then not exist in the context of 252 Administrative VR. 254 4.4 Administrative and Operational Status of VRs 256 VRs can be administratively turned down. When this is done, no 257 packet forwarding via the VR takes place. 259 VrOperStatus denotes the operational status of a VR. Currently the 260 VrOperStatus is expected to change along the VrAdminStatus unless an 261 error condition exists. 263 4.4.1 VR Routing Protocol Trigger 265 A construct for independently instantiating routing protocol 266 instances for each VR may be useful a solution especially in a PE 267 router where scaling of resources would be necessary. 269 VrRpTrigger object represents the Routing Protocol (RP) triggers 270 on a VR and is it meant to be used to initiate or shutdown routing 271 protocols on a VR. 273 4.5 Binding interfaces to a VR 275 Interfaces are bound to a VR, using vrIfConfigTable. This is 276 a read-write table, and note that interfaces are not created through 277 this table. The vrIfConfigTable MIB module table is used to indicated 278 the relationship between interfaces and virtual router IDs. For each 279 interface present in the system, this table is used to provide the 280 mapping from IfIndex to a unique VR. The table show which interfaces 281 are ?attached or connected? to a virtual router. An interface can not 282 be attached to more than one VR. 284 The "Admin" VR could be used to manage the resource pool of 285 unattached interfaces. However interfaces would not be attached to 286 VRID 0. 288 4.6 Setting per VR limits 290 VRs consume resources on a device, and hence the following parameters 291 defined in vrConfigTable are used to specify an upper bound of resource 292 utilization: 294 VrMaxRoutes - 295 Specify the maximum number of routes that will be permitted in VR. This 296 includes all routes, such as the statically configured routes, and the 297 routes learnt via dynamic routing protocols. 299 4.7 Per VR Statistics 301 In addition to those statistics available through the VR instantiated 302 MIB module tables, there are some per-VR statistics available through 303 vrStatTable. 305 4.8 Traps 307 This memo defines that VrUp and VrDown traps are generated just after 308 VrOperStatus leaves, or just before it enters, the down state, 309 respectively. 311 (1) A transition into the down state will occur when an error is 312 detected on a VR instance. 314 (2) Departing the down state generally indicates that the 315 VR is going to up, which is considered a "healthy" state. 317 An exception to the above generation of VrUp/VrDown traps on changes 318 in VrOperStatus, occurs when an VR is "flapping", i.e., when it is 319 rapidly oscillating between the up and down states. If traps were 320 generated for each such oscillation, the network and the network 321 management system would be flooded with unnecessary traps. In such a 322 situation, the agent should limit the rate at which it generates traps. 324 This memo defines that enabling and disabling the VR traps is achieved 325 by setting the VrTrapEnable to true(1) or false(2), respectively. By 326 default, this object should have the value true(1). 328 On some devices where system memory is limited, there may be a need to 329 restrict the maximum number of routes allowed on the system. This memo 330 defines vrMaxRoutesExceeded trap to indicate when vrStatRouteEntries 331 exceeds the maximum limit. There is a danger of notification storms 332 with this type of notification. The definition of vrMaxRoutes is such 333 that vrStatRouteEntries could never exceed it. So whenever vrMaxRoutes 334 has been reached, each new attempt to add a route will cause a new 335 Notification. In order to prevent notification storms of this type, 336 this memo also defines and the enabling and disabling of this trap 337 which is acheived by setting the VrMaxRouteTrapEnable to true(1) or 338 false(2), respectively. By default, this object should have the value 339 true(1). 341 4.9 Usability Considerations 342 4.9.1 Multiple Agents 344 The MIB module is based upon the premise that a single SNMP agent should 345 represent every virtual router on a physical router. An alternative 346 approach would be to deploy a separate SNMP agent for each virtual 347 router. Creating multiple agents for use by the administrator 348 (Service Provider) could be done, for instance by binding to different 349 ports or addresses on the P-node. However from a resource perspective, 350 it is more efficient to use a single agent and multiplex based on the 351 community/context as described in this document. In either case, 352 though, a VR-MIB module is needed to map each VR to its respective 353 agent or context. 355 There could be a case where a separate agent per VR may be useful, 356 though not as a replacement for the VR-MIB module. If the platform 357 supports instantiation of an agent *within* the VR then the VPN user 358 could query stats, etc., from that agent. This would not be a 359 replacement for the VR-MIB module because (in addition to the above 360 points) the Service Provider may very well not have 361 reachability/connectivity (not to mention uniqueness in addressing) 362 into the VPN. For example, the Service Provider may not have 363 management-network access to the customers' networks. 365 4.9.2 Provisioning vs. Monitoring 366 The VR-MIB module goes to some length the support configuration using 367 SNMP. Other MIB modules tend to be for monitoring purposes, with an 368 occasional read-write variable. There is value in having configuration 369 capabilities in this MIB module. The VR-MIB module fills in a gap, 370 allowing for creation of the VR, while the VR context MIB modules allow 371 for configuration of the VR itself. This might prove useful, perhaps 372 even allowing for interoperable management tools. 374 Some Service Provider may intend to use it only for monitoring. This 375 is because there may be other mechanisms available to them for 376 configuration of a specific platforms, such as Corba or XML interfaces 377 that they may find more valuable for this function. 379 5.0 Sample VR MIB module Configuration Scenario 381 5.1 Creation of a VR 383 Creating VR instances can be achieved using the following example. 385 (1) Get the next available Virtual Router Id using the 386 NextAvailableVrId, to create a VR: 388 Using a context with 'read' access for system level entities. 389 GetRequest { NextAvailableVrId.0 } 390 Response { NextAvailableVrId.0 = 5555 } 392 (2) In VrConfigTable, create VR Instance using VrRowStatus: 394 Using a context with 'read-write' access for system level entities 395 SetRequest { 396 VrRowStatus.5555 createAndGo(4), 397 VrName.5555 "BigTelcoVR", 398 VrContextName.5555 "vr5555", 399 VrTrapEnable.5555 true(1), 400 VrAdminStatus.5555 up(1) 401 } 403 6.0 Definition of the Virtual Router MIB Module 405 -- 406 -- VIRTUAL-ROUTER-MIB 407 -- 409 VIRTUAL-ROUTER-MIB DEFINITIONS ::= BEGIN 411 IMPORTS 412 InterfaceIndex 413 FROM IF-MIB 414 InetAddressType, InetAddress 415 FROM INET-ADDRESS-MIB 416 -- RFC Ed.: VPN-TC-STD-MIB in Last Call in L3VPN WG 417 VPNId 418 FROM VPN-TC-STD-MIB 419 OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP 420 FROM SNMPv2-CONF 421 Unsigned32, OBJECT-TYPE, MODULE-IDENTITY, TimeTicks, 422 NOTIFICATION-TYPE, mib-2 423 FROM SNMPv2-SMI 424 TruthValue, DisplayString, RowStatus, TEXTUAL-CONVENTION 425 FROM SNMPv2-TC; 427 virtualRouterMIB MODULE-IDENTITY 428 LAST-UPDATED "200507221200Z" 429 ORGANIZATION 430 "IETF L3VPN WG" 431 CONTACT-INFO 433 " 434 Elwin Stelzer Eliazer 435 Corona Networks, Inc. 436 630 Alder Drive 437 Milpitas, CA 95035 438 USA 439 Phone: +1-408-519-3832 440 Email: elwinietf@yahoo.com 442 Samuel Hancock 443 ACM Systems 444 3034 Gold Canal Drive 445 Rancho Cordova, CA 95670 446 USA 447 Phone: +1-916-463-7949 448 Email: hancoc_s@yahoo.com 450 Benson Schliesser 451 SAVVIS Communications 452 1 Savvis Parkway 453 Town and Country, MO 63017 454 USA 455 Phone: +1-314-628-7036 456 Email: bensons@savvis.net 458 Joseph Laria (Editor) 459 Level Stream Research 460 Wilmington, MA 01887 461 USA 462 Phone: +1-978-223-9908 463 Email: jlaria@levelstream.com 464 " 466 DESCRIPTION 467 "The MIB module is the definition of the managed 468 objects for the Virtual Router." 469 REVISION "200507221200Z" -- 22 July 2005 12:00:00 GMT 470 DESCRIPTION "Initial version, published as RFC yyyy." 471 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 472 ::= { mib-2 xxxx } -- To be assigned 473 -- RFC Ed.: replace xxxx with IANA-assigned number & remove this note 475 -- 476 -- Textual conventions 477 -- 479 VrIdentifier ::= TEXTUAL-CONVENTION 480 STATUS current 481 DESCRIPTION 482 "Virtual Router Identifier. 483 VRID 0 is reserved for the Administrative VR 484 and cannot be used to create VR's. 485 " 486 SYNTAX Unsigned32 (0..4294967295) 488 VrRpTriggerBitCode ::= TEXTUAL-CONVENTION 489 STATUS current 490 DESCRIPTION 491 "This object represents Routing Protocol (RP) 492 Triggers on a Virtual Router. The BITS 493 represent an Action-code that specifies the 494 action on the Routing Protocols. 496 The actions are: initiate or shutdown. 498 When encoding the RP using the BITS construct, 499 the value is encoded as an OCTET STRING where 500 the first bit (bit 0) is the highest bit of the 501 octet. 503 Bits 0-3 may be specified in any combination to 504 allow multiple Routing Protocols to be acted on 505 simultaneously or individually. 506 " 507 SYNTAX BITS { 508 rip (0), 509 ospf(1), 510 bgp (2), 511 isis (3) 512 } 514 -- 515 -- Node definitions 516 -- 518 vrMIBObjects OBJECT IDENTIFIER ::= { virtualRouterMIB 1 } 520 vrConfig OBJECT IDENTIFIER ::= { vrMIBObjects 1 } 522 vrConfigScalars OBJECT IDENTIFIER ::= { vrConfig 1 } 524 vrConfigNextAvailableVrId OBJECT-TYPE 525 SYNTAX VrIdentifier 526 MAX-ACCESS read-only 527 STATUS current 528 DESCRIPTION 529 "The next available Virtual Router Id (index). 530 This object provides a hint for the vrID value 531 to use when administratively creating a new 532 vrConfigEntry. 534 A GET of this object returns the next available vrId 535 value to be used to create an entry in the associated 536 vrConfigTable; or zero, if no valid vrId 537 value is available. A value of zero(0) indicates that 538 it is not possible to create a new vrConfigEntry 539 This object also returns a value of zero when it is the 540 lexicographic successor of a varbind presented in an 541 SNMP GETNEXT or GETBULK request, for which circumstance 542 it is assumed that ifIndex allocation is unintended. 544 Successive GETs will typically return different 545 values, thus avoiding collisions among cooperating 546 management clients seeking to create table entries 547 simultaneously. 549 Unless specified otherwise by its MAX-ACCESS and 550 DESCRIPTION clauses, an object of this type is read-only, 551 and a SET of such an object returns a notWritable error." 552 ::= { vrConfigScalars 1 } 554 vrConfigTable OBJECT-TYPE 555 SYNTAX SEQUENCE OF VrConfigEntry 556 MAX-ACCESS not-accessible 557 STATUS current 558 DESCRIPTION 559 "This table is for creating the new Virtual Routers." 560 ::= { vrConfig 2 } 562 vrConfigEntry OBJECT-TYPE 563 SYNTAX VrConfigEntry 564 MAX-ACCESS not-accessible 565 STATUS current 566 DESCRIPTION 567 "The entries in this table can be added/deleted 568 using the vrRowStatus." 569 INDEX { vrId } 570 ::= { vrConfigTable 1 } 572 VrConfigEntry ::= 573 SEQUENCE { 574 vrId 575 VrIdentifier, 576 vrRowStatus 577 RowStatus, 578 vrName 579 DisplayString, 580 vrContextName 581 DisplayString, 582 vrTrapEnable 583 TruthValue, 584 vrMaxRoutes 585 Unsigned32, 586 vrAdminStatus 587 INTEGER, 588 vrVpnId 589 VPNId, 590 vrRpTrigger 591 VrRpTriggerBitCode, 592 vrMaxRoutesTrapEnable 593 TruthValue 594 } 596 vrId OBJECT-TYPE 597 SYNTAX VrIdentifier 598 MAX-ACCESS not-accessible 599 STATUS current 600 DESCRIPTION 601 "The unique id of this virtual router instance. A Virtual 602 Router cannot not be created with vrId = 0. 603 VRID 0 is reserved for the Administrative VR. 604 " 605 ::= { vrConfigEntry 1 } 607 vrRowStatus OBJECT-TYPE 608 SYNTAX RowStatus 609 MAX-ACCESS read-create 610 STATUS current 611 DESCRIPTION 612 "The status column has three defined values: 614 - `active', which indicates that the conceptual row is 615 available for use by the managed device; 616 - `createAndGo', which is supplied by a management 617 station wishing to create a new instance of a 618 conceptual row and to have its status automatically set 619 to active, making it available for use by the managed 620 device; 622 - `destroy', which is supplied by a management station 623 wishing to delete all of the instances associated with 624 an existing conceptual row." 625 ::= { vrConfigEntry 2 } 627 vrName OBJECT-TYPE 628 SYNTAX DisplayString 629 MAX-ACCESS read-create 630 STATUS current 631 DESCRIPTION 632 "The Name of the Virtual Router." 633 ::= { vrConfigEntry 3 } 635 vrContextName OBJECT-TYPE 636 SYNTAX DisplayString 637 MAX-ACCESS read-create 638 STATUS current 639 DESCRIPTION 640 "The SNMPv2 Community String or SNMPv3 contextName 641 denotes the VR 'context' and is used to logically 642 separate the MIB module management." 643 ::= { vrConfigEntry 4 } 645 vrTrapEnable OBJECT-TYPE 646 SYNTAX TruthValue 647 MAX-ACCESS read-create 648 STATUS current 649 DESCRIPTION 650 "This objects is used to enable the generation 651 of the VrUp and VrDown traps. 652 true(1) - VR Traps Enabled 653 false(2) - VR Traps Disabled" 654 DEFVAL { true } 655 ::= { vrConfigEntry 5 } 657 vrMaxRoutes OBJECT-TYPE 658 SYNTAX Unsigned32 659 MAX-ACCESS read-create 660 STATUS current 661 DESCRIPTION 662 "This object specifies the maximum number of routes that 663 this VR can support. The default value is 4 Gig (meaning 664 unlimited)." 665 DEFVAL { 4294967295 } 666 ::= { vrConfigEntry 6 } 668 vrAdminStatus OBJECT-TYPE 669 SYNTAX INTEGER { 670 up(1), 671 down(2), 672 testing(3), 673 unknown(4) 674 } 675 MAX-ACCESS read-create 676 STATUS current 677 DESCRIPTION 678 "The administrative state of the Virtual Router." 679 DEFVAL { down } 680 ::= { vrConfigEntry 7 } 682 vrVpnId OBJECT-TYPE 683 SYNTAX VPNId 684 MAX-ACCESS read-create 685 STATUS current 686 DESCRIPTION 687 "The Virtual Private Network Identifier of the Virtual 688 Router." 689 ::= { vrConfigEntry 8 } 691 vrRpTrigger OBJECT-TYPE 692 SYNTAX VrRpTriggerBitCode 693 MAX-ACCESS read-create 694 STATUS current 695 DESCRIPTION 696 "This object represents Routing Protocol (RP) 697 Triggers on a Virtual Router and it meant to 698 be used to initiate or shutdown routing 699 protocols on a VR. Multiple RPs can be acted 700 on simultaneously. Also, individual RPs can 701 be brought up in steps, which should not 702 affect the RPs that were running. The BITS 703 represent an Action-code that specifies what 704 action is to be performed for the RPs. 705 The actions are: initiate(1) or shutdown(0). 707 The running status of an RP shall be available 708 in the VR stats table's vrRpStatus, which has 709 a similar format, but represents the status. 711 Bits 0-3 may be specified in any combination. 712 Individual routing protocols may be enabled 713 and disabled independently. Protocols are 714 enabled by setting the respective BIT and are 715 disabled by resetting the BIT. 717 So, for example, to enable RIP and BGP protocols 718 the vrRpTrigger bits 0 and 2 need to be set, and 719 as encoded as 10100000. 720 All zeros should be interpreted as all protocols 721 disable. 722 " 723 DEFVAL { '00000000'b } 724 ::= { vrConfigEntry 9 } 725 vrMaxRoutesTrapEnable OBJECT-TYPE 726 SYNTAX TruthValue 727 MAX-ACCESS read-create 728 STATUS current 729 DESCRIPTION 730 "This objects is used to enable the generation 731 of the VR Max Routes Exceeded traps. 732 true(1) - VR Max Routes Exceeded Traps Enabled 733 false(2) - VR Max Routes Exceeded Traps Disabled" 734 DEFVAL { true } 735 ::= { vrConfigEntry 10 } 737 vrStat OBJECT IDENTIFIER ::= { vrMIBObjects 2 } 739 vrStatScalars OBJECT IDENTIFIER ::= { vrStat 1 } 741 vrConfiguredVRs OBJECT-TYPE 742 SYNTAX Unsigned32 743 MAX-ACCESS read-only 744 STATUS current 745 DESCRIPTION 746 "The number of VRs configured on this network element." 747 ::= { vrStatScalars 1 } 749 vrActiveVRs OBJECT-TYPE 750 SYNTAX Unsigned32 751 MAX-ACCESS read-only 752 STATUS current 753 DESCRIPTION 754 "The number of VRs that are active on the network element. 755 These are VRs for which the 756 vrStatOperStatus = up(1)" 757 ::= { vrStatScalars 2 } 759 vrStatTable OBJECT-TYPE 760 SYNTAX SEQUENCE OF VrStatEntry 761 MAX-ACCESS not-accessible 762 STATUS current 763 DESCRIPTION 764 "This table contains statistics for the Virtual Router." 765 ::= { vrStat 2 } 767 vrStatEntry OBJECT-TYPE 768 SYNTAX VrStatEntry 769 MAX-ACCESS not-accessible 770 STATUS current 771 DESCRIPTION 772 "Entries in this table a per vrId." 773 INDEX { vrId } 774 ::= { vrStatTable 1 } 776 VrStatEntry ::= 777 SEQUENCE { 778 vrStatRouteEntries 779 Unsigned32, 780 vrStatFIBEntries 781 Unsigned32, 782 vrStatUpTime 783 TimeTicks, 784 vrOperStatus 785 INTEGER, 786 vrRpStatus 787 VrRpTriggerBitCode, 788 vrRouterAddressType 789 InetAddressType, 790 vrRouterAddress 791 InetAddress 792 } 794 vrStatRouteEntries OBJECT-TYPE 795 SYNTAX Unsigned32 796 MAX-ACCESS read-only 797 STATUS current 798 DESCRIPTION 799 "Total number of routes for this VR." 800 ::= { vrStatEntry 1 } 802 vrStatFIBEntries OBJECT-TYPE 803 SYNTAX Unsigned32 804 MAX-ACCESS read-only 805 STATUS current 806 DESCRIPTION 807 "Total number of FIB Entries for this VR." 808 ::= { vrStatEntry 2 } 810 vrStatUpTime OBJECT-TYPE 811 SYNTAX TimeTicks 812 MAX-ACCESS read-only 813 STATUS current 814 DESCRIPTION 815 "The time in (in hundredths of a second) since 816 this VR entry has been operational." 817 ::= { vrStatEntry 3 } 819 vrOperStatus OBJECT-TYPE 820 SYNTAX INTEGER { 821 up(1), 822 down(2), 823 unknown(3) 824 } 825 MAX-ACCESS read-only 826 STATUS current 827 DESCRIPTION 828 "The operational status of the Virtual Router." 829 ::= { vrStatEntry 4 } 831 vrRpStatus OBJECT-TYPE 832 SYNTAX VrRpTriggerBitCode 833 MAX-ACCESS read-only 834 STATUS current 835 DESCRIPTION 836 "This object represents the status of Routing 837 Protocols on this VR corresponding to the list 838 of RP specified in vrRpTrigger. 840 The BITS represent an Action-code that specifies 841 the status of the RPs. 842 The status are: initiated (1) or shutdown (0). 843 Initiated status is indicated when the respective 844 BIT value is 1 and indicates shutdown when the 845 respective BIT value is 0. 847 Bits 0-3 may appear in any combination to 848 indicate that RPs may be enabled and disabled 849 independently or that multiple RP are acted on 850 simultaneously. 851 " 852 ::= { vrStatEntry 5 } 854 vrRouterAddressType OBJECT-TYPE 855 SYNTAX InetAddressType 856 MAX-ACCESS read-only 857 STATUS current 858 DESCRIPTION 859 "Router Address Type of this VR." 860 ::= { vrStatEntry 6 } 862 vrRouterAddress OBJECT-TYPE 863 SYNTAX InetAddress 864 MAX-ACCESS read-only 865 STATUS current 866 DESCRIPTION 867 "Router Address of this VR. It is derived from one of the 868 interfaces. If loopback interface is present, the loopback 869 interface address can be used. However, loopback interface 870 is optional." 871 ::= { vrStatEntry 7 } 873 vrIfConfig OBJECT IDENTIFIER ::= { vrMIBObjects 3 } 875 vrIfConfigScalars OBJECT IDENTIFIER ::= { vrIfConfig 1 } 877 vrIfConfigTable OBJECT-TYPE 878 SYNTAX SEQUENCE OF VrIfConfigEntry 879 MAX-ACCESS not-accessible 880 STATUS current 881 DESCRIPTION 882 "This table is for configuring VR Interfaces." 883 ::= { vrIfConfig 2 } 885 vrIfConfigEntry OBJECT-TYPE 886 SYNTAX VrIfConfigEntry 887 MAX-ACCESS not-accessible 888 STATUS current 889 DESCRIPTION 890 "Entries in this table correspond to the entries in 891 the ifTable that apply to the Virtual Router." 892 INDEX { vrId, 893 vrIfId } 894 ::= { vrIfConfigTable 1 } 896 VrIfConfigEntry ::= 897 SEQUENCE { 898 vrIfId 899 InterfaceIndex, 900 vrIfConfigRowStatus 901 RowStatus 902 } 904 vrIfId OBJECT-TYPE 905 SYNTAX InterfaceIndex 906 MAX-ACCESS not-accessible 907 STATUS current 908 DESCRIPTION 909 "Virtual Router Interface Index." 910 ::= { vrIfConfigEntry 1 } 912 vrIfConfigRowStatus OBJECT-TYPE 913 SYNTAX RowStatus 914 MAX-ACCESS read-create 915 STATUS current 916 DESCRIPTION 917 " This object is used to create, delete or 918 modify a row in this table." 919 ::= { vrIfConfigEntry 2 } 921 -- ******************************************************************* 922 -- Module Traps/Notifications 923 -- ******************************************************************* 925 vrNotificationsPrefix OBJECT IDENTIFIER ::= { vrMIBObjects 4 } 927 vrNotifications OBJECT IDENTIFIER ::= { vrNotificationsPrefix 0 } 929 vrUp NOTIFICATION-TYPE 930 OBJECTS { vrOperStatus } 931 STATUS current 932 DESCRIPTION 933 "This notification is generated when the specified 934 VR is about to be initialized or change the VR's 935 operational status from down to up." 936 ::= { vrNotifications 1 } 938 vrDown NOTIFICATION-TYPE 939 OBJECTS { vrOperStatus } 940 STATUS current 941 DESCRIPTION 942 "This notification is generated when the specified 943 VR's operational status is about to go down." 944 ::= { vrNotifications 2 } 946 vrMaxRoutesExceeded NOTIFICATION-TYPE 947 OBJECTS { vrRowStatus, vrMaxRoutes, vrStatRouteEntries } 948 STATUS current 949 DESCRIPTION 950 "This notification is generated when the specified VR has 951 exceeded the maximum number of routes specified. 952 " 953 ::= { vrNotifications 3 } 955 -- ******************************************************************* 956 -- Module Compliance/Conformance Statements 957 -- ******************************************************************* 959 vrConformance OBJECT IDENTIFIER ::= { virtualRouterMIB 2 } 961 vrCompliances OBJECT IDENTIFIER ::= { vrConformance 1 } 963 vrMIBCompliance MODULE-COMPLIANCE 964 STATUS current 965 DESCRIPTION 966 "The compliance statement for entities that implement the 967 VIRTUAL-ROUTER-MIB. Implementation of this MIB module 968 is strongly recommended for any platform targeted for a 969 carrier-class environment. 970 When this MIB module is implemented with support for 971 read-create, then such an implementation can claim full 972 compliance. 973 Such devices can then be both monitored and configured 974 with this MIB." 975 MODULE -- this module 976 MANDATORY-GROUPS { vrConfigGroup, vrStatGroup, 977 vrIfGroup, vrNotificationGroup } 978 ::= { vrCompliances 1 } 980 vrGroups OBJECT IDENTIFIER ::= { vrConformance 2 } 982 vrConfigGroup OBJECT-GROUP 983 OBJECTS { vrRowStatus, vrName, 984 vrContextName, vrTrapEnable, 985 vrMaxRoutes, vrAdminStatus, 986 vrVpnId, vrRpTrigger, 987 vrMaxRoutesTrapEnable, 988 vrConfigNextAvailableVrId } 989 STATUS current 990 DESCRIPTION 991 "A collection of attributes that support provisioning 992 of a virtual router." 993 ::= { vrGroups 1 } 995 vrStatGroup OBJECT-GROUP 996 OBJECTS { vrConfiguredVRs, vrActiveVRs, 997 vrStatRouteEntries, vrStatFIBEntries, vrStatUpTime, 998 vrOperStatus, vrRpStatus, vrRouterAddress, 999 vrRouterAddressType } 1000 STATUS current 1001 DESCRIPTION 1002 "A collection of attributes that contain stats about the 1003 virtual router." 1004 ::= { vrGroups 2 } 1006 vrIfGroup OBJECT-GROUP 1007 OBJECTS { vrIfConfigRowStatus } 1008 STATUS current 1009 DESCRIPTION 1010 "A collection of attributes that support provisioning of 1011 a virtual router interfaces." 1012 ::= { vrGroups 3 } 1014 vrNotificationGroup NOTIFICATION-GROUP 1015 NOTIFICATIONS { vrUp, vrDown, vrMaxRoutesExceeded } 1016 STATUS current 1017 DESCRIPTION 1018 "A collection of traps that are supported by the VR." 1019 ::= { vrGroups 4 } 1021 END 1023 7.0 Acknowledgments 1025 Funding for the RFC Editor function is currently provided by the 1026 Internet Society. 1028 Special thanks to Joan Cucchiara for providing valuable comments 1029 on this MIB. 1031 8.0 Security Considerations 1033 There are a number of management objects defined in this MIB module 1034 with a MAX-ACCESS clause of read-write and/or read-create. Such 1035 objects may be considered sensitive or vulnerable in some network 1036 environments. The support for SET operations in a non-secure 1037 environment without proper protection can have a negative effect on 1038 network operations. These are the tables and objects and their 1039 sensitivity/vulnerability: 1041 The Administrative VR provides visibility into and control over 1042 multiple VPNs. As such, security considerations for implementations 1043 of the Administrative VR and associated control plane(s) are critical 1044 to the security of the VPNs supported on each PE device. 1046 Some of the readable objects in this MIB module (i.e., objects with a 1047 MAX-ACCESS other than not-accessible) may be considered sensitive or 1048 vulnerable in some network environments. It is thus important to 1049 control even GET and/or NOTIFY access to these objects and possibly 1050 to even encrypt the values of these objects when sending them over 1051 the network via SNMP. These are the tables and objects and their 1052 sensitivity/vulnerability: 1054 Use of any vrContextName MUST be allowed in the Administrative VR. 1055 Additional authentication and security mechanisms SHOULD be used for 1056 SNMP access in the Administrative VR. 1058 VRs other than the Administrative VR MUST NOT have access to other 1059 VR's Instantiated MIB modules, and MAY have access to their own 1060 instantiated MIB modules. 1062 In VRs other than the Administrative VR, access to that VR's 1063 instantiated MIB modules MAY be permitted via that VR's vrContextName. 1064 Use of any vrContextName other than that assigned to the accessed VR 1065 MUST result in an error, and implementations SHOULD provide a logging 1066 mechanism for such events. 1068 SNMP versions prior to SNMPv3 did not include adequate security. 1069 Even if the network itself is secure (for example by using IPSec), 1070 even then, there is no control as to who on the secure network is 1071 allowed to access and GET/SET (read/change/create/delete) the objects 1072 in this MIB module. 1074 It is RECOMMENDED that implementers consider the security features as 1075 provided by the SNMPv3 framework (see [RFC3410], section 8), 1076 including full support for the SNMPv3 cryptographic mechanisms 1077 (for authentication and privacy). 1079 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1080 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1081 enable cryptographic security. It is then a customer/operator 1082 responsibility to ensure that the SNMP entity giving access to an 1083 instance of this MIB module is properly configured to give access to 1084 the objects only to those principals (users) that have legitimate 1085 rights to indeed GET or SET (change/create/delete) them. 1087 9.0 References 1089 9.1 Normative References 1091 [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture 1092 for Describing SNMP Management Frameworks", RFC 2571, April 1999. 1094 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1095 Requirements Levels", BCP 14, RFC 2119, March 1997. 1097 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1098 Rose, M. and S. Waldbusser, "Structure of Management 1099 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1100 1999. 1102 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1103 Rose, M. and S. Waldbusser, "Textual Conventions for 1104 SMIv2", STD 58, RFC 2579, April 1999. 1106 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1107 Rose, M. and S. Waldbusser, "Conformance Statements for 1108 SMIv2", STD 58, RFC 2580, April 1999. 1110 [VPNTCMIB] B. Schliesser, and T. Nadeau, "Definition of Textual 1111 Conventions for Provider Provisioned Virtual Private Network 1112 (PPVPN) Management.", Internet Draft 1113 , May 2004. 1115 9.2 Informative References 1117 [RFC2685] Fox B., et al, "Virtual Private Networks 1118 Identifier", RFC 2685, September 1999. 1120 [PPVPN-FW] R. Callon, et al., "A Framework for Layer 3 Provider 1121 Provisioned Virtual Private Networks", 1122 draft-ietf-l3vpn-framework-00.txt, March 2003. 1124 [PPVPN-VR] P. Knight, et al., "Network based IP VPN Architecture 1125 using Virtual Routers", draft-ietf-l3vpn-vpn-vr-02.txt, 1126 April 2004. 1128 [PPVPN-VR-AS] A. Nagarajan, et al., "Applicability Statement for 1129 Virtual Router-based Layer 3 PPVPN approaches", 1130 draft-ietf-l3vpn-as-vr-01.txt, March 2004. 1132 10.0 Authors' Addresses 1134 Elwin Stelzer Eliazer 1135 Corona Networks, Inc. 1136 630 Alder Drive 1137 Milpitas, CA 95035 1138 USA 1139 Phone: +1-408-519-3832 1140 Email: elwinietf@yahoo.com 1142 Samuel Hancock 1143 ACM Systems 1144 3034 Gold Canal Drive 1145 Rancho Cordova, CA 94123 1146 USA 1147 Phone: +1-916-463-7949 1148 Email: hancoc_s@yahoo.com 1150 Benson Schliesser 1151 SAVVIS Communications 1152 1 Savvis Parkway 1153 Town and Country, MO 63017 1154 USA 1155 Phone: +1-314-628-7036 1156 Email: bensons@savvis.net 1158 Joseph Laria 1159 Level Stream Research 1160 Wilmington, MA 01887 1161 USA 1162 Phone: +1-978-223-9908 1163 Email: jlaria@levelstream.com 1165 11.0 Intellectual Property Considerations 1167 The IETF takes no position regarding the validity or scope of any 1168 Intellectual Property Rights or other rights that might be claimed 1169 to pertain to the implementation or use of the technology described 1170 in this document or the extent to which any license under such rights 1171 might or might not be available; nor does it represent that it has 1172 made any independent effort to identify any such rights. Information 1173 on the procedures with respect to rights in RFC documents can be 1174 found in BCP 78 and BCP 79. 1176 Copies of IPR disclosures made to the IETF Secretariat and any 1177 assurances of licenses to be made available, or the result of an 1178 attempt made to obtain a general license or permission for the use 1179 of such proprietary rights by implementers or users of this 1180 specification can be obtained from the IETF on-line IPR repository 1181 at http://www.ietf.org/ipr. 1183 The IETF invites any interested party to bring to its attention any 1184 copyrights, patents or patent applications, or other proprietary 1185 rights that may cover technology that may be required to implement 1186 this standard. Please address the information to the IETF at 1187 ietf-ipr@ietf.org. 1189 12.0 Full Copyright Statement 1191 Copyright (C) The Internet Society (2005). 1193 This document is subject to the rights, licenses and restrictions 1194 contained in BCP 78, and except as set forth therein, the authors 1195 retain all their rights. 1197 This document and the information contained herein are provided on 1198 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1199 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1200 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1201 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1202 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1203 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1205 13.0 IANA Considerations for L3VPN-VR-MIB Module 1207 The IANA is requested to assign { mib-2 XXXX } to the 1208 L3VPN-VR-MIB module specified in this document.