Subject: draft-ietf-l3vpn-vr-mib-05

From: Joseph Laria <[email-masked]>
Date: Mon, 14 Mar 2005 00:53:11 -0800 (PST)

Hi,

Attached is the latest version of
draft-ietf-l3vpn-vr-mib. The Virtual Router MIB is a
work item of the Provider Provisioned Virtual Private
Networks (L3) Working Group.

Title: Virtual Router Management Information Base
Using SMIv2
Author(s): Elwin Stelzer, Sam Hancock, Benson
Schliesser, Joseph Laria
Filename: draft-ietf-l3vpn-vr-mib-05.txt
Pages: XX
Date: March 2005
Abstract:
This memo defines a portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP based internets.
In particular, it defines objects for managing
networks using Virtual Routers (VR).

The changes which have been made include:
1. Update "status of memo" section to refer to RFC
3667 2. Include statement of document validity
2. Correct end-of-line formatting errors 

Thanks
Joe Laria

INTERNET-DRAFT                                        Elwin Stelzer
draft-ietf-l3vpn-vr-mib-05.txt                 Corona Networks, Inc.
Expires: June 2005
                                                         Sam Hancock
                                                         ACM Systems

                                                   Benson Schliesser
                                               SAVVIS Communications

                                                        Joseph Laria
                                               Level Stream Research

                                                          March 2005

        Virtual Router Management Information Base Using SMIv2

Status of this Memo

   This document is an Internet-Draft. By submitting this document,
   each author certifies that any applicable patent or other IPR 
   claims of which he or she is aware has been disclosed, or will 
   be disclosed, and any of which we become aware will be disclosed, 
   in accordance with RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as 
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other 
   documents at any time. It is inappropriate to use Internet-Drafts 
   as reference material or to cite them other than as 
   "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is a product of the IETF's Layer 3 Virtual Private  
   Network (l3vpn) working group. Comments should be addressed to WG's  
   mailing list at [email-masked]. The charter for l3vpn may be found  
   at http://www.ietf.org/html.charters/l3vpn-charter.html 

Abstract

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP based internets.
In particular, it defines objects for managing networks using Virtual
Routers (VR).

Layer-3 VPN Group             Expires June 2005             [Page 1]

Draft                    Virtual Router MIB              March 2005

Table of Contents

     1.0 Terminology
     2.0 Introduction
     3.0 The Internet-Standard Management Framework
     4.0 Overview of the Virtual Router MIB
     4.1 SNMP Contexts for Management for Virtual Routers
     4.2 VR Indexing
     4.3 Creation and Deletion of VRs
     4.4 Administrative and Operational Status of VRs
     4.5 Binding interfaces to a VR
     4.6 Setting per VR limits
     4.7 Per VR Statistics
     4.8 Traps
     4.9 Usability Considerations
     4.9.1 Multiple Agents
     4.9.2 Provisioning vs. Monitoring
     5.0 Sample VR MIB Configuration Scenario
     5.1 Creation of a VR
     6.0 Definition of the Virtual Router MIB
     7.0 Acknowledgments
     8.0 Security Considerations
     9.0 References
     9.1 Normative References
     9.2 Informative References
     10.0 Authors' Addresses
     11.0 Intellectual Property Considerations
     12.0 Full Copyright Statement
     13.0 IANA Considerations for L3VPN-VR-MIB

1.0 Terminology

This document uses terminology defined in [PPVPN-FW] and [PPVPN-VR].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119, reference [RFC2119].

2.0 Introduction

This memo defines a MIB for the Virtual Router [PPVPN-VR, PPVPN-VR-AS]
model of Provider Provisioned VPNs [PPVPN-FW].

Following are the goals, in defining this MIB:

  - To have a means for Service Providers to provision VPN service for
    subscribers, at the PE device.

  - To make the agent-side implementation simple, by not modifying the
    existing standard MIBs.

  - Define all the gluing tables that are needed toward this end.

Layer-3 VPN Group             Expires June 2005             [Page 2]

Draft                    Virtual Router MIB              March 2005

3.0  The Internet-Standard Management Framework

For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].

Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB.  MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI).  This memo specifies a
MIB module that is compliant to the SMIv2, which is described in STD
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC
2580 [RFC2580].

4.0 Overview of the Virtual Router MIB

4.1 SNMP Contexts for Management for Virtual Routers

There is a need for a single agent to manage multiple Virtual Routers.
The Architecture for describing SNMP Management Frameworks [RFC3411]
provides a way to support such cases.

Managing multiple virtual routers requires that the PE management 
plane be subdivided into logical VR management domains.  In the VR 
model of PPVPNs a single PE device may contain many virtual routers.  
Different management entities SHOULD be able to manage specific 
virtual routers and associated services. The Service Provider MUST be
able to manage all virtual routers and associated services.

Using SNMP contexts to group a collection of management information
provides the following benefits:

 (1)  Uses a standard framework defined by the IETF, allowing the
      product to remain flexible to all implementations of virtual
      router devices.

      (a) Use SNMPv2c Community String's

      (b) Use SNMPv3 contextName's

 (2)  Prevents vendors from having to modify the standard MIBs, 
      allowing the implementation to remain standards compliant.

 (3)  Provides a framework that will work for RIP, OSPF, IS-IS, BGP,
      IP-FORWARDING, MPLS, and any other MIB that can be 
      administratively grouped with a VR.

Layer-3 VPN Group             Expires June 2005             [Page 3]

Draft                    Virtual Router MIB              March 2005

The SNMP context for the Virtual Router instance can be specified in
the VrConfigTable.  The VrContextName columnar object is used to set 
the SNMPv2c Community String or the SNMPv3 contextName for a given VR.

A virtual router context represents the set of MIB objects that could 
be administratively grouped within a VR.  For example, each VR would 
maintain its own instance of routing protocol MIB tables. However, the 
ADMIN context would contain single instances of objects and tables 
that pertain to system wide configuration such as the Entity, 
Interfaces, and ATM MIBs.

A management system using the SNMP context of a particular virtual
router MUST be able to manage the virtual router without disrupting 
other virtual routers in the same PE device.

For example, a PE can be subdivided into two 2 VRs running the OSPF 
routing protocol.  Each VR will maintain a unique instance of the 
OSPF-MIB. Therefore, the ospfAreaTable of VR-A is distinct from the
ospfAreaTable of VR-B.

   +-----------------------------------------------------------------+
   |  +------------------------------------------------------------+ |
   |  |  SNMP entity (including Engine, Applications)              | |
   |  |                                                            | |
   |  |  example contextNames:                                     | |
   |  |                                                            | |
   |  |  "vr01"             "vr09"                 "admin"         | |
   |  |  ---------          ---------            ------------      | |
   |  |      |                  |                   |              | |
   |  +------|------------------|-------------------|--------------+ |
   |         |                  |                   |                |
   |  +------|------------------|-------------------|--------------+ |
   |  |  MIB | instrumentation  |                   |              | |
   |  |  +---v------------+ +---v------------+ +----v-----------+  | |
   |  |  | context=vr01   | | context=vr09   | | context=admin  |  | |
   |  |  |                | |                | |                |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  | |  OSPF MIB  | | | |  OSPF MIB  | | | |  VR  MIB   | |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  | |  BGP MIB   | | | |  BGP MIB   | | | |   ATM MIB  | |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  | |  IP MIB    | | | |  IP MIB    | | | | ENTITY MIB | |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  | | other MIB  | | | | other MIB  | | | |  IF  MIB   | |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  |       ...      | |      ...       | |      ...       |  | |
   +-----------------------------------------------------------------+

Layer-3 VPN Group             Expires June 2005             [Page 4]

Draft                    Virtual Router MIB              March 2005

Filtering mechanisms based on the SNMP context of a particular virtual 
router may implemented to allow different management entities to manage 
those objects and services provisioned the 'Admin' context.

4.2 VR Indexing

While the standard protocol MIB tables are instantiated in the
context specified using SNMP contexts, there may be tables that are
defined with the VRID as index.

The VRID is of local significance to a particular PE device, and need
not be globally unique. Thus a particular VRID value assigned to a VR
in one PE device may indicate a different VR in another PE device.

The VRID has an Unsigned32 value, and this value is assigned by the 
management station. To aid the management station in assigning a VRID 
without conflict, the management station can get the 
'NextAvailableVRID' from the PE device.

A SNMP manager SHOULD NOT assume global significance of any VRID value
other than 0.

For those MIB tables instantiated in the virtual router context, 
indexing can only be assumed unique for that particular VR.  However 
those indices in the "ADMIN" context are unique across the entire 
system, including all VRs.

4.3 Creation and Deletion of VRs

The VR Config Table is used for this purpose. This is a read-create
table and adding an entry into this table will create a VR. Removing
an entry from this table marks the deletion of a VR.

VRID 0 is assigned to the Administrative VR, which exists by default,
and need not be created. Deletion of the Administrative VR will not be
permitted.  The VRID of the Administrative VR (VRID 0) should be a
reserved VRID number.  VRID 0 could be termed the "null VR" and it 
could be the context that manages the resource pool of unattached 
interfaces. Routing would then not exist in the context of 
Administrative VR.

4.4 Administrative and Operational Status of VRs

VRs can be administratively turned down. When this is done, no
packet forwarding via the VR takes place.

VrOperStatus denotes the operational status of a VR. Currently the
VrOperStatus is expected to change along the VrAdminStatus unless an
error condition exists.

Layer-3 VPN Group             Expires June 2005             [Page 5]

Draft                    Virtual Router MIB              March 2005

4.5 Binding interfaces to a VR

Interfaces are bound to a VR, using vrIfConfigTable. This is
a read-write table, and note that interfaces are not created through
this table. The vrIfConfigTable MIB table is used to indicated the
relationship between interfaces and virtual router IDs. For each
interface present in the system, this table is used to provide the
mapping from IfIndex to a unique VR.  The table show which interfaces
are ?attached or connected? to a virtual router. An interface can not
be attached to more than one VR.

The "Admin" VR could be used to manage the resource pool of
unattached interfaces.  However interfaces would not be attached to
VRID 0.

4.6 Setting per VR limits

VRs consume resources on a device, and hence the following parameters
defined in vrConfigTable are used to specify an upper bound of resource
utilization:

VrMaxRoutes -
Specify the maximum number of routes that will be permitted in VR. This
includes all routes, such as the statically configured routes, and the 
routes learnt via dynamic routing protocols.

4.7 Per VR Statistics

In addition to those statistics available through the VR instantiated 
MIB tables, there are some per-VR statistics available through 
vrStatTable.

4.8 Traps

This memo defines that VrUp and VrDown traps are generated just after
VrOperStatus leaves, or just before it enters, the down state,
respectively.

   (1)   A transition into the down state will occur when an error is
         detected on a VR instance.

   (2)   Departing the down state generally indicates that the
         VR is going to up, which is considered a "healthy" state.

An exception to the above generation of VrUp/VrDown traps on changes
in VrOperStatus, occurs when an VR is "flapping", i.e., when it is
rapidly oscillating between the up and down states.  If traps were
generated for each such oscillation, the network and the network
management system would be flooded with unnecessary traps.  In such a
situation, the agent should limit the rate at which it generates traps.

This memo defines that enabling and disabling the VR traps is achieved
by setting the VrTrapEnable to true(1) or false(2), respectively.  By
default, this object should have the value true(1).

Layer-3 VPN Group             Expires June 2005             [Page 6]

Draft                    Virtual Router MIB              March 2005

4.9 Usability Considerations
4.9.1  Multiple Agents

The MIB is based upon the premise that a single SNMP agent should 
represent every virtual router on a physical router. An alternative 
approach would be to deploy a separate  SNMP agent for each virtual 
router.  Creating multiple agents for use by the administrator 
(Service Provider) could be done, for instance by binding to different 
ports or addresses on the P-node.  However from a resource perspective, 
it is more efficient to use a single agent and multiplex based on the 
community/context as described in this document. In either case, 
though, a VR-MIB is needed to map each VR to its respective agent or 
context.

There could be a case where a separate agent per VR may be useful, 
though not as a replacement for the VR-MIB. If the platform supports 
instantiation of an agent *within* the VR then the VPN user could 
query stats, etc., from that agent. This would not be a replacement 
for the VR-MIB because (in addition to the above points) the SP may 
very well not have reachability/connectivity (not to mention 
uniqueness in addressing) into the VPN.  For example, the Service 
Provider may not have management-network access to the customers' 
networks.

4.9.2  Provisioning vs. Monitoring
The vr-mib goes to some length the support configuration using SNMP.
Other MIBs tend to be for monitoring purposes, with an occasional 
read-write variable. There is value in having configuration 
capabilities in this MIB. The VR-MIB fills in a gap, allowing for 
creation of the VR, while the VR context MIBs allow for configuration 
of the VR itself. This might prove useful, perhaps even allowing for 
interoperable management tools.

Some Service Provider may intend to use it only for monitoring.  This 
is because there may be other mechanisms available to them for 
configuration of a specific platforms, such as Corba or XML interfaces 
that they may find more valuable for this function.

5.0 Sample VR MIB Configuration Scenario

5.1 Creation of a VR

Creating VR instances can be achieved using the following example.

(1) Get the next available Virtual Router Id using the
    NextAvailableVrId, to create a VR:

    Using a context with 'read' access for system level entities.
    GetRequest { NextAvailableVrId.0 }
    Response   { NextAvailableVrId.0  =  5555 }

 (2) In VrConfigTable, create VR Instance using VrRowStatus:

    Using a context with 'read-write' access for system level entities
    SetRequest {
        VrRowStatus.5555                   createAndGo(4),
        VrName.5555                        "BigTelcoVR",
        VrContextName.5555                 "vr5555",
        VrTrapEnable.5555                  true(1),
        VrAdminStatus.5555                 up(1)
    }

6.0 Definition of the Virtual Router MIB

--
-- VIRTUAL-ROUTER-MIB
--

VIRTUAL-ROUTER-MIB DEFINITIONS ::= BEGIN

    IMPORTS
        InterfaceIndex
            FROM IF-MIB
        InetAddressType, InetAddress
            FROM INET-ADDRESS-MIB
-- RFC Ed.: VPN-TC-MIB in Last Call in L3VPN WG
         VPNId
 	    FROM VPN-TC-MIB
        OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP
            FROM SNMPv2-CONF
        experimental, Unsigned32, OBJECT-TYPE,
        MODULE-IDENTITY, TimeTicks, NOTIFICATION-TYPE
            FROM SNMPv2-SMI
        TruthValue, DisplayString, RowStatus, TEXTUAL-CONVENTION
            FROM SNMPv2-TC;

    virtualRouterMIB MODULE-IDENTITY
        LAST-UPDATED "200503161200Z"
        ORGANIZATION
            "IETF L3VPN WG"
        CONTACT-INFO

Layer-3 VPN Group             Expires June 2005             [Page 7]

Draft                    Virtual Router MIB              March 2005

            "
            Elwin Stelzer Eliazer
            Corona Networks, Inc.
            630 Alder Drive
            Milpitas, CA 95035
            USA
            Phone: +1-408-519-3832
            Email: [email-masked]

            Samuel Hancock
            ACM Systems
            3034 Gold Canal Drive
            Rancho Cordova, CA 95670
            USA
            Phone: +1-916-463-7949
            Email: [email-masked]

            Benson Schliesser
            SAVVIS Communications
            1 Savvis Parkway
            Town and Country, MO 63017
            USA
            Phone: +1-314-628-7036
            Email: [email-masked]

            Joseph Laria
            Level Stream Research
            Wilmington, MA  01887
            USA
            Phone: +1-978-884-3537
            Emain: [email-masked]
            "
        DESCRIPTION
            "The MIB is the definition of the managed
            objects for the Virtual Router."
        REVISION "200503101200Z"  -- 10 March 2005 12:00:00 GMT
        DESCRIPTION "Initial version, published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note
        ::= { experimental xxxx } -- To be assigned
-- RFC Ed.: replace xxxx with IANA-assigned number & remove this note

--
-- Textual conventions
--

    VrIdentifier ::= TEXTUAL-CONVENTION
        STATUS current
        DESCRIPTION
            "Virtual Router Identifier.

Layer-3 VPN Group             Expires June 2005             [Page 8]

Draft                    Virtual Router MIB              March 2005

             VRID 0 is reserved for the Administrative VR
             and cannot be used to create VR's.
            "
        SYNTAX Unsigned32

--
-- Node definitions
--

    vrMIBObjects OBJECT IDENTIFIER ::= { virtualRouterMIB 1 }

    vrConfig OBJECT IDENTIFIER ::= { vrMIBObjects 1 }

    vrConfigScalars OBJECT IDENTIFIER ::= { vrConfig 1 }

    vrConfigNextAvailableVrId OBJECT-TYPE
        SYNTAX VrIdentifier
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The next available Virtual Router Id (index).
            This object provides a hint for the vrID value
            to use when administratively creating a new
            vrConfigEntry.

            A GET of this object returns the next available vrId
            value to be used to create an entry in the associated
            vrConfigTable; or zero, if no valid vrId
            value is available. A value of zero(0) indicates that
            it is not possible to create a new vrConfigEntry
            This object also returns a value of zero when it is the
            lexicographic successor of a varbind presented in an
            SNMP GETNEXT or GETBULK request, for which circumstance
            it is assumed that ifIndex allocation is unintended.

            Successive GETs will typically return different
            values, thus avoiding collisions among cooperating
            management clients seeking to create table entries
            simultaneously.

            Unless specified otherwise by its MAX-ACCESS and
            DESCRIPTION clauses, an object of this type is read-only,
            and a SET of such an object returns a notWritable error."
        ::= { vrConfigScalars 1 }

    vrConfigTable OBJECT-TYPE
        SYNTAX SEQUENCE OF VrConfigEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "This table is for creating the new Virtual Routers."
        ::= { vrConfig 2 }

Layer-3 VPN Group             Expires June 2005             [Page 9]

Draft                    Virtual Router MIB              March 2005

    vrConfigEntry OBJECT-TYPE
        SYNTAX VrConfigEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "The entries in this table can be added/deleted
            using the vrRowStatus."
        INDEX { vrId }
        ::= { vrConfigTable 1 }

    VrConfigEntry ::=
        SEQUENCE {
            vrId
                VrIdentifier,
            vrRowStatus
                RowStatus,
            vrName
                DisplayString,
            vrContextName
                DisplayString,
            vrTrapEnable
                TruthValue,
            vrMaxRoutes
                Unsigned32,
            vrAdminStatus
                INTEGER,
            vrVpnId
                VPNId,
            vrRpTrigger
                Unsigned32
         }

    vrId OBJECT-TYPE
        SYNTAX VrIdentifier
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "The unique id of this virtual router instance. A Virtual
             Router cannot not be created with vrId = 0.
             VRID 0 is reserved for the Administrative VR.
            "
    ::= { vrConfigEntry 1 }

    vrRowStatus OBJECT-TYPE
        SYNTAX RowStatus
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "The status column has three defined values:

            - `active', which indicates that the conceptual row is
            available for use by the managed device;

Layer-3 VPN Group             Expires June 2005             [Page 10]

Draft                    Virtual Router MIB              March 2005

            - `createAndGo', which is supplied by a management
            station wishing to create a new instance of a
            conceptual row and to have its status automatically set
            to active, making it available for use by the managed
            device;

            - `destroy', which is supplied by a management station
            wishing to delete all of the instances associated with
            an existing conceptual row."
    ::= { vrConfigEntry 2 }

    vrName OBJECT-TYPE
        SYNTAX DisplayString
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "The Name of the Virtual Router..
             "
        ::= { vrConfigEntry 3 }

    vrContextName OBJECT-TYPE
        SYNTAX DisplayString
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "The SNMPv2 Community String or SNMPv3 contextName
            denotes the VR 'context' and is used to logically
            separate the MIB management."
        ::= { vrConfigEntry 4 }

    vrTrapEnable OBJECT-TYPE
        SYNTAX TruthValue
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "This objects is used to enable the generation
            of the VrUp and VrDown traps.
                true(1)     - VR Traps Enabled
                false(2)    - VR Traps Disabled"
        DEFVAL { true }
        ::= { vrConfigEntry 5 }

    vrMaxRoutes OBJECT-TYPE
        SYNTAX Unsigned32
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "This object specifies the maximum number of routes that
            this VR can support. The default value is 4 Gig (meaning
            unlimited)."
        DEFVAL { 4294967295 }
        ::= { vrConfigEntry 6 }

Layer-3 VPN Group             Expires June 2005             [Page 11]

Draft                    Virtual Router MIB              March 2005

    vrAdminStatus OBJECT-TYPE
        SYNTAX  INTEGER {
                 up(1),
                 down(2),
                 testing(3),
                 unknown(4)
                }
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "The administrative state of the Virtual Router."
        DEFVAL { down }
        ::= { vrConfigEntry 7 }

    vrVpnId OBJECT-TYPE
        SYNTAX  VPNId
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "The Virtual Private Network Identifier of the Virtual
             Router."
        ::= { vrConfigEntry 8 }

    vrRpTrigger OBJECT-TYPE
        SYNTAX  Unsigned32
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            "The Routing Protocol Triggers on the Virtual Router.
            This can be used to initiate or shutdown routing protocols
            on a VR.
            The 32 bits are divided into:
                16 bits of RP bitmap,
                15 bits reserved (0), and 1 bit of action-code.

                         0 1 2 3 4 5 6 7
                        +-+-+-+-+-+-+-+-+
                        |RP bitmap (MSB)|
                        +-+-+-+-+-+-+-+-+
                        |RP bitmap (LSB)|
                        +-+-+-+-+-+-+-+-+
                        |   Reserved    |
                        +-+-+-+-+-+-+-+-+
                        |*|  Reserved   |
                        +-+-+-+-+-+-+-+-+    *=action-code

            The RP bitmap specify the RP that is to be initiated or

Layer-3 VPN Group             Expires June 2005             [Page 12]

Draft                    Virtual Router MIB              March 2005

            shutdown. Multiple RPs can be acted on simultaneously.
            Also, individual RPs can be brought up in steps, which
            should not affect the RPs that were running.
            Action-code specify what needs to be done for the RPs
            in the RP bitmap.  The actions are: initiate or shutdown.

            The running status of the RP shall be available in the
            VR stats table's vrRpStatus, which has a similar
            format, but represent the status."
        ::= { vrConfigEntry 9 }

    vrStat OBJECT IDENTIFIER ::= { vrMIBObjects 2 }

    vrStatScalars OBJECT IDENTIFIER ::= { vrStat 1 }

    vrConfiguredVRs OBJECT-TYPE
        SYNTAX Unsigned32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of VRs configured on this network element."
        ::= { vrStatScalars 1 }

    vrActiveVRs OBJECT-TYPE
        SYNTAX Unsigned32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The number of VRs that are active on the network element.
            These are VRs for which the
            vrStatOperationalStatus  = up(1)"
        ::= { vrStatScalars 2 }

    vrStatTable OBJECT-TYPE
        SYNTAX SEQUENCE OF VrStatEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "This table contains statistics for the Virtual Router."
        ::= { vrStat 2 }

    vrStatEntry OBJECT-TYPE
        SYNTAX VrStatEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "Entries in this table a per vrId."
        INDEX { vrId }
        ::= { vrStatTable 1 }

    VrStatEntry ::=
        SEQUENCE {

Layer-3 VPN Group             Expires June 2005             [Page 13]

Draft                    Virtual Router MIB              March 2005

            vrStatRouteEntries
                Unsigned32,
            vrStatFIBEntries
                Unsigned32,
            vrStatUpTime
                TimeTicks,
            vrOperStatus
                INTEGER,
            vrRpStatus
                Unsigned32,
            vrRouterAddressType
                InetAddressType,
            vrRouterAddress
                InetAddress
         }

    vrStatRouteEntries OBJECT-TYPE
        SYNTAX Unsigned32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "Total number of routes for this VR."
        ::= { vrStatEntry 1 }

    vrStatFIBEntries OBJECT-TYPE
        SYNTAX Unsigned32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "Total number of FIB Entries for this VR."
        ::= { vrStatEntry 2 }

    vrStatUpTime OBJECT-TYPE
        SYNTAX TimeTicks
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The time in (in hundredths of a second) since
            this VR entry has been operational."
        ::= { vrStatEntry 3 }

    vrOperStatus OBJECT-TYPE
        SYNTAX  INTEGER {
                 up(1),
                 down(2),
                 unknown(3)
                }
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The operational state of the Virtual Router."
        ::= { vrStatEntry 4 }

Layer-3 VPN Group             Expires June 2005             [Page 14]

Draft                    Virtual Router MIB              March 2005

    vrRpStatus OBJECT-TYPE
        SYNTAX  Unsigned32
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "List of Routing Protocols on this VR."
        ::= { vrStatEntry 5 }

    vrRouterAddressType OBJECT-TYPE
        SYNTAX  InetAddressType
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "Router Address Type of this VR."
        ::= { vrStatEntry 6 }

    vrRouterAddress OBJECT-TYPE
        SYNTAX  InetAddress
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "Router Address of this VR.  It is derived from one of the
            interfaces. If loopback interface is present, the loopback
            interface address can be used. However, loopback interface
            is optional."
        ::= { vrStatEntry 7 }

    vrIfConfig OBJECT IDENTIFIER ::= { vrMIBObjects 3 }

    vrIfConfigScalars OBJECT IDENTIFIER ::= { vrIfConfig 1 }

    vrIfConfigTable OBJECT-TYPE
        SYNTAX SEQUENCE OF VrIfConfigEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "This table is for configuring VR Interfaces."
        ::= { vrIfConfig 2 }

    vrIfConfigEntry OBJECT-TYPE
        SYNTAX VrIfConfigEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "Entries in this table correspond to the entries in
            the ifTable that apply to the Virtual Router."
        INDEX { vrId,
                vrIfId }
        ::= { vrIfConfigTable 1 }

Layer-3 VPN Group             Expires June 2005             [Page 15]

Draft                    Virtual Router MIB              March 2005

    VrIfConfigEntry ::=
        SEQUENCE {
            vrIfId
               InterfaceIndex,
            vrIfConfigRowStatus
               RowStatus
         }

    vrIfId OBJECT-TYPE
        SYNTAX InterfaceIndex
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "Virtual Router Interface Index."
        ::= { vrIfConfigEntry 1 }

     vrIfConfigRowStatus  OBJECT-TYPE
        SYNTAX RowStatus
        MAX-ACCESS read-create
        STATUS current
        DESCRIPTION
            " This object is used to create, delete or
            modify a row in this table."
        ::= { vrIfConfigEntry 2 }

-- *******************************************************************
-- Module Traps/Notifications
-- *******************************************************************

    vrNotificationsPrefix OBJECT IDENTIFIER ::= { vrMIBObjects 4 }

    vrNotifications OBJECT IDENTIFIER ::= { vrNotificationsPrefix 0 }

    vrUp NOTIFICATION-TYPE
        OBJECTS { vrRowStatus }
        STATUS current
        DESCRIPTION
            "This notification is generated when the specified
            VR is about to initialized or change the status from
            down to up."
        ::= { vrNotifications 1 }

    vrDown NOTIFICATION-TYPE
        OBJECTS { vrRowStatus }
        STATUS current
        DESCRIPTION
            "This notification is generated when the specified
            VR is about to go down."
        ::= { vrNotifications 2 }

Layer-3 VPN Group             Expires June 2005             [Page 16]

Draft                    Virtual Router MIB              March 2005

    vrMaxRoutesExceeded NOTIFICATION-TYPE
        OBJECTS { vrRowStatus, vrMaxRoutes, vrStatRouteEntries }
        STATUS current
        DESCRIPTION
            "This notification is generated when the specified VR has
            exceeded the maximum number of routes specified"
        ::= { vrNotifications 3 }

-- *******************************************************************
-- Module Compliance/Conformance Statements
-- *******************************************************************

    vrConformance OBJECT IDENTIFIER ::= { virtualRouterMIB 2 }

    vrCompliances OBJECT IDENTIFIER ::= { vrConformance 1 }

    vrMIBCompliance MODULE-COMPLIANCE
        STATUS current
        DESCRIPTION
            "The compliance statement for entities that implement the
            VIRTUAL-ROUTER-MIB.  Implementation of this MIB
            is strongly recommended for any platform targeted for a
            carrier-class environment.
            When this MIB is implemented with support for read-create, 
            then such an implementation can claim full compliance. 
            Such devices can then be both monitored and configured 
            with this MIB."
        MODULE -- this module
            MANDATORY-GROUPS { vrConfigGroup, vrStatGroup,
                               vrIfGroup, vrNotificationGroup }
        ::= { vrCompliances 1 }

    vrGroups OBJECT IDENTIFIER ::= { vrConformance 2 }

    vrConfigGroup OBJECT-GROUP
        OBJECTS { vrRowStatus, vrName,
                  vrContextName, vrTrapEnable,
                  vrMaxRoutes, vrAdminStatus,
                  vrVpnId, vrRpTrigger,
                  vrConfigNextAvailableVrId }
            STATUS current
            DESCRIPTION
                "A collection of attributes that support provisioning
                of a virtual router."
            ::= { vrGroups 1 }

    vrStatGroup OBJECT-GROUP
        OBJECTS { vrConfiguredVRs, vrActiveVRs,
                  vrStatRouteEntries, vrStatFIBEntries, vrStatUpTime,
                  vrOperStatus, vrRpStatus, vrRouterAddress,
                  vrRouterAddressType }
        STATUS current
        DESCRIPTION
            "A collection of attributes that contain stats about the
            virtual router."
        ::= { vrGroups 2 }

Layer-3 VPN Group             Expires June 2005             [Page 17]

Draft                    Virtual Router MIB              March 2005

    vrIfGroup OBJECT-GROUP
        OBJECTS { vrIfConfigRowStatus  }
        STATUS current
        DESCRIPTION
            "A collection of attributes that support provisioning of 
            a virtual router interfaces."
        ::= { vrGroups 3 }

    vrNotificationGroup NOTIFICATION-GROUP
        NOTIFICATIONS { vrUp, vrDown, vrMaxRoutesExceeded }
        STATUS current
        DESCRIPTION
            "A collection of traps that are supported by the VR."
        ::= { vrGroups 4 }

END

7.0 Acknowledgments

Special thanks to Joan Cucchiara for providing valuable comments 
on this MIB.

8.0 Security Considerations

There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create.  Such
objects may be considered sensitive or vulnerable in some network
environments.  The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.  These are the tables and objects and their
sensitivity/vulnerability:

The Administrative VR provides visibility into and control over 
multiple VPNs. As such, security considerations for implementations 
of the Administrative VR and associated control plane(s) are critical 
to the security of the VPNs supported on each PE device.

Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments.  It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP.  These are the tables and objects and their
sensitivity/vulnerability:

Use of any vrContextName MUST be allowed in the Administrative VR.
Additional authentication and security mechanisms SHOULD be used for 
SNMP access in the Administrative VR.

Layer-3 VPN Group             Expires June 2005             [Page 18]

Draft                    Virtual Router MIB              March 2005

VRs other than the Administrative VR MUST NOT have access to other 
VR's Instantiated MIBs, and MAY have access to their own instantiated 
MIBs.

In VRs other than the Administrative VR, access to that VR's 
instantiated MIBs MAY be permitted via that VR's vrContextName. Use
of any vrContextName other than that assigned to the accessed VR MUST 
result in an error, and implementations SHOULD provide a logging 
mechanism for such events.

SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.

It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms 
(for authentication and privacy).

Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security.  It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.

9.0 References

9.1 Normative References

[RFC2571]  Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
     for Describing SNMP Management Frameworks", RFC 2571, April 1999.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
     Requirements Levels", BCP 14, RFC 2119, March 1997.

[RFC2578]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
     Rose, M. and S. Waldbusser, "Structure of Management
     Information Version 2 (SMIv2)", STD 58, RFC 2578, April
     1999.

[RFC2579]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
     Rose, M. and S. Waldbusser, "Textual Conventions for
     SMIv2", STD 58, RFC 2579, April 1999.

[RFC2580]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
     Rose, M. and S. Waldbusser, "Conformance Statements for
     SMIv2", STD 58, RFC 2580, April 1999.

Layer-3 VPN Group             Expires June 2005             [Page 19]

Draft                    Virtual Router MIB              March 2005

9.2 Informative References

[RFC2685]  Fox B., et al, "Virtual Private Networks
     Identifier", RFC 2685, September 1999.

[VPNTCMIB]  B. Schliesser, and T. Nadeau, "Definition of Textual
     Conventions for Provider Provisioned Virtual Private Network
     (PPVPN) Management.", Internet Draft
     <draft-ietf-l3vpn-tc-mib-03.txt>, May 2004.

[PPVPN-FW] R. Callon, et al., "A Framework for Layer 3 Provider
     Provisioned Virtual Private Networks",
     draft-ietf-l3vpn-framework-00.txt, March 2003.

[PPVPN-VR] P. Knight, et al., "Network based IP VPN Architecture
     using Virtual Routers", draft-ietf-l3vpn-vpn-vr-02.txt, 
     April 2004.

[PPVPN-VR-AS] A. Nagarajan, et al., "Applicability Statement for
     Virtual Router-based Layer 3 PPVPN approaches",
     draft-ietf-l3vpn-as-vr-01.txt, March 2004.

10.0 Authors' Addresses

Elwin Stelzer Eliazer
Corona Networks, Inc.
630 Alder Drive
Milpitas, CA 95035
USA
Phone: +1-408-519-3832
Email: [email-masked]

Samuel Hancock
ACM Systems
3034 Gold Canal Drive
Rancho Cordova, CA 94123
USA
Phone: +1-916-463-7949
Email: [email-masked]

Benson Schliesser
SAVVIS Communications
1 Savvis Parkway
Town and Country, MO 63017
USA
Phone: +1-314-628-7036
Email: [email-masked]

Joseph Laria
Level Stream Research
Wilmington, MA  01887
USA
Phone: +1-978-884-3537
Emain: [email-masked]

Layer-3 VPN Group             Expires June 2005             [Page 20]

Draft                    Virtual Router MIB              March 2005

11.0  Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   inthis document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and and
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at 
   [email-masked].

12.0  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 
   OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

13.0  IANA Considerations for L3VPN-VR-MIB

   The IANA is requested to assign { experimental  XXXX } to the 
   L3VPN-VR-MIB module specified in this document.

Layer-3 VPN Group             Expires June 2005             [Page 21]

---

From: John Smith <[email-masked]>
Date: Tue, 15 Mar 2005 14:58:11 +0000 (GMT)

Hi,

Are the following statements true about BGP Route Reflectors in BGP/MPLS VPNs:

[1] We are not required to configure any RDs since most of the times there would not be
any customers attached to the RRs.

[2] The RR would be peered up with a couple of BGP PE routers. It would reflect
(following the rules laid out for RRs) all the BGP VPN routes it learns from one PE
router to the other PE router without modifying the NEXT_HOP. It does not even need to
look at the extended communities for doing that, unless some ORF has been advertised by a
PE router.

[3] If the RR does not have any VRFs then it will not insert any routes in its FIB and
will not program the MPLS labels. How would then the forwarding take place? Does the RR
need to do something special for that?

I would really appreciate if somebody could help me with these questions.

Thanks and Regards,
John Smith

Send instant messages to your online friends http://uk.messenger.yahoo.com