idnits 2.17.1 draft-ietf-ppvpn-vr-mib-05.txt: ** The Abstract section seems to be numbered -(281): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(946): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(949): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(950): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1102 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 22 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 166 has weird spacing: '...ving to modif...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7620 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: '11' is mentioned on line 110, but not defined == Missing Reference: '12' is mentioned on line 111, but not defined == Missing Reference: '13' is mentioned on line 117, but not defined == Missing Reference: '14' is mentioned on line 119, but not defined == Unused Reference: '16' is defined on line 1000, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1008, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1012, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (ref. '1') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '9') ** Obsolete normative reference: RFC 1906 (ref. '10') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2575 (ref. '15') (Obsoleted by RFC 3415) == Outdated reference: A later version (-03) exists of draft-ouldbrahim-vpn-vr-01 -- Possible downref: Normative reference to a draft: ref. '17' ** Downref: Normative reference to an Informational RFC: RFC 2764 (ref. '19') == Outdated reference: A later version (-04) exists of draft-rosen-rfc2547bis-03 -- Possible downref: Normative reference to a draft: ref. '20' == Outdated reference: A later version (-01) exists of draft-declercq-bgp-ipsec-vpn-00 -- Possible downref: Normative reference to a draft: ref. '21' ** Obsolete normative reference: RFC 2667 (ref. '22') (Obsoleted by RFC 4087) -- No information found for draft-ietf-ppvpn-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PPVPN-FW' -- No information found for draft-ietf-ppvpn-vpn-vr - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PPVPN-VR' -- No information found for draft-ietf-ppvpn-as-vr - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PPVPN-VR-AS' Summary: 15 errors (**), 0 flaws (~~), 18 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Elwin Stelzer 2 draft-ietf-ppvpn-vr-mib-05.txt Sam Hancock 3 Expires: December 2003 Corona Networks, Inc. 5 Benson Schliesser 6 SAVVIS Communications 8 Joseph Laria 9 Level Stream Research 11 June 2003 13 Virtual Router Management Information Base Using SMIv2 15 1.0 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 2.0 Abstract 37 This memo defines a portion of the Management Information Base (MIB) 38 for use with network management protocols in TCP/IP based internets. 39 In particular, it defines objects for managing networks using Virtual 40 Routers (VR). 42 3.0 Table of Contents 44 1.0 Status of this Memo 45 2.0 Abstract 46 3.0 Table of Contents 47 4.0 Terminology 48 5.0 Introduction 49 6.0 The SNMP Network Management Framework 50 7.0 Overview of the Virtual Router MIB 51 7.1 SNMP Contexts for Management for Virtual Routers 52 7.2 VR Indexing 53 7.3 Creation and Deletion of VRs 54 7.4 Administrative and Operational Status of VRs 55 7.5 Binding interfaces to a VR 56 7.6 Setting per VR limits 57 7.7 Per VR Statistics 58 7.8 Traps 59 8.0 Sample VR MIB Configuration Scenario 60 8.1 Creation of a VR 61 9.0 Definition of the Virtual Router MIB 62 10.0 Summary for Sub-IP Area 63 10.1 Where does it fit in the Picture of the Sub-IP Work 64 10.2 Why is it Targeted at this WG 65 10.3 Justification 66 11.0 Security Considerations 67 12.0 Acknowledgments 68 13.0 References 69 14.0 Authors' Addresses 71 4.0 Terminology 73 This document uses terminology defined in [PPVPN-FW] and [PPVPN-VR]. 75 5.0 Introduction 77 This memo defines a MIB for the Virtual Router [PPVPN-VR, PPVPN-VR-AS] 78 model of Provider Provisioned VPNs [PPVPN-FW]. 80 Following are the goals, in defining this MIB: 82 - To have a means for Service Providers to provision VPN service for 83 subscribers, at the PE device. 85 - To make the agent-side implementation simple, by not modifying the 86 existing standard MIBs. 88 - Define all the gluing tables that are needed toward this end. 90 6.0 The SNMP Network Management Framework 92 The SNMP Management Framework presently consists of five major 93 components: 95 o An overall architecture, described in RFC 2571 [1]. 97 o Mechanisms for describing and naming objects and events for the 98 purpose of management. The first version of this Structure of 99 Management Information (SMI) is called SMIv1 and described in 100 STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. 101 The second version, called SMIv2, is described in STD 58, which 102 consists of RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. 104 o Message protocols for transferring management information. The 105 first version of the SNMP message protocol is called SNMPv1 and 106 described in STD 15, RFC 1157 [8]. A second version of the 107 SNMP message protocol, which is not an Internet standards track 108 protocol, is called SNMPv2c and described in RFC 1901 [9] and 109 RFC 1906 [10]. The third version of the message protocol is 110 called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and 111 RFC 2574 [12]. 113 o Protocol operations for accessing management information. The 114 first set of protocol operations and associated PDU formats is 115 described in STD 15, RFC 1157 [8]. A second set of protocol 116 operations and associated PDU formats is described in RFC 1905 117 [13]. 119 o A set of fundamental applications described in RFC 2573 [14] 120 and the view-based access control mechanism described in RFC 121 2575 [15]. 123 A more detailed introduction to the current SNMP Management Framework 124 can be found in RFC 2570 [22]. 126 Managed objects are accessed via a virtual information store, termed 127 the Management Information Base or MIB. Objects in the MIB are 128 defined using the mechanisms defined in the SMI. 130 This memo specifies a MIB module that is compliant to the SMIv2. A 131 MIB conforming to the SMIv1 can be produced through the appropriate 132 translations. The resulting translated MIB must be semantically 133 equivalent, except where objects or events are omitted because no 134 translation is possible (e.g., use of Counter64). Some machine 135 readable information in SMIv2 will be converted into textual 136 descriptions in SMIv1 during the translation process. However, this 137 loss of machine readable information is not considered to change the 138 semantics of the MIB. 140 7.0 Overview of the Virtual Router MIB 142 7.1 SNMP Contexts for Management for Virtual Routers 144 There is a need for a single agent to manage multiple Virtual Routers. 145 The Architecture for describing Internet Management Frameworks [1] 146 provides a way to support such cases. 148 Managing multiple virtual routers requires that the PE management plane be 149 subdivided into logical VR management domains. In the VR model of PPVPNs 150 a single PE device may contain many virtual routers. Different management 151 entities SHOULD be able to manage specific virtual routers and associated 152 services. The Service Provider MUST be able to manage all virtual routers 153 and associated services. 155 Using SNMP contexts to group a collection of management information 156 provides the following benefits: 158 (1) Uses a standard framework defined by the IETF, allowing the 159 product to remain flexible to all implementations of virtual 160 router devices. 162 (a) Use SNMPv2c Community String's 164 (b) Use SNMPv3 contextName's 166 (2) Prevents vendors from having to modify the 167 standard MIBs, allowing the implementation to remain standards 168 compliant. 170 (3) Provides a framework that will work for RIP, OSPF, IS-IS, BGP, 171 IP-FORWARDING, MPLS, and any other MIB that can be administratively 172 grouped with a VR. 174 The SNMP context for the Virtual Router instance can be specified in 175 the VrConfigTable. The VrContextName columnar object is used to set the 176 SNMPv2c Community String or the SNMPv3 contextName for a given VR. 178 A virtual router context represents the set of MIB objects that could be 179 administratively grouped within a VR. For example, each VR would maintain 180 its own instance of routing protocol MIB tables. However, the ADMIN context 181 would contain single instances of objects and tables that pertain to system 182 wide configuration such as the Entity, Interfaces, and ATM MIBs. 184 A management system using the SNMP context of a particular virtual 185 router MUST be able to manage the virtual router without disrupting other 186 virtual routers in the same PE device. 188 For example, a PE can be subdivided into two 2 VRs running the OSPF routing 189 protocol. Each VR will maintain a unique instance of the OSPF-MIB. 190 Therefore, the ospfAreaTable of VR-A is distinct from the 191 ospfAreaTable of VR-B. 193 +-----------------------------------------------------------------+ 194 | +------------------------------------------------------------+ | 195 | | SNMP entity (including Engine, Applications) | | 196 | | | | 197 | | example contextNames: | | 198 | | | | 199 | | "vr01" "vr09" "admin" | | 200 | | --------- --------- ------------ | | 201 | | | | | | | 202 | +------|------------------|-------------------|--------------+ | 203 | | | | | 204 | +------|------------------|-------------------|--------------+ | 205 | | MIB | instrumentation | | | | 206 | | +---v------------+ +---v------------+ +----v-----------+ | | 207 | | | context=vr01 | | context=vr09 | | context=admin | | | 208 | | | | | | | | | | 209 | | | +------------+ | | +------------+ | | +------------+ | | | 210 | | | | OSPF MIB | | | | OSPF MIB | | | | VR MIB | | | | 211 | | | +------------+ | | +------------+ | | +------------+ | | | 212 | | | | | | | | | | 213 | | | +------------+ | | +------------+ | | +------------+ | | | 214 | | | | BGP MIB | | | | BGP MIB | | | | ATM MIB | | | | 215 | | | +------------+ | | +------------+ | | +------------+ | | | 216 | | | | | | | | | | 217 | | | +------------+ | | +------------+ | | +------------+ | | | 218 | | | | IP MIB | | | | IP MIB | | | | ENTITY MIB | | | | 219 | | | +------------+ | | +------------+ | | +------------+ | | | 220 | | | | | | | | | | 221 | | | +------------+ | | +------------+ | | +------------+ | | | 222 | | | | other MIB | | | | other MIB | | | | IF MIB | | | | 223 | | | +------------+ | | +------------+ | | +------------+ | | | 224 | | | ... | | ... | | ... | | | 225 +-----------------------------------------------------------------+ 227 Filtering mechanisms based on the SNMP context of a particular virtual router 228 may implemented to allow different management entities to manage those objects 229 and services provisioned the �Admin� context. 231 7.2 VR Indexing 233 While the standard protocol MIB tables are instantiated in the 234 context specified using SNMP contexts, there may be tables that are 235 defined with the VRID as index. 237 The VRID is of local significance to a particular PE device, and need 238 not be globally unique. Thus a particular VRID value assigned to a VR 239 in one PE device may indicate a different VR in another PE device. 241 The VRID has an Unsigned32 value, and this value is assigned by the management 242 station. To aid the management station in assigning a VRID without conflict, 243 the management station can get the 'NextAvailableVRID' from the PE device. 244 A SNMP manager SHOULD NOT assume global significance of any VRID value 245 other than 0. 247 For those MIB tables instantiated in the virtual router context, indexing can 248 only be assumed unique for that particular VR. However those indices in the 249 "ADMIN" context are unique across the entire system, including all VRs. 251 7.3 Creation and Deletion of VRs 253 The VR Config Table is used for this purpose. This is a read-create 254 table and adding an entry into this table will create a VR. Removing 255 an entry from this table marks the deletion of a VR. 257 VRID 0 is assigned to the Administrative VR, which exists by default, 258 and need not be created. Deletion of the Administrative VR will not be 259 permitted. The VRID of the Administrative VR (VRID 0) should be a 260 reserved VRID number. VRID 0 could be termed the "null VR" and it could 261 be the context that manages the resource pool of unattached interfaces. 262 Routing would then not exist in the context of Administrative VR. 264 7.4 Administrative and Operational Status of VRs 266 VRs can be administratively turned down. When this is done, no 267 packet forwarding via the VR takes place. 269 VrOperStatus denotes the operational status of a VR. Currently the 270 VrOperStatus is expected to change along the VrAdminStatus unless an 271 error condition exists. 273 7.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 table is used to indicated the 278 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 7.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 296 in VR. This includes all routes, such as the statically configured routes, 297 and the routes learnt via dynamic routing protocols. 299 7.7 Per VR Statistics 301 In addition to those statistics available through the VR instantiated MIB 302 tables, there are some per-VR statistics available through vrStatTable. 304 7.8 Traps 306 This memo defines that VrUp and VrDown traps are generated just after 307 VrOperStatus leaves, or just before it enters, the down state, 308 respectively. 310 (1) A transition into the down state will occur when an error is 311 detected on a VR instance. 313 (2) Departing the down state generally indicates that the 314 VR is going to up, which is considered a "healthy" state. 316 An exception to the above generation of VrUp/VrDown traps on changes 317 in VrOperStatus, occurs when an VR is "flapping", i.e., when it is 318 rapidly oscillating between the up and down states. If traps were 319 generated for each such oscillation, the network and the network 320 management system would be flooded with unnecessary traps. In such a 321 situation, the agent should limit the rate at which it generates traps. 323 This memo defines that enabling and disabling the VR traps is achieved 324 by setting the VrTrapEnable to true(1) or false(2), respectively. By 325 default, this object should have the value true(1). 327 8.0 Sample VR MIB Configuration Scenario 329 8.1 Creation of a VR 331 Creating VR instances can be achieved using the following example. 333 (1) Get the next available Virtual Router Id using the 334 NextAvailableVrId, to create a VR: 336 Using a context with 'read' access for system level entities. 337 GetRequest { NextAvailableVrId.0 } 338 Response { NextAvailableVrId.0 = 5555 } 340 (2) In VrConfigTable, create VR Instance using VrRowStatus: 342 Using a context with 'read-write' access for system level entities 343 SetRequest { 344 VrRowStatus.5555 createAndGo(4), 345 VrName.5555 "BigTelcoVR", 346 VrContextName.5555 "vr5555", 347 VrTrapEnable.5555 true(1), 348 VrAdminStatus.5555 up(1) 349 } 351 9.0 Definition of the Virtual Router MIB 353 -- 354 -- VIRTUAL-ROUTER-MIB 355 -- 357 VIRTUAL-ROUTER-MIB DEFINITIONS ::= BEGIN 359 IMPORTS 360 InterfaceIndex 361 FROM IF-MIB 362 InetAddressType, InetAddress 363 FROM INET-ADDRESS-MIB 364 OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP 365 FROM SNMPv2-CONF 366 experimental, Unsigned32, OBJECT-TYPE, 367 MODULE-IDENTITY, TimeTicks, NOTIFICATION-TYPE 368 FROM SNMPv2-SMI 369 TruthValue, DisplayString, RowStatus, TEXTUAL-CONVENTION 370 FROM SNMPv2-TC; 372 virtualRouterMIB MODULE-IDENTITY 373 LAST-UPDATED "200301311200Z" 374 ORGANIZATION 375 "IETF PPVPN WG" 376 CONTACT-INFO 377 " 378 Elwin Stelzer Eliazer 379 Corona Networks, Inc. 380 630 Alder Drive 381 Milpitas, CA 95035 382 USA 383 Phone: +1-408-519-3832 384 Email: elwinietf@yahoo.com 386 Samuel Hancock 387 Corona Networks, Inc. 388 630 Alder Drive 389 Milpitas, CA 95035 390 USA 391 Phone: +1-408-519-3800 Ext 421 392 Email: hancoc_s@yahoo.com 394 Benson Schliesser 395 SAVVIS Communications 396 1 Savvis Parkway 397 Town and Country, MO 63017 398 USA 399 Phone: +1-314-628-7036 400 Email: bensons@savvis.net 402 Joseph Laria 403 Level Stream Research 404 Wilmington, MA 01887 405 USA 406 Phone: +1-978-884-3537 407 Emain: jlaria@levelstream.com 408 " 409 DESCRIPTION 410 "The MIB is the definition of the managed 411 objects for the Virtual Router." 412 REVISION "200306011200Z" 413 DESCRIPTION 414 "VR-MIB Draft of the IETF PPVPN WG" 415 ::= { experimental xxxx } -- To be assigned 417 -- 418 -- Textual conventions 419 -- 421 VrId ::= TEXTUAL-CONVENTION 422 STATUS current 423 DESCRIPTION 424 "Virtual Router Identifier. 425 VRID 0 is reserved for the Administrative VR 426 and cannot be used to create VR's. 427 " 428 SYNTAX Unsigned32 430 VpnIdentifier ::= TEXTUAL-CONVENTION 431 STATUS current 432 DESCRIPTION 433 "RFC2685: The global VPN Identifier format is: 434 3 octet VPN authority Organizationally Unique Identifier 435 followed by 436 4 octet VPN index identifying VPN according to OUI" 437 SYNTAX OCTET STRING(SIZE (0..7)) 439 -- 440 -- Node definitions 441 -- 443 vrMIBObjects OBJECT IDENTIFIER ::= { virtualRouterMIB 1 } 445 vrConfig OBJECT IDENTIFIER ::= { vrMIBObjects 1 } 447 vrConfigScalars OBJECT IDENTIFIER ::= { vrConfig 1 } 449 vrConfigNextAvailableVrId OBJECT-TYPE 450 SYNTAX VrId 451 MAX-ACCESS read-only 452 STATUS current 453 DESCRIPTION 454 "The next available Virtual Router Id (index). 455 This object provides a hint for the vrID value 456 to use when administratively creating a new 457 vrConfigEntry. 459 A GET of this object returns the next available vrId 460 value to be used to create an entry in the associated 461 vrConfigTable; or zero, if no valid vrId 462 value is available. A value of zero(0) indicates that 463 it is not possible to create a new vrConfigEntry 464 This object also returns a value of zero when it is the 465 lexicographic successor of a varbind presented in an 466 SNMP GETNEXT or GETBULK request, for which circumstance 467 it is assumed that ifIndex allocation is unintended. 469 Successive GETs will typically return different 470 values, thus avoiding collisions among cooperating 471 management clients seeking to create table entries 472 simultaneously. 474 Unless specified otherwise by its MAX-ACCESS and 475 DESCRIPTION clauses, an object of this type is read-only, 476 and a SET of such an object returns a notWritable error." 477 ::= { vrConfigScalars 1 } 479 vrConfigTable OBJECT-TYPE 480 SYNTAX SEQUENCE OF VrConfigEntry 481 MAX-ACCESS not-accessible 482 STATUS current 483 DESCRIPTION 484 "This table is for creating the new Virtual Routers." 485 ::= { vrConfig 2 } 487 vrConfigEntry OBJECT-TYPE 488 SYNTAX VrConfigEntry 489 MAX-ACCESS not-accessible 490 STATUS current 491 DESCRIPTION 492 "The entries in this table can be added/deleted 493 using the vrRowStatus." 494 INDEX { vrId } 495 ::= { vrConfigTable 1 } 497 VrConfigEntry ::= 498 SEQUENCE { 499 vrId 500 VrId, 501 vrRowStatus 502 RowStatus, 503 vrName 504 DisplayString, 505 vrContextName 506 DisplayString, 507 vrTrapEnable 508 TruthValue, 509 vrMaxRoutes 510 Unsigned32, 511 vrAdminStatus 512 INTEGER, 513 vrVpnId 514 VpnIdentifier, 515 vrRpTrigger 516 Unsigned32 517 } 519 vrId OBJECT-TYPE 520 SYNTAX VrId 521 MAX-ACCESS not-accessible 522 STATUS current 523 DESCRIPTION 524 "The unique id of this virtual router instance. A Virtual 525 Router cannot not be created with vrId = 0. 526 VRID 0 is reserved for the Administrative VR. 527 " 528 ::= { vrConfigEntry 1 } 530 vrRowStatus OBJECT-TYPE 531 SYNTAX RowStatus 532 MAX-ACCESS read-create 533 STATUS current 534 DESCRIPTION 535 "The status column has three defined values: 537 - `active', which indicates that the conceptual row is 538 available for use by the managed device; 540 - `createAndGo', which is supplied by a management 541 station wishing to create a new instance of a 542 conceptual row and to have its status automatically set 543 to active, making it available for use by the managed 544 device; 546 - `destroy', which is supplied by a management station 547 wishing to delete all of the instances associated with 548 an existing conceptual row." 549 ::= { vrConfigEntry 2 } 551 vrName OBJECT-TYPE 552 SYNTAX DisplayString 553 MAX-ACCESS read-create 554 STATUS current 555 DESCRIPTION 556 "The Name of the Virtual Router.. 557 " 558 ::= { vrConfigEntry 3 } 560 vrContextName OBJECT-TYPE 561 SYNTAX DisplayString 562 MAX-ACCESS read-create 563 STATUS current 564 DESCRIPTION 565 "The SNMPv2 Community String or SNMPv3 contextName 566 denotes the VR 'context' and is used to logically 567 separate the MIB management. 568 RFC2571 and RFC2737 describe this approach." 569 ::= { vrConfigEntry 4 } 571 vrTrapEnable OBJECT-TYPE 572 SYNTAX TruthValue 573 MAX-ACCESS read-create 574 STATUS current 575 DESCRIPTION 576 "This objects is used to enable the generation 577 of the VrUp and VrDown traps. 578 true(1) - VR Traps Enabled 579 false(2) - VR Traps Disabled" 580 DEFVAL { true } 581 ::= { vrConfigEntry 5 } 583 vrMaxRoutes OBJECT-TYPE 584 SYNTAX Unsigned32 585 MAX-ACCESS read-create 586 STATUS current 587 DESCRIPTION 588 "This object specifies the maximum number of routes that 589 this VR can support. The default value is 4 Gig (meaning 590 unlimited)." 591 DEFVAL { 4294967295 } 592 ::= { vrConfigEntry 6 } 594 vrAdminStatus OBJECT-TYPE 595 SYNTAX INTEGER { 596 up(1), 597 down(2), 598 testing(3), 599 unknown(4) 600 } 601 MAX-ACCESS read-create 602 STATUS current 603 DESCRIPTION 604 "The administrative state of the Virtual Router." 605 DEFVAL { down } 606 ::= { vrConfigEntry 7 } 608 vrVpnId OBJECT-TYPE 609 SYNTAX VpnIdentifier 610 MAX-ACCESS read-create 611 STATUS current 612 DESCRIPTION 613 "The Virtual Private Network Identifier of the Virtual 614 Router." 615 ::= { vrConfigEntry 8 } 617 vrRpTrigger OBJECT-TYPE 618 SYNTAX Unsigned32 619 MAX-ACCESS read-create 620 STATUS current 621 DESCRIPTION 622 "The Routing Protocol Triggers on the Virtual Router. 623 This can be used to initiate or shutdown routing protocols 624 on a VR. 625 The 32 bits are divided into: 626 16 bits of RP bitmap, 627 15 bits reserved (0), and 1 bit of action-code. 629 0 1 2 3 4 5 6 7 630 +-+-+-+-+-+-+-+-+ 631 |RP bitmap (MSB)| 632 +-+-+-+-+-+-+-+-+ 633 |RP bitmap (LSB)| 634 +-+-+-+-+-+-+-+-+ 635 | Reserved | 636 +-+-+-+-+-+-+-+-+ 637 |*| Reserved | 638 +-+-+-+-+-+-+-+-+ *=action-code 640 The RP bitmap specify the RP that is to be initiated or 641 shutdown. Multiple RPs can be acted on simultaneously. 642 Also, individual RPs can be brought up in steps, which 643 should not affect the RPs that were running. 644 Action-code specify what needs to be done for the RPs 645 in the RP bitmap. The actions are: initiate or shutdown. 647 The running status of the RP shall be available in the 648 VR stats table's vrRpStatus, which has a similar 649 format, but represent the status." 650 ::= { vrConfigEntry 9 } 652 vrStat OBJECT IDENTIFIER ::= { vrMIBObjects 2 } 654 vrStatScalars OBJECT IDENTIFIER ::= { vrStat 1 } 656 vrConfiguredVRs OBJECT-TYPE 657 SYNTAX Unsigned32 658 MAX-ACCESS read-only 659 STATUS current 660 DESCRIPTION 661 "The number of VRs configured on this network element." 662 ::= { vrStatScalars 1 } 664 vrActiveVRs OBJECT-TYPE 665 SYNTAX Unsigned32 666 MAX-ACCESS read-only 667 STATUS current 668 DESCRIPTION 669 "The number of VRs that are active on the network element. 670 These are VRs for which the 671 vrStatOperationalStatus = up(1)" 672 ::= { vrStatScalars 2 } 674 vrStatTable OBJECT-TYPE 675 SYNTAX SEQUENCE OF VrStatEntry 676 MAX-ACCESS not-accessible 677 STATUS current 678 DESCRIPTION 679 "This table contains statistics for the Virtual Router." 680 ::= { vrStat 2 } 682 vrStatEntry OBJECT-TYPE 683 SYNTAX VrStatEntry 684 MAX-ACCESS not-accessible 685 STATUS current 686 DESCRIPTION 687 "Entries in this table a per vrId." 688 INDEX { vrId } 689 ::= { vrStatTable 1 } 691 VrStatEntry ::= 692 SEQUENCE { 693 vrStatRouteEntries 694 Unsigned32, 695 vrStatFIBEntries 696 Unsigned32, 697 vrStatUpTime 698 TimeTicks, 699 vrOperStatus 700 INTEGER, 701 vrRpStatus 702 Unsigned32, 703 vrRouterAddressType 704 InetAddressType, 705 vrRouterAddress 706 InetAddress 707 } 709 vrStatRouteEntries OBJECT-TYPE 710 SYNTAX Unsigned32 711 MAX-ACCESS read-only 712 STATUS current 713 DESCRIPTION 714 "Total number of routes for this VR." 715 ::= { vrStatEntry 1 } 717 vrStatFIBEntries OBJECT-TYPE 718 SYNTAX Unsigned32 719 MAX-ACCESS read-only 720 STATUS current 721 DESCRIPTION 722 "Total number of FIB Entries for this VR." 723 ::= { vrStatEntry 2 } 725 vrStatUpTime OBJECT-TYPE 726 SYNTAX TimeTicks 727 MAX-ACCESS read-only 728 STATUS current 729 DESCRIPTION 730 "The time in (in hundredths of a second) since 731 this VR entry has been operational." 732 ::= { vrStatEntry 3 } 734 vrOperStatus OBJECT-TYPE 735 SYNTAX INTEGER { 736 up(1), 737 down(2), 738 unknown(3) 739 } 740 MAX-ACCESS read-only 741 STATUS current 742 DESCRIPTION 743 "The operational state of the Virtual Router." 744 ::= { vrStatEntry 4 } 746 vrRpStatus OBJECT-TYPE 747 SYNTAX Unsigned32 748 MAX-ACCESS read-only 749 STATUS current 750 DESCRIPTION 751 "List of Routing Protocols on this VR." 752 ::= { vrStatEntry 5 } 754 vrRouterAddressType OBJECT-TYPE 755 SYNTAX InetAddressType 756 MAX-ACCESS read-only 757 STATUS current 758 DESCRIPTION 759 "Router Address Type of this VR." 760 ::= { vrStatEntry 6 } 762 vrRouterAddress OBJECT-TYPE 763 SYNTAX InetAddress 764 MAX-ACCESS read-only 765 STATUS current 766 DESCRIPTION 767 "Router Address of this VR. It is derived from one of the 768 interfaces. If loopback interface is present, the loopback 769 interface address can be used. However, loopback interface 770 is optional." 771 ::= { vrStatEntry 7 } 773 vrIfConfig OBJECT IDENTIFIER ::= { vrMIBObjects 3 } 775 vrIfConfigScalars OBJECT IDENTIFIER ::= { vrIfConfig 1 } 777 vrIfConfigTable OBJECT-TYPE 778 SYNTAX SEQUENCE OF VrIfConfigEntry 779 MAX-ACCESS not-accessible 780 STATUS current 781 DESCRIPTION 782 "This table is for configuring VR Interfaces." 783 ::= { vrIfConfig 2 } 785 vrIfConfigEntry OBJECT-TYPE 786 SYNTAX VrIfConfigEntry 787 MAX-ACCESS not-accessible 788 STATUS current 789 DESCRIPTION 790 "Entries in this table correspond to the entries in 791 the ifTable that apply to the Virtual Router." 792 INDEX { vrId, 793 vrIfId } 794 ::= { vrIfConfigTable 1 } 796 VrIfConfigEntry ::= 797 SEQUENCE { 798 vrIfId 799 InterfaceIndex, 800 vrIfConfigRowStatus 801 RowStatus 802 } 804 vrIfId OBJECT-TYPE 805 SYNTAX InterfaceIndex 806 MAX-ACCESS not-accessible 807 STATUS current 808 DESCRIPTION 809 "Virtual Router Interface Index." 810 ::= { vrIfConfigEntry 1 } 812 vrIfConfigRowStatus OBJECT-TYPE 813 SYNTAX RowStatus 814 MAX-ACCESS read-create 815 STATUS current 816 DESCRIPTION 817 " This object is used to create, delete or 818 modify a row in this table." 819 ::= { vrIfConfigEntry 2 } 821 -- ********************************************************************* 822 -- Module Traps/Notifications 823 -- ********************************************************************* 825 vrNotificationsPrefix OBJECT IDENTIFIER ::= { vrMIBObjects 4 } 827 vrNotifications OBJECT IDENTIFIER ::= { vrNotificationsPrefix 0 } 829 vrUp NOTIFICATION-TYPE 830 OBJECTS { vrRowStatus } 831 STATUS current 832 DESCRIPTION 833 "This notification is generated when the specified 834 VR is about to initialized or change the status from 835 down to up." 836 ::= { vrNotifications 1 } 838 vrDown NOTIFICATION-TYPE 839 OBJECTS { vrRowStatus } 840 STATUS current 841 DESCRIPTION 842 "This notification is generated when the specified 843 VR is about to go down." 844 ::= { vrNotifications 2 } 846 vrMaxRoutesExceeded NOTIFICATION-TYPE 847 OBJECTS { vrRowStatus, vrMaxRoutes, vrStatRouteEntries } 848 STATUS current 849 DESCRIPTION 850 "This notification is generated when the specified VR has 851 exceeded the maximum number of routes specified" 852 ::= { vrNotifications 3 } 854 -- ********************************************************************* 855 -- Module Compliance/Conformance Statements 856 -- ********************************************************************* 858 vrConformance OBJECT IDENTIFIER ::= { virtualRouterMIB 2 } 860 vrCompliances OBJECT IDENTIFIER ::= { vrConformance 1 } 862 vrMIBCompliance MODULE-COMPLIANCE 863 STATUS current 864 DESCRIPTION 865 "The compliance statement for entities that implement the 866 VIRTUAL-ROUTER-MIB. Implementation of this MIB 867 is strongly recommended for any platform targeted for a 868 carrier-class environment." 869 MODULE -- this module 870 MANDATORY-GROUPS { vrConfigGroup, vrStatGroup, 871 vrIfGroup, vrNotificationGroup } 872 ::= { vrCompliances 1 } 874 vrGroups OBJECT IDENTIFIER ::= { vrConformance 2 } 876 vrConfigGroup OBJECT-GROUP 877 OBJECTS { vrRowStatus, vrName, 878 vrContextName, vrTrapEnable, 879 vrMaxRoutes, vrAdminStatus, 880 vrVpnId, vrRpTrigger, 881 vrConfigNextAvailableVrId } 882 STATUS current 883 DESCRIPTION 884 "A collection of attributes that support provisioning 885 of a virtual router." 886 ::= { vrGroups 1 } 888 vrStatGroup OBJECT-GROUP 889 OBJECTS { vrConfiguredVRs, vrActiveVRs, 890 vrStatRouteEntries, vrStatFIBEntries, vrStatUpTime, 891 vrOperStatus, vrRpStatus, vrRouterAddress, 892 vrRouterAddressType } 893 STATUS current 894 DESCRIPTION 895 "A collection of attributes that contain stats about the 896 virtual router." 897 ::= { vrGroups 2 } 899 vrIfGroup OBJECT-GROUP 900 OBJECTS { vrIfConfigRowStatus } 901 STATUS current 902 DESCRIPTION 903 "A collection of attributes that support provisioning of a 904 virtual router interfaces." 905 ::= { vrGroups 3 } 907 vrNotificationGroup NOTIFICATION-GROUP 908 NOTIFICATIONS { vrUp, vrDown, vrMaxRoutesExceeded } 909 STATUS current 910 DESCRIPTION 911 "A collection of traps that are supported by the VR." 912 ::= { vrGroups 4 } 914 END 916 10.0 Summary for Sub-IP Area 918 This document defines a MIB that provides a way to provision VPNs at 919 the PE devices employing the Virtual Router model. 921 10.1 Where does it fit in the Picture of the Sub-IP Work 923 This work fits in the PPVPN Working Group. 925 10.2 Why is it Targeted at this WG 927 The WG is chartered with developing Provider Provisioned VPN 928 solutions. This draft contributes to this. 930 10.3 Justification 932 The WG should consider this document since it provides a means to 933 configure and manage Virtual Router based PPVPNs. 935 11.0 Security Considerations 937 The Administrative VR provides visibility into and control over multiple 938 VPNs. As such, security considerations for implementations of the 939 Administrative VR and associated control plane(s) are critical to the 940 security of the VPNs supported on each PE device. 942 Use of any vrContextName MUST be allowed in the Administrative VR. 943 Additional authentication and security mechanisms SHOULD be used for SNMP 944 access in the Administrative VR. 946 VRs other than the Administrative VR MUST NOT have access to other VR��s 947 Instantiated MIBs, and MAY have access to their own instantiated MIBs. 949 In VRs other than the Administrative VR, access to that VR��s instantiated 950 MIBs MAY be permitted via that VR��s vrContextName. Use of any vrContextName 951 other than that assigned to the accessed VR MUST result in an error, and 952 implementations SHOULD provide a logging mechanism for such events. 954 12.0 Acknowledgments 956 Special thanks to Joan Cucchiara for providing valuable comments on this MIB. 958 13.0 References 960 [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 961 Describing SNMP Management Frameworks", RFC 2571, April 1999. 963 [2] Rose, M. and K. McCloghrie, "Structure and Identification of 964 Management Information for TCP/IP-based Internets", STD 16, RFC 965 1155, May 1990. 967 [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, 968 RFC 1212, March 1991. 970 [4] Rose, M., "A Convention for Defining Traps for use with the 971 SNMP", RFC 1215, March 1991. 973 [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 974 M. and S. Waldbusser, "Structure of Management Information 975 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 977 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 978 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 979 RFC 2579, April 1999. 981 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 982 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 983 58, RFC 2580, April 1999. 985 [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple 986 Network Management Protocol", STD 15, RFC 1157, May 1990. 988 [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 989 "Introduction to Community-based SNMPv2", RFC 1901, January 990 1996. 992 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport 993 Mappings for Version 2 of the Simple Network Management Protocol 994 (SNMPv2)", RFC 1906, January 1996 996 [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 997 Control Model (VACM) for the Simple Network Management Protocol 998 (SNMP)", RFC 2575, January 1998. 1000 [16] Bradner, S., "Key words for use in RFCs to Indicate Requirements 1001 Levels", BCP 14, RFC 2119, March 1997. 1003 [17] Ouldbrahim's VR draft, "Network Based IP VPN Architecture Using 1004 Virtual Routers", draft-ouldbrahim-vpn-vr-01.txt 1006 [18] RFC 2685, "Virtual Private Networks Identifier" 1008 [19] RFC 2764, "A Framework for IP Based Vitual Private Networks" 1010 [20] RFC 2547bis, "BGP/MPLS VPNs", draft-rosen-rfc2547bis-03.txt 1012 [21] "BGP/IPsec VPN", draft-declercq-bgp-ipsec-vpn-00.txt 1014 [22] RFC 2667, "IP Tunnel MIB" 1016 [PPVPN-FW] R. Callon, et al., "A Framework for Layer 3 Provider 1017 Provisioned Virtual Private Networks", 1018 draft-ietf-ppvpn-framework-06.txt, October 2002. 1020 [PPVPN-VR] P. Knight, et al., "Network based IP VPN Architecture 1021 using Virtual Routers", draft-ietf-ppvpn-vpn-vr-03.txt, July 2002. 1023 [PPVPN-VR-AS] A. Nagarajan, et al., "Applicability Statement for 1024 Virtual Router-based Layer 3 PPVPN approaches", 1025 draft-ietf-ppvpn-as-vr-00.txt, August 2002. 1027 14.0 Authors' Addresses 1029 Elwin Stelzer Eliazer 1030 Corona Networks, Inc. 1031 630 Alder Drive 1032 Milpitas, CA 95035 1033 USA 1034 Phone: +1-408-519-3832 1035 Email: elwinietf@yahoo.com 1037 Samuel Hancock 1038 Corona Networks, Inc. 1039 630 Alder Drive 1040 Milpitas, CA 95035 1041 USA 1042 Phone: +1-408-519-3800 Ext 421 1043 Email: hancoc_s@yahoo.com 1045 Benson Schliesser 1046 SAVVIS Communications 1047 1 Savvis Parkway 1048 Town and Country, MO 63017 1049 USA 1050 Phone: +1-314-628-7036 1051 Email: bensons@savvis.net 1053 Joseph Laria 1054 Level Stream Research 1055 Wilmington, MA 01887 1056 USA 1057 Phone: +1-978-884-3537 1058 Emain: jlaria@levelstream.com