doc: Add RFC documents

1 files changed, 2019 insertions, 0 deletions

diff --git a/doc/rfc/rfc7697.txt b/doc/rfc/rfc7697.txt
new file mode 100644
index 0000000..d737e5f
--- /dev/null
+++ b/doc/rfc/rfc7697.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                            P. Pan
+Request for Comments: 7697                                      Infinera
+Category: Standards Track                                      S. Aldrin
+ISSN: 2070-1721                                             Google, Inc.
+                                                           M. Venkatesan
+                                                              Dell, Inc.
+                                                              K. Sampath
+                                                                  Redeem
+                                                               T. Nadeau
+                                                                 Brocade
+                                                              S. Boutros
+                                                            VMware, Inc.
+                                                            January 2016
+
+
+    MPLS Transport Profile (MPLS-TP) Operations, Administration, and
+    Maintenance (OAM) Identifiers Management Information Base (MIB)
+
+Abstract
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in the Internet community.
+   In particular, it describes managed objects to configure the
+   Operations, Administration, and Maintenance (OAM) identifiers for
+   Multiprotocol Label Switching (MPLS) and the MPLS-based Transport
+   Profile (TP).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7697.
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                    [Page 1]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. The Internet-Standard Management Framework ......................3
+   3. Overview ........................................................3
+      3.1. Conventions Used in This Document ..........................3
+      3.2. Terminology ................................................4
+      3.3. Acronyms ...................................................4
+   4. Feature List ....................................................5
+   5. Brief Description of MIB Objects ................................5
+      5.1. mplsOamIdMegTable ..........................................5
+      5.2. mplsOamIdMeTable ...........................................5
+   6. MPLS OAM Identifier Configuration for MPLS LSP: Example .........6
+   7. MPLS OAM Identifiers MIB Definitions ............................8
+   8. Security Considerations ........................................31
+   9. IANA Considerations ............................................32
+      9.1. IANA Considerations for MPLS-OAM-ID-STD-MIB ...............32
+   10. References ....................................................32
+      10.1. Normative References .....................................32
+      10.2. Informative References ...................................34
+   Acknowledgments ...................................................35
+   Authors' Addresses ................................................36
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                    [Page 2]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+1.  Introduction
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in the Internet community.
+   In particular, it describes managed objects for modeling a Transport
+   Profile (TP) based on Multiprotocol Label Switching (MPLS) [RFC3031].
+
+   This MIB module should be used for performing the OAM (Operations,
+   Administration, and Maintenance) operations for MPLS Tunnel LSPs
+   (Label Switched Paths), Pseudowires, and Sections.
+
+   At the time of this writing, SNMP SET is no longer recommended as a
+   way to configure MPLS networks as was described in [RFC3812].
+   However, since the MIB modules specified in this document are
+   intended to work in parallel with the MIB modules for MPLS specified
+   in [RFC3812], certain objects defined here are specified with a
+   MAX-ACCESS of read-write or read-create so that specifications of the
+   base tables in [RFC3812] and the new MIB modules in this document are
+   consistent.  Although the example described in Section 6 specifies
+   means to configure OAM identifiers for MPLS-TP Tunnels, this should
+   be seen as indicating how the MIB values would be returned in the
+   specified circumstances having been configured by alternative means.
+
+2.  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
+   RFC3410 [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].
+
+3.  Overview
+
+3.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   RFC 2119 [RFC2119].
+
+
+
+
+
+Aldrin, et al.               Standards Track                    [Page 3]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+3.2.  Terminology
+
+   This document uses terminology from the Multiprotocol Label Switching
+   Architecture [RFC3031], the MPLS Traffic Engineering (TE) MIB
+   [RFC3812], the MPLS Label Switching Router (LSR) MIB [RFC3813], the
+   OAM Framework for MPLS-Based Transport Networks [RFC6371], "MPLS
+   Transport Profile (MPLS-TP) Identifiers" [RFC6370], MPLS-TP
+   Identifiers Following ITU-T Conventions [RFC6923], and OAM in MPLS
+   Transport Networks [RFC5860].
+
+3.3.  Acronyms
+
+   BFD: Bidirectional Forwarding Detection
+
+   ICC: ITU Carrier Code
+
+   IP: Internet Protocol
+
+   LSP: Label Switched Path
+
+   LSR: Label Switching Router
+
+   ME: Maintenance Entity
+
+   MEG: Maintenance Entity Group
+
+   MEP: Maintenance Entity Group End Point
+
+   MIB: Management Information Base
+
+   MIP: Maintenance Entity Group Intermediate Point
+
+   MP: Maintenance Point
+
+   MPLS: Multiprotocol Label Switching
+
+   MPLS-TP: MPLS Transport Profile
+
+   PW: Pseudowire
+
+   TE: Traffic Engineering
+
+   TP: Transport Profile
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                    [Page 4]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+4.  Feature List
+
+   The MPLS transport profile OAM identifiers MIB module is designed to
+   satisfy the following requirements and constraints:
+
+   -  The MIB module supports configuration of OAM identifiers for MPLS
+      point-to-point Tunnels, point-to-multipoint LSPs, co-routed
+      bidirectional LSPs, associated bidirectional LSPs, and
+      Pseudowires.
+
+5.  Brief Description of MIB Objects
+
+   The objects described in this section support the functionality
+   described in [RFC5654] and [RFC6370].  The tables support both
+   IP-compatible and ICC-based OAM identifiers configurations for MPLS
+   Tunnels, LSPs, and Pseudowires.
+
+5.1.  mplsOamIdMegTable
+
+   The mplsOamIdMegTable is used to manage one or more Maintenance
+   Entities (MEs) that belong to the same transport path.
+
+   When a new entry is created with mplsOamIdMegOperatorType set to
+   ipCompatible (1), then as per [RFC6370] (MEG_ID for an LSP is LSP_ID,
+   and MEG_ID for a PW is PW_Path_ID), MEP_ID can be automatically
+   formed.
+
+   For an ICC-based transport path, the user is expected to configure
+   the ICC identifier explicitly in this table for MPLS Tunnels, LSPs,
+   and Pseudowires.
+
+5.2.  mplsOamIdMeTable
+
+   The mplsOamIdMeTable defines a relationship between two points
+   (source and sink) of a transport path to which maintenance and
+   monitoring operations apply.  The two points that define an ME are
+   called Maintenance Entity Group End Points (MEPs).
+
+   In between MEPs, there are zero or more intermediate points, called
+   Maintenance Entity Group Intermediate Points (MIPs).  MEPs and MIPs
+   are associated with the MEG and can be shared by more than one ME in
+   a MEG.
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                    [Page 5]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+6.  MPLS OAM Identifier Configuration for MPLS LSP: Example
+
+   In this section, we provide an example of the OAM identifier
+   configuration for an MPLS co-routed bidirectional LSP.
+
+   This example provides usage of MEG and ME tables for management and
+   monitoring operations of an MPLS LSP.
+
+   This example considers the OAM identifiers configuration on a
+   head-end LSR to manage and monitor an MPLS LSP.  Only relevant
+   objects that are applicable for IP-based OAM identifiers of MPLS
+   co-routed bidirectional LSPs are illustrated here.
+
+      In the mplsOamIdMegTable:
+
+      {
+        -- MEG index (Index to the table)
+        mplsOamIdMegIndex                 = 1,
+        mplsOamIdMegName                  = "MEG1",
+        mplsOamIdMegOperatorType          = ipCompatible (1),
+        mplsOamIdMegServicePointerType    = lsp (1),
+        mplsOamIdMegMpLocation            = perNode (1),
+      -- Mandatory parameters needed to activate the row go here
+
+        mplsOamIdMegRowStatus             = createAndGo (4),
+        mplsOamIdMegPathFlow
+                             = coRoutedBidirectionalPointToPoint (2)
+      }
+
+      This will create an entry in the mplsOamIdMegTable to manage and
+      monitor the MPLS Tunnel.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                    [Page 6]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+      The following ME table is used to associate the path information
+      to a MEG.
+
+         In the mplsOamIdMeTable:
+
+         {
+         -- ME index (Index to the table)
+          mplsOamIdMeIndex                  = 1,
+
+         -- MP index (Index to the table)
+          mplsOamIdMeMpIndex                = 1,
+          mplsOamIdMeName                   = "ME1",
+          mplsOamIdMeMpIfIndex              = 0,
+         -- The source MEP ID is derived from the IP-compatible MPLS LSP
+          mplsOamIdMeSourceMepIndex         = 0,
+         -- The sink MEP ID is derived from the IP-compatible MPLS LSP
+          mplsOamIdMeSinkMepIndex           = 0,
+          mplsOamIdMeMpType                 = mep (1),
+          mplsOamIdMeMepDirection           = down (2),
+         --  RowPointer MUST point to the first accessible column of an
+         --  MPLS LSP
+          mplsOamIdMeServicePointer         = mplsTunnelName.1.1.10.20,
+         -- Mandatory parameters needed to activate the row go here
+          mplsOamIdMeRowStatus              = createAndGo (4)
+         }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                    [Page 7]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+7.  MPLS OAM Identifiers MIB Definitions
+
+   MPLS-OAM-ID-STD-MIB DEFINITIONS ::= BEGIN
+
+       IMPORTS
+          MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
+          Unsigned32
+             FROM SNMPv2-SMI                   -- RFC 2578
+          MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
+             FROM SNMPv2-CONF                  -- RFC 2580
+          RowStatus, RowPointer, StorageType
+             FROM SNMPv2-TC                    -- RFC 2579
+          SnmpAdminString
+             FROM SNMP-FRAMEWORK-MIB           -- RFC 3411
+          IndexIntegerNextFree
+             FROM DIFFSERV-MIB                 -- RFC 3289
+          mplsStdMIB
+             FROM MPLS-TC-STD-MIB              -- RFC 3811
+          InterfaceIndexOrZero, ifGeneralInformationGroup,
+          ifCounterDiscontinuityGroup
+             FROM IF-MIB;                      -- RFC 2863
+
+      mplsOamIdStdMIB MODULE-IDENTITY
+         LAST-UPDATED
+            "201601070000Z" -- January 07, 2016
+         ORGANIZATION
+            "Multiprotocol Label Switching (MPLS) Working Group"
+         CONTACT-INFO
+            "Sam Aldrin
+             Google, Inc.
+             1600 Amphitheatre Parkway
+             Mountain View, CA  94043
+             USA
+             Email: aldrin.ietf@gmail.com
+
+             Thomas D. Nadeau
+             Email: tnadeau@lucidvision.com
+
+             Venkatesan Mahalingam
+             Dell, Inc.
+             5450 Great America Parkway
+             Santa Clara, CA  95054
+             USA
+             Email: venkat.mahalingams@gmail.com
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                    [Page 8]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+             Kannan KV Sampath
+             Redeem
+             India
+             Email: kannankvs@gmail.com
+
+             Ping Pan
+             Infinera
+
+             Sami Boutros
+             VMware, Inc.
+             3401 Hillview Ave.
+             Palo Alto, CA  94304
+             USA
+             Email: sboutros@vmware.com"
+
+         DESCRIPTION
+            "Copyright (c) 2016 IETF Trust and the persons identified
+             as authors of the code.  All rights reserved.
+
+             Redistribution and use in source and binary forms, with or
+             without modification, is permitted pursuant to, and subject
+             to the license terms contained in, the Simplified BSD
+             License set forth in Section 4.c of the IETF Trust's
+             Legal Provisions Relating to IETF Documents
+             (http://trustee.ietf.org/license-info).
+
+             This MIB module contains generic object definitions for
+             MPLS OAM identifiers."
+
+         -- Revision history
+
+         REVISION
+            "201601070000Z" -- January 07, 2016
+         DESCRIPTION
+            "MPLS OAM Identifiers MIB objects for Tunnels, LSPs,
+             Pseudowires, and Sections."
+
+         ::= { mplsStdMIB 21 }
+
+      -- Top-level components of this MIB module
+
+      -- notifications
+      mplsOamIdNotifications
+                   OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 0 }
+      -- tables, scalars
+      mplsOamIdObjects  OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 1 }
+
+
+
+
+
+Aldrin, et al.               Standards Track                    [Page 9]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+      -- conformance
+      mplsOamIdConformance
+                   OBJECT IDENTIFIER ::= { mplsOamIdStdMIB 2 }
+
+       -- Start of MPLS Transport Profile MEG table
+
+      mplsOamIdMegIndexNext OBJECT-TYPE
+         SYNTAX        IndexIntegerNextFree (0..4294967295)
+         MAX-ACCESS    read-only
+         STATUS        current
+         DESCRIPTION
+           "This object contains an unused value for
+            mplsOamIdMegIndex, or a zero to indicate
+            that none exist.  Negative values are not allowed,
+            as they do not correspond to valid values of
+            mplsOamIdMegIndex."
+         ::= { mplsOamIdObjects 1 }
+
+      mplsOamIdMegTable OBJECT-TYPE
+         SYNTAX        SEQUENCE OF MplsOamIdMegEntry
+         MAX-ACCESS    not-accessible
+         STATUS        current
+         DESCRIPTION
+           "This table contains information about the Maintenance
+            Entity Groups (MEGs).
+
+            A MEG, as mentioned in the MPLS-TP OAM framework, defines
+            a set of one or more Maintenance Entities (MEs).
+            MEs define a relationship between any two points of a
+            transport path in an OAM domain to which maintenance and
+            monitoring operations apply."
+         ::= { mplsOamIdObjects 2 }
+
+       mplsOamIdMegEntry OBJECT-TYPE
+          SYNTAX        MplsOamIdMegEntry
+          MAX-ACCESS    not-accessible
+          STATUS        current
+          DESCRIPTION
+            "An entry in this table represents an MPLS-TP MEG.
+             An entry can be created by a network administrator
+             or by an SNMP agent as instructed by an MPLS-TP OAM
+             framework.
+
+             When a new entry is created with
+             mplsOamIdMegOperatorType set to ipCompatible (1),
+             then as per RFC 6370 (MEG_ID for an LSP is LSP_ID, and
+             MEG_ID for a PW is PW_Path_ID), MEP_ID can be
+             automatically formed.
+
+
+
+Aldrin, et al.               Standards Track                   [Page 10]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+             For a co-routed bidirectional LSP, MEG_ID is
+             A1-{Global_ID::Node_ID::Tunnel_Num}::Z9-{Global_ID::
+             Node_ID::Tunnel_Num}::LSP_Num.
+
+             For an associated bidirectional LSP, MEG_ID is
+             A1-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}::
+             Z9-{Global_ID::Node_ID::Tunnel_Num::LSP_Num}.
+
+             For an LSP, MEP_ID is formed using
+             Global_ID::Node_ID::Tunnel_Num::LSP_Num.
+
+             For a PW, MEG_ID is formed using AGI::
+             A1-{Global_ID::Node_ID::AC_ID}::
+             Z9-{Global_ID::Node_ID::AC_ID}.
+
+             For a PW, MEP_ID is formed using
+             AGI::Global_ID::Node_ID::AC_ID.
+
+             MEP_ID is retrieved from the mplsOamIdMegServicePointer
+             object based on the mplsOamIdMegServicePointerType value.
+             The ICC MEG_ID for an LSP and a PW is formed using the
+             objects mplsOamIdMegIdIcc and mplsOamIdMegIdUmc.
+
+             MEP_ID can be formed using MEG_ID::MEP_Index."
+          REFERENCE
+            "1. RFC 5860: Requirements for Operations, Administration,
+                and Maintenance (OAM) in MPLS Transport Networks,
+                May 2010.
+             2. RFC 6371: Operations, Administration, and Maintenance
+                Framework for MPLS-Based Transport Networks,
+                September 2011, Section 3.
+             3. RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers,
+                September 2011.
+             4. RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers
+                Following ITU-T Conventions, May 2013."
+          INDEX { mplsOamIdMegIndex }
+          ::= { mplsOamIdMegTable 1 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 11]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+          MplsOamIdMegEntry ::= SEQUENCE {
+             mplsOamIdMegIndex                 Unsigned32,
+             mplsOamIdMegName                  SnmpAdminString,
+             mplsOamIdMegOperatorType          INTEGER,
+             mplsOamIdMegIdCc                  SnmpAdminString,
+             mplsOamIdMegIdIcc                 SnmpAdminString,
+             mplsOamIdMegIdUmc                 SnmpAdminString,
+             mplsOamIdMegServicePointerType    INTEGER,
+             mplsOamIdMegMpLocation            INTEGER,
+             mplsOamIdMegPathFlow              INTEGER,
+             mplsOamIdMegOperStatus            INTEGER,
+             mplsOamIdMegSubOperStatus         BITS,
+             mplsOamIdMegRowStatus             RowStatus,
+             mplsOamIdMegStorageType           StorageType
+       }
+
+       mplsOamIdMegIndex  OBJECT-TYPE
+          SYNTAX        Unsigned32 (1..4294967295)
+          MAX-ACCESS    not-accessible
+          STATUS        current
+          DESCRIPTION
+            "Index for the conceptual row identifying a MEG within
+             this MEG table.  Managers should obtain new values for row
+             creation in this table by reading mplsOamIdMegIndexNext."
+          ::= { mplsOamIdMegEntry 1 }
+
+       mplsOamIdMegName  OBJECT-TYPE
+          SYNTAX        SnmpAdminString (SIZE(0..48))
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Each MEG has a unique name amongst all those used or
+             available to a service provider or operator.  It
+             facilitates easy identification of administrative
+             responsibility for each MEG."
+          ::= { mplsOamIdMegEntry 2 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 12]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+       mplsOamIdMegOperatorType OBJECT-TYPE
+          SYNTAX        INTEGER {
+                            ipCompatible (1),
+                            iccBased (2)
+                        }
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Indicates the operator type for the MEG.  Conceptual rows
+             having 'iccBased' as the operator type MUST have valid
+             values for the objects mplsOamIdMegIdIcc and
+             mplsOamIdMegIdUmc when the row status is active."
+          REFERENCE
+            "1. RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers,
+                September 2011.
+             2. RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers
+                Following ITU-T Conventions, May 2013, Section 3.1."
+          DEFVAL { ipCompatible }
+          ::= { mplsOamIdMegEntry 3 }
+
+       mplsOamIdMegIdCc OBJECT-TYPE
+          SYNTAX        SnmpAdminString (SIZE(0..2))
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Global uniqueness is assured by concatenating the ICC
+             with a Country Code (CC).  The Country Code (alpha-2)
+             is a string of two alphabetic characters represented
+             with uppercase letters (i.e., A-Z).
+
+             This object MUST contain a non-null value if
+             the MplsOamIdMegOperatorType value is iccBased (2);
+             otherwise, a null value with octet size 0
+             should be assigned."
+          REFERENCE
+            "RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers
+             Following ITU-T Conventions, May 2013, Section 3."
+          DEFVAL {""}
+          ::= { mplsOamIdMegEntry 4 }
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 13]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+       mplsOamIdMegIdIcc OBJECT-TYPE
+          SYNTAX        SnmpAdminString (SIZE(0..6))
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Unique code assigned to a network operator or service
+             provider; maintained by the ITU-T.  This is the
+             ITU Carrier Code used to form the MEGID.
+
+             This object MUST contain a non-null value if
+             the MplsOamIdMegOperatorType value is iccBased (2);
+             otherwise, a null value with octet size 0
+             should be assigned."
+          REFERENCE
+            "RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers
+             Following ITU-T Conventions, May 2013, Section 3.1."
+          DEFVAL {""}
+          ::= { mplsOamIdMegEntry 5 }
+
+       mplsOamIdMegIdUmc OBJECT-TYPE
+          SYNTAX        SnmpAdminString (SIZE(0..7))
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Unique code assigned by a network operator or service
+             provider.  This code is appended to mplsOamIdMegIdIcc to
+             form the MEGID.
+             This object MUST contain a non-null value if
+             the MplsOamIdMegOperatorType value is iccBased (2);
+             otherwise, a null value with octet size 0
+             should be assigned."
+          REFERENCE
+            "RFC 6923: MPLS Transport Profile (MPLS-TP) Identifiers
+             Following ITU-T Conventions, May 2013, Section 7.1."
+          DEFVAL {""}
+          ::= { mplsOamIdMegEntry 6 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 14]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+       mplsOamIdMegServicePointerType OBJECT-TYPE
+          SYNTAX        INTEGER {
+                            tunnel (1),
+                            lsp (2),
+                            pseudowire (3),
+                            section (4)
+                        }
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Indicates the service type for the MEG.
+             If the service type indicates tunnel (1), the service
+             pointer in the mplsOamIdMeTable points to an entry in
+             the point-to-point mplsTunnelTable (RFC 3812).
+
+             If the service type indicates lsp (2), the service pointer
+             in the mplsOamIdMeTable points to an entry in
+             the co-routed or associated bidirectional mplsTunnelTable.
+
+             If the value is the pseudowire (3) service type, the
+             service pointer in the mplsOamIdMeTable points to an entry
+             in the pwTable (RFC 5601).
+
+             If the value is the section (4) service type, the service
+             pointer in the mplsOamIdMeTable points to an entry in
+             the mplsTunnelTable (RFC 3812)."
+          REFERENCE
+            "1. RFC 3812: Multiprotocol Label Switching (MPLS)
+                Traffic Engineering (TE) Management Information
+                Base (MIB), June 2004.
+             2. RFC 5601: Pseudowire (PW) Management Information
+                Base (MIB), July 2009."
+          DEFVAL { lsp }
+          ::= { mplsOamIdMegEntry 7 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 15]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+       mplsOamIdMegMpLocation OBJECT-TYPE
+          SYNTAX        INTEGER {
+                            perNode (1),
+                            perInterface (2)
+                        }
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Indicates the MP location type for this MEG.
+
+             If the value is perNode, then the MEG in the LSR supports
+             only perNode MEPs/MIPs, i.e., only one MEP/MIP in an LSR.
+
+             If the value is perInterface, then the MEG in the LSR
+             supports perInterface MEPs/MIPs, i.e., two MEPs/MIPs in
+             an LSR."
+          REFERENCE
+            "RFC 6371: Operations, Administration, and Maintenance
+             Framework for MPLS-Based Transport Networks,
+             September 2011."
+          DEFVAL { perNode }
+          ::= { mplsOamIdMegEntry 8 }
+
+       mplsOamIdMegPathFlow OBJECT-TYPE
+          SYNTAX        INTEGER {
+                            unidirectionalPointToPoint (1),
+                            coRoutedBidirectionalPointToPoint (2),
+                            associatedBidirectionalPointToPoint (3),
+                            unidirectionalPointToMultiPoint (4)
+                        }
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Indicates the transport path flow for this MEG.
+             In the case of a unidirectional point-to-point transport
+             path, a single unidirectional ME is defined to monitor it.
+             In the case of associated bidirectional point-to-point
+             transport paths, two independent unidirectional MEs are
+             defined to independently monitor each direction.
+             In the case of co-routed bidirectional point-to-point
+             transport paths, a single bidirectional ME is defined to
+             monitor both directions congruently.
+             In the case of unidirectional point-to-multipoint transport
+             paths, a single unidirectional ME for each leaf is defined
+             to monitor the transport path from the root to that leaf."
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 16]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+          REFERENCE
+            "RFC 6371: Operations, Administration, and Maintenance
+             Framework for MPLS-Based Transport Networks,
+             September 2011."
+          DEFVAL { coRoutedBidirectionalPointToPoint }
+          ::= { mplsOamIdMegEntry 9 }
+
+       mplsOamIdMegOperStatus OBJECT-TYPE
+          SYNTAX       INTEGER {
+                           up (1),
+                           down (2)
+                       }
+          MAX-ACCESS   read-only
+          STATUS       current
+          DESCRIPTION
+            "This object specifies the operational status of the
+             Maintenance Entity Group (MEG).  This object is used to
+             send the notification to the SNMP manager about the MEG.
+
+             The value up (1) indicates that the MEG and its monitored
+             path are operationally up.  The value down (2) indicates
+             that the MEG is operationally down.
+
+             When the value of mplsOamIdMegOperStatus is up (1),
+             all the bits of mplsOamIdMegSubOperStatus must be cleared.
+             When the value of mplsOamIdMegOperStatus is down (2),
+             at least one bit of mplsOamIdMegSubOperStatus must be set."
+          ::= { mplsOamIdMegEntry 10 }
+
+       mplsOamIdMegSubOperStatus OBJECT-TYPE
+          SYNTAX       BITS {
+                        megDown (0),
+                        meDown (1),
+                        oamAppDown (2),
+                        pathDown (3)
+                       }
+          MAX-ACCESS   read-only
+          STATUS       current
+          DESCRIPTION
+            "This object specifies the reason why the MEG operational
+             status, as indicated by the object mplsOamIdMegOperStatus,
+             is down.  This object is used to send the notification to
+             the SNMP manager about the MEG.
+
+             The bit 0 (megDown) indicates that the MEG is down.
+             The bit 1 (meDown) indicates that the ME table is down.
+             The bit 2 (oamAppDown) indicates that the OAM application
+             (LSP or PW) monitored by this MEG is down.  Currently, BFD
+
+
+
+Aldrin, et al.               Standards Track                   [Page 17]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+             is the only supported OAM application.
+             The bit 3 (pathDown) indicates that the underlying
+             LSP or PW is down."
+          ::= { mplsOamIdMegEntry 11 }
+
+       mplsOamIdMegRowStatus OBJECT-TYPE
+          SYNTAX        RowStatus
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+             "This variable is used to create, modify, and/or delete
+              a row in this table.  When a row in this table is in the
+              active(1) state, no objects in that row can be modified
+              by the agent except mplsOamIdMegRowStatus."
+          ::= { mplsOamIdMegEntry 12 }
+
+       mplsOamIdMegStorageType OBJECT-TYPE
+          SYNTAX        StorageType
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "This variable indicates the storage type for this
+             object.
+             Conceptual rows having the value 'permanent'
+             need not allow write access to any columnar
+             objects in the row."
+          DEFVAL { volatile }
+          ::= { mplsOamIdMegEntry 13 }
+
+       -- End of MPLS Transport Profile MEG table
+
+
+       -- Start of MPLS Transport Profile ME table
+
+       mplsOamIdMeIndexNext OBJECT-TYPE
+          SYNTAX        IndexIntegerNextFree (0..4294967295)
+          MAX-ACCESS    read-only
+          STATUS        current
+          DESCRIPTION
+            "This object contains an unused value for
+             mplsOamIdMeIndex, or a zero to indicate
+             that none exist.  Negative values are not allowed,
+             as they do not correspond to valid values of
+             mplsOamIdMeIndex."
+          ::= { mplsOamIdObjects 3 }
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 18]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+       mplsOamIdMeMpIndexNext OBJECT-TYPE
+          SYNTAX        IndexIntegerNextFree (0..4294967295)
+          MAX-ACCESS    read-only
+          STATUS        current
+          DESCRIPTION
+            "This object contains an unused value for
+             mplsOamIdMeMpIndex, or a zero to indicate
+             that none exist.  Negative values are not allowed,
+             as they do not correspond to valid values of
+             mplsOamIdMeMpIndex."
+          ::= { mplsOamIdObjects 4 }
+
+       mplsOamIdMeTable OBJECT-TYPE
+          SYNTAX        SEQUENCE OF MplsOamIdMeEntry
+          MAX-ACCESS    not-accessible
+          STATUS        current
+          DESCRIPTION
+            "This table contains MPLS-TP ME information.
+
+             The ME is some portion of a transport path that requires
+             management bounded by two points (called MEPs), and the
+             relationship between those points to which maintenance
+             and monitoring operations apply.
+
+             This table is generic enough to handle MEP and MIP
+             information within a MEG."
+          ::= { mplsOamIdObjects 5 }
+
+       mplsOamIdMeEntry OBJECT-TYPE
+          SYNTAX        MplsOamIdMeEntry
+          MAX-ACCESS    not-accessible
+          STATUS        current
+          DESCRIPTION
+            "An entry in this table represents an MPLS-TP ME.  This
+             entry represents the ME if the source and sink MEPs are
+             defined.
+
+             An ME is a point-to-point entity.  One ME has two such
+             MEPs.  A MEG is a group of one or more MEs.  One MEG can
+             have two or more MEPs.
+
+             For a point-to-point LSP, one MEG has one ME, and this ME
+             is associated with two MEPs (source and sink MEPs) within
+             a MEG.  Each mplsOamIdMeIndex value denotes the ME within
+             a MEG.
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 19]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+             In the case of unidirectional point-to-point transport
+             paths, a single unidirectional ME is defined to monitor
+             it, and mplsOamIdMeServicePointer points to a
+             unidirectional point-to-point path.
+
+             In the case of associated bidirectional point-to-point
+             transport paths, two independent unidirectional
+             MEs are defined to independently monitor each direction,
+             and each mplsOamIdMeServicePointer MIB object points to a
+             unique unidirectional transport path.
+             This has implications for transactions that terminate at
+             or query a MIP, as a return path from a MIP to a source
+             MEP does not necessarily exist within the MEG.
+
+             In the case of co-routed bidirectional point-to-point
+             transport paths, a single bidirectional ME is defined to
+             monitor both directions congruently, and the
+             mplsOamIdMeServicePointer MIB object points to a co-routed
+             bidirectional point-to-point transport path.
+
+             In the case of unidirectional point-to-multipoint transport
+             paths, a single unidirectional ME for each leaf is defined
+             to monitor the transport path from the root to that leaf,
+             and each leaf has different transport path information in
+             the mplsOamIdMeServicePointer MIB object.  Note that the
+             MplsOamIdMeEntry should be created manually once the MEG
+             is configured for OAM operations."
+             INDEX { mplsOamIdMegIndex,
+                     mplsOamIdMeIndex,
+                     mplsOamIdMeMpIndex
+                   }
+             ::= { mplsOamIdMeTable 1 }
+
+           MplsOamIdMeEntry ::= SEQUENCE {
+              mplsOamIdMeIndex                  Unsigned32,
+              mplsOamIdMeMpIndex                Unsigned32,
+              mplsOamIdMeName                   SnmpAdminString,
+              mplsOamIdMeMpIfIndex              InterfaceIndexOrZero,
+              mplsOamIdMeSourceMepIndex         Unsigned32,
+              mplsOamIdMeSinkMepIndex           Unsigned32,
+              mplsOamIdMeMpType                 INTEGER,
+              mplsOamIdMeMepDirection           INTEGER,
+              mplsOamIdMeServicePointer         RowPointer,
+              mplsOamIdMeRowStatus              RowStatus,
+              mplsOamIdMeStorageType            StorageType
+        }
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 20]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+       mplsOamIdMeIndex  OBJECT-TYPE
+          SYNTAX        Unsigned32 (1..4294967295)
+          MAX-ACCESS    not-accessible
+          STATUS        current
+          DESCRIPTION
+            "Uniquely identifies an ME index within a MEG.  Managers
+             should obtain new values for row creation in this table by
+             reading mplsOamIdMeIndexNext."
+          ::= { mplsOamIdMeEntry 1 }
+
+       mplsOamIdMeMpIndex  OBJECT-TYPE
+          SYNTAX        Unsigned32 (1..4294967295)
+          MAX-ACCESS    not-accessible
+          STATUS        current
+          DESCRIPTION
+            "Indicates the Maintenance Point (MP) index that is used to
+             create multiple MEPs in a node of a single ME.  The value
+             of this object can be the MEP index or the MIP index.
+             Managers should obtain new values for row creation in this
+             table by reading mplsOamIdMeMpIndexNext."
+          ::= { mplsOamIdMeEntry 2 }
+
+       mplsOamIdMeName  OBJECT-TYPE
+          SYNTAX        SnmpAdminString (SIZE(1..48))
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "This object denotes the ME name.  Each ME has a unique
+             name within a MEG."
+          ::= { mplsOamIdMeEntry 3 }
+
+       mplsOamIdMeMpIfIndex OBJECT-TYPE
+          SYNTAX        InterfaceIndexOrZero
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Indicates the MP interface.
+             If the mplsOamIdMegMpLocation object value
+             is perNode (1), the MP interface index should point
+             to the incoming interface or outgoing interface, or
+             be zero (to indicate that the MP OAM packets are initiated
+             from the forwarding engine).
+
+             If the mplsOamIdMegMpLocation object value is
+             perInterface (2), the MP interface index should point to
+             the incoming interface or outgoing interface."
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 21]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+          REFERENCE
+            "1. RFC 6371: Operations, Administration, and Maintenance
+                Framework for MPLS-Based Transport Networks,
+                September 2011.
+             2. RFC 2863: The Interfaces Group MIB, June 2000."
+          DEFVAL { 0 }
+          ::= { mplsOamIdMeEntry 4 }
+
+       mplsOamIdMeSourceMepIndex  OBJECT-TYPE
+          SYNTAX        Unsigned32
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Indicates the source MEP index of the ME.  This object
+             should be configured if the mplsOamIdMegOperatorType object
+             in the mplsOamIdMegEntry is configured as iccBased (2).
+             If the MEG is configured for an IP-based operator,
+             the value of this object should be set to zero, and the
+             MEP ID will be automatically derived from the service
+             identifiers (MPLS-TP LSP/PW Identifier)."
+          DEFVAL { 0 }
+          ::= { mplsOamIdMeEntry 5 }
+
+       mplsOamIdMeSinkMepIndex  OBJECT-TYPE
+          SYNTAX        Unsigned32
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Indicates the sink MEP index of the ME.  This object
+             should be configured if the mplsOamIdMegOperatorType object
+             in the mplsOamIdMegEntry is configured as iccBased (2).
+             If the MEG is configured for an IP-based operator,
+             the value of this object should be set to zero, and the
+             MEP ID will be automatically derived from the service
+             identifiers (MPLS-TP LSP/PW Identifier)."
+          DEFVAL { 0 }
+          ::= { mplsOamIdMeEntry 6 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 22]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+       mplsOamIdMeMpType OBJECT-TYPE
+          SYNTAX        INTEGER {
+                            mep (1),
+                            mip (2)
+                        }
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Indicates the MP type within the MEG.
+
+             The object should have the value mep (1) only in the
+             ingress or egress nodes of the transport path.
+
+             The object can have the value mip (2) in the
+             intermediate nodes and possibly in the egress nodes
+             of the transport path."
+          DEFVAL { mep }
+          ::= { mplsOamIdMeEntry 7 }
+
+       mplsOamIdMeMepDirection OBJECT-TYPE
+          SYNTAX        INTEGER {
+                            up (1),
+                            down (2),
+                            notApplicable (3)
+                        }
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "Indicates the direction of the MEP.  This object
+             should be configured if mplsOamIdMeMpType is configured
+             as mep (1); otherwise, notApplicable (3) is set."
+          DEFVAL { down }
+          ::= { mplsOamIdMeEntry 8 }
+
+       mplsOamIdMeServicePointer OBJECT-TYPE
+          SYNTAX        RowPointer
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "This variable represents a pointer to the MPLS-TP
+             transport path.  This value MUST point at an entry in the
+             mplsTunnelEntry if mplsOamIdMegServicePointerType
+             is configured as tunnel (1), lsp (2), or section (4),
+             or at an entry in the pwEntry if
+             mplsOamIdMegServicePointerType is configured
+             as pseudowire (3).
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 23]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+             Note: This service pointer object is placed in the ME table
+             instead of the MEG table, since it will be useful in the
+             point-to-multipoint case, where each ME will point to
+             different branches of a point-to-multipoint tree."
+          ::= { mplsOamIdMeEntry 9 }
+
+       mplsOamIdMeRowStatus OBJECT-TYPE
+          SYNTAX        RowStatus
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "This variable is used to create, modify, and/or delete
+             a row in this table.  When a row in this table is in the
+             active(1) state, no objects in that row can be modified
+             by the agent except mplsOamIdMeRowStatus."
+          ::= { mplsOamIdMeEntry 10 }
+
+       mplsOamIdMeStorageType OBJECT-TYPE
+          SYNTAX        StorageType
+          MAX-ACCESS    read-create
+          STATUS        current
+          DESCRIPTION
+            "This variable indicates the storage type for this object.
+             Conceptual rows having the value 'permanent'
+             need not allow write access to any columnar
+             objects in the row."
+          DEFVAL { volatile }
+          ::= { mplsOamIdMeEntry 11 }
+
+       -- End of MPLS Transport Profile ME table
+
+       -- End of MPLS-TP OAM tables
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 24]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+   -- Notification definitions of MPLS-TP identifiers
+
+       mplsOamIdDefectCondition NOTIFICATION-TYPE
+          OBJECTS      {
+                         mplsOamIdMegName,
+                         mplsOamIdMeName,
+                         mplsOamIdMegOperStatus,
+                         mplsOamIdMegSubOperStatus
+                       }
+          STATUS       current
+          DESCRIPTION
+            "This notification is sent whenever the operational
+             status of the MEG is changed."
+          ::= { mplsOamIdNotifications 1 }
+
+   -- End of notifications
+
+
+   -- Module compliance
+
+   mplsOamIdCompliances
+      OBJECT IDENTIFIER ::= { mplsOamIdConformance 1 }
+
+   mplsOamIdGroups
+      OBJECT IDENTIFIER ::= { mplsOamIdConformance 2 }
+
+   -- Compliance requirement for fully compliant implementations
+
+   mplsOamIdModuleFullCompliance MODULE-COMPLIANCE
+      STATUS       current
+      DESCRIPTION "Compliance statement for agents that provide full
+                   support for the MPLS-TP-OAM-STD-MIB.  Such devices
+                   can then be monitored and also be configured
+                   using this MIB module."
+
+      MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863
+      MANDATORY-GROUPS {
+         ifGeneralInformationGroup,
+         ifCounterDiscontinuityGroup
+      }
+
+      MODULE -- this module
+      MANDATORY-GROUPS {
+            mplsOamIdMegGroup,
+            mplsOamIdMeGroup
+      }
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 25]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+      GROUP        mplsOamIdNotificationObjectsGroup
+      DESCRIPTION "This group is only mandatory for those
+                   implementations that can efficiently implement
+                   the notifications contained in this group."
+
+      GROUP        mplsOamIdNotificationGroup
+      DESCRIPTION "This group is only mandatory for those
+                   implementations that can efficiently implement
+                   the notifications contained in this group."
+
+      ::= { mplsOamIdCompliances 1 }
+
+        -- Compliance requirement for read-only implementations
+
+         mplsOamIdModuleReadOnlyCompliance MODULE-COMPLIANCE
+            STATUS current
+            DESCRIPTION
+                "Compliance statement for agents that only provide
+                 read-only support for the MPLS-TP-OAM-STD-MIB module."
+
+            MODULE -- this module
+
+         MANDATORY-GROUPS    {
+            mplsOamIdMegGroup,
+            mplsOamIdMeGroup
+         }
+
+
+      GROUP        mplsOamIdNotificationObjectsGroup
+      DESCRIPTION "This group is only mandatory for those
+                   implementations that can efficiently implement
+                   the notifications contained in this group."
+
+      GROUP        mplsOamIdNotificationGroup
+      DESCRIPTION "This group is only mandatory for those
+                   implementations that can efficiently implement
+                   the notifications contained in this group."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 26]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+         -- mplsOamIdMegTable
+
+         OBJECT      mplsOamIdMegName
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMegOperatorType
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMegIdCc
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMegIdIcc
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMegIdUmc
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMegServicePointerType
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMegMpLocation
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMegPathFlow
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMegRowStatus
+         SYNTAX      RowStatus { active(1) }
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 27]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+         OBJECT      mplsOamIdMegStorageType
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         -- mplsOamIdMeTable
+
+         OBJECT      mplsOamIdMeName
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMeMpIfIndex
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMeSourceMepIndex
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMeSinkMepIndex
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMeMpType
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMeMepDirection
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMeServicePointer
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+         OBJECT      mplsOamIdMeRowStatus
+         SYNTAX      RowStatus { active(1) }
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 28]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+         OBJECT      mplsOamIdMeStorageType
+         MIN-ACCESS  read-only
+         DESCRIPTION
+               "Write access is not required."
+
+      ::= { mplsOamIdCompliances 2 }
+
+   -- Units of conformance
+
+   mplsOamIdMegGroup OBJECT-GROUP
+      OBJECTS {
+         mplsOamIdMegIndexNext,
+         mplsOamIdMegName,
+         mplsOamIdMegOperatorType,
+         mplsOamIdMegIdCc,
+         mplsOamIdMegIdIcc,
+         mplsOamIdMegIdUmc,
+         mplsOamIdMegServicePointerType,
+         mplsOamIdMegMpLocation,
+         mplsOamIdMegOperStatus,
+         mplsOamIdMegSubOperStatus,
+         mplsOamIdMegPathFlow,
+         mplsOamIdMegRowStatus,
+         mplsOamIdMegStorageType
+      }
+
+      STATUS  current
+      DESCRIPTION
+            "Collection of objects needed for MPLS MEG information."
+      ::= { mplsOamIdGroups 1 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 29]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+   mplsOamIdMeGroup  OBJECT-GROUP
+      OBJECTS {
+         mplsOamIdMeIndexNext,
+         mplsOamIdMeMpIndexNext,
+         mplsOamIdMeName,
+         mplsOamIdMeMpIfIndex,
+         mplsOamIdMeSourceMepIndex,
+         mplsOamIdMeSinkMepIndex,
+         mplsOamIdMeMpType,
+         mplsOamIdMeMepDirection,
+         mplsOamIdMeServicePointer,
+         mplsOamIdMeRowStatus,
+         mplsOamIdMeStorageType
+      }
+      STATUS  current
+      DESCRIPTION
+            "Collection of objects needed for MPLS ME information."
+      ::= { mplsOamIdGroups 2 }
+
+   mplsOamIdNotificationObjectsGroup  OBJECT-GROUP
+      OBJECTS {
+         mplsOamIdMegOperStatus,
+         mplsOamIdMegSubOperStatus
+      }
+      STATUS  current
+      DESCRIPTION
+            "Collection of objects needed to implement notifications."
+      ::= { mplsOamIdGroups 3 }
+
+   mplsOamIdNotificationGroup NOTIFICATION-GROUP
+      NOTIFICATIONS {
+          mplsOamIdDefectCondition
+      }
+      STATUS  current
+      DESCRIPTION
+            "Set of notifications implemented in this module."
+      ::= { mplsOamIdGroups 4 }
+
+   END
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 30]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+8.  Security Considerations
+
+   This MIB relates to a system that will provide network connectivity
+   and packet forwarding services.  As such, improper manipulation of
+   the objects represented by this MIB may result in denial of service
+   to a large number of end-users.
+
+   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 opens devices to attack.
+
+   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:
+
+   - The mplsOamIdMegTable and the mplsOamIdMeTable collectively show
+     the MPLS OAM characteristics.  If an administrator does not want to
+     reveal this information, then these tables should be considered
+     sensitive/vulnerable.
+
+   SNMP versions prior to SNMPv3 did not include adequate security.
+   Even if the network itself is secure (for example by using IPsec),
+   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.
+
+   Implementations SHOULD provide the security features described by the
+   SNMPv3 framework (see [RFC3410]), and implementations claiming
+   compliance to the SNMPv3 standard MUST include full support for
+   authentication and privacy via the User-based Security Model (USM)
+   [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
+   MAY also provide support for the Transport Security Model (TSM)
+   [RFC5591] in combination with a secure transport such as SSH
+   [RFC5592] or TLS/DTLS [RFC6353].
+
+   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.
+
+
+
+Aldrin, et al.               Standards Track                   [Page 31]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+9.  IANA Considerations
+
+   As described in [RFC4221] and [RFC6639], and as requested in the
+   MPLS-TC-STD-MIB [RFC3811], MPLS-related Standards Track MIB modules
+   should be rooted under the mplsStdMIB subtree.  The following
+   subsection lists a new assignment that has been made by IANA under
+   the mplsStdMIB subtree for the MPLS-OAM-ID-STD-MIB module defined in
+   this document.  New assignments can only be made via a Standards
+   Action as specified in [RFC5226].
+
+9.1.  IANA Considerations for MPLS-OAM-ID-STD-MIB
+
+   IANA has to assign the OID { mplsStdMIB 21 } to the
+   MPLS-OAM-ID-STD-MIB module specified in this document.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
+              Schoenwaelder, Ed., "Structure of Management Information
+              Version 2 (SMIv2)", STD 58, RFC 2578,
+              DOI 10.17487/RFC2578, April 1999,
+              <http://www.rfc-editor.org/info/rfc2578>.
+
+   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
+              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
+              STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
+              <http://www.rfc-editor.org/info/rfc2579>.
+
+   [RFC2580]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
+              Schoenwaelder, Ed., "Conformance Statements for SMIv2",
+              STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
+              <http://www.rfc-editor.org/info/rfc2580>.
+
+   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+              MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
+              <http://www.rfc-editor.org/info/rfc2863>.
+
+   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+              Label Switching Architecture", RFC 3031,
+              DOI 10.17487/RFC3031, January 2001,
+              <http://www.rfc-editor.org/info/rfc3031>.
+
+
+
+Aldrin, et al.               Standards Track                   [Page 32]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+   [RFC3289]  Baker, F., Chan, K., and A. Smith, "Management Information
+              Base for the Differentiated Services Architecture",
+              RFC 3289, DOI 10.17487/RFC3289, May 2002,
+              <http://www.rfc-editor.org/info/rfc3289>.
+
+   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
+              Architecture for Describing Simple Network Management
+              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+              DOI 10.17487/RFC3411, December 2002,
+              <http://www.rfc-editor.org/info/rfc3411>.
+
+   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
+              (USM) for version 3 of the Simple Network Management
+              Protocol (SNMPv3)", STD 62, RFC 3414,
+              DOI 10.17487/RFC3414, December 2002,
+              <http://www.rfc-editor.org/info/rfc3414>.
+
+   [RFC3826]  Blumenthal, U., Maino, F., and K. McCloghrie, "The
+              Advanced Encryption Standard (AES) Cipher Algorithm in the
+              SNMP User-based Security Model", RFC 3826,
+              DOI 10.17487/RFC3826, June 2004,
+              <http://www.rfc-editor.org/info/rfc3826>.
+
+   [RFC5591]  Harrington, D. and W. Hardaker, "Transport Security Model
+              for the Simple Network Management Protocol (SNMP)",
+              STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009,
+              <http://www.rfc-editor.org/info/rfc5591>.
+
+   [RFC5592]  Harrington, D., Salowey, J., and W. Hardaker, "Secure
+              Shell Transport Model for the Simple Network Management
+              Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592,
+              June 2009, <http://www.rfc-editor.org/info/rfc5592>.
+
+   [RFC5601]  Nadeau, T., Ed., and D. Zelig, Ed., "Pseudowire (PW)
+              Management Information Base (MIB)", RFC 5601,
+              DOI 10.17487/RFC5601, July 2009,
+              <http://www.rfc-editor.org/info/rfc5601>.
+
+   [RFC6353]  Hardaker, W., "Transport Layer Security (TLS) Transport
+              Model for the Simple Network Management Protocol (SNMP)",
+              STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,
+              <http://www.rfc-editor.org/info/rfc6353>.
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 33]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+10.2.  Informative References
+
+   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
+              "Introduction and Applicability Statements for Internet-
+              Standard Management Framework", RFC 3410,
+              DOI 10.17487/RFC3410, December 2002,
+              <http://www.rfc-editor.org/info/rfc3410>.
+
+   [RFC3811]  Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of
+              Textual Conventions (TCs) for Multiprotocol Label
+              Switching (MPLS) Management", RFC 3811,
+              DOI 10.17487/RFC3811, June 2004,
+              <http://www.rfc-editor.org/info/rfc3811>.
+
+   [RFC3812]  Srinivasan, C., Viswanathan, A., and T. Nadeau,
+              "Multiprotocol Label Switching (MPLS) Traffic Engineering
+              (TE) Management Information Base (MIB)", RFC 3812,
+              DOI 10.17487/RFC3812, June 2004,
+              <http://www.rfc-editor.org/info/rfc3812>.
+
+   [RFC3813]  Srinivasan, C., Viswanathan, A., and T. Nadeau,
+              "Multiprotocol Label Switching (MPLS) Label Switching
+              Router (LSR) Management Information Base (MIB)", RFC 3813,
+              DOI 10.17487/RFC3813, June 2004,
+              <http://www.rfc-editor.org/info/rfc3813>.
+
+   [RFC4221]  Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol
+              Label Switching (MPLS) Management Overview", RFC 4221,
+              DOI 10.17487/RFC4221, November 2005,
+              <http://www.rfc-editor.org/info/rfc4221>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
+              Sprecher, N., and S. Ueno, "Requirements of an MPLS
+              Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
+              September 2009, <http://www.rfc-editor.org/info/rfc5654>.
+
+   [RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
+              "Requirements for Operations, Administration, and
+              Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
+              DOI 10.17487/RFC5860, May 2010,
+              <http://www.rfc-editor.org/info/rfc5860>.
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 34]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
+              Profile (MPLS-TP) Identifiers", RFC 6370,
+              DOI 10.17487/RFC6370, September 2011,
+              <http://www.rfc-editor.org/info/rfc6370>.
+
+   [RFC6371]  Busi, I., Ed., and D. Allan, Ed., "Operations,
+              Administration, and Maintenance Framework for MPLS-Based
+              Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
+              September 2011, <http://www.rfc-editor.org/info/rfc6371>.
+
+   [RFC6639]  King, D., Ed., and M. Venkatesan, Ed., "Multiprotocol
+              Label Switching Transport Profile (MPLS-TP) MIB-Based
+              Management Overview", RFC 6639, DOI 10.17487/RFC6639,
+              June 2012, <http://www.rfc-editor.org/info/rfc6639>.
+
+   [RFC6923]  Winter, R., Gray, E., van Helvoort, H., and M. Betts,
+              "MPLS Transport Profile (MPLS-TP) Identifiers Following
+              ITU-T Conventions", RFC 6923, DOI 10.17487/RFC6923,
+              May 2013, <http://www.rfc-editor.org/info/rfc6923>.
+
+Acknowledgments
+
+   We wish to thank Muly Ilan, Adrian Farrel, Joan Cucchiara, Weiying
+   Cheng, Mach Chen, Peter Yee, and Tina TSOU for their valuable
+   comments on this document.
+
+   The coauthors of this document, the working group chairs, the
+   document shepherd, the responsible AD, and the MPLS Working Group
+   wish to dedicate this RFC to the memory of our friend and colleague
+   Ping Pan, in recognition for his devotion and hard work at the IETF.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 35]
+
+RFC 7697                   MPLS-TP OAM ID MIB               January 2016
+
+
+Authors' Addresses
+
+   Ping Pan
+   Infinera
+
+
+   Sam Aldrin
+   Google, Inc.
+   1600 Amphitheatre Parkway
+   Mountain View, CA  94043
+   United States
+
+   Email: aldrin.ietf@gmail.com
+
+
+   Venkatesan Mahalingam
+   Dell, Inc.
+   5450 Great America Parkway
+   Santa Clara, CA  95054
+   United States
+
+   Email: venkat.mahalingams@gmail.com
+
+
+   Kannan KV Sampath
+   Redeem
+   India
+
+   Email: kannankvs@gmail.com
+
+
+   Thomas D. Nadeau
+   Brocade
+
+   Email: tnadeau@lucidvision.com
+
+
+   Sami Boutros
+   VMware, Inc.
+   3401 Hillview Ave.
+   Palo Alto, CA  94304
+   United States
+
+   Email: sboutros@vmware.com
+
+
+
+
+
+
+
+Aldrin, et al.               Standards Track                   [Page 36]
+