RFC 7697
MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB)
RFC 7697: MPLS-TP OAM Identifiers MIB 🦋
RFC 7697 is titled MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB). It was published in January 2016 as a Standards Track document (ISSN 2070-1721). The header doesn't list any RFCs it obsoletes or updates. 🌸
The authors are P. Pan (Infinera), S. Aldrin (Google, Inc.), M. Venkatesan (Dell, Inc.), K. Sampath (Redeem), T. Nadeau (Brocade), and S. Boutros (VMware, Inc.). The whole squad. 👑
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 ................................................36Status 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.
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.
1. Introduction 🌈
okay so this doc is basically about a chunk of the Management Information Base (MIB), which is the virtual info store that network management protocols poke at. The big focus is managed objects that let you configure OAM identifiers for Multiprotocol Label Switching (MPLS) and the MPLS-based Transport Profile (TP). It's giving "I know exactly what I'm doing" energy. 💅
This MIB module is meant for doing OAM (Operations, Administration, and Maintenance) work on MPLS Tunnel LSPs (Label Switched Paths), Pseudowires, and Sections. 🎀
Now the tea ☕: SNMP SET is no longer recommended as a way to configure MPLS networks, as described in [RFC3812]. BUT the MIB modules in this document are supposed to work alongside the MPLS MIB modules from [RFC3812], so some objects here are set to a MAX-ACCESS of read-write or read-create. That way the base tables in [RFC3812] and the new modules in this doc stay consistent. 🧚 The example in Section 6 shows how to configure OAM identifiers for MPLS-TP Tunnels, but it's really showing how the MIB values would come back in those situations if they were configured some other way. Not me getting ahead of myself. 🙈
2. The Internet-Standard Management Framework 🧠
If you want the full overview of the current Internet-Standard Management Framework, go check section 7 of RFC3410 [RFC3410]. You'll thank me later. 🫶
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB. Usually you reach them with the Simple Network Management Protocol (SNMP). The objects are defined using the Structure of Management Information (SMI) rules. This memo specifies a MIB module that's compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Structured, clean, iconic. 👑
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]. (These are the official capital-letter power words, so they get to keep their special meaning. 💜)
3.2. Terminology
This doc borrows its terminology from a whole group chat of sources: 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]. So many citations, so much respect. 🫡
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
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 in this section support the functionality described in [RFC5654] and [RFC6370]. The tables handle both IP-compatible and ICC-based OAM identifier configurations for MPLS Tunnels, LSPs, and Pseudowires. Two tables, and they're both doing a lot. 💅
5.1. mplsOamIdMegTable
The mplsOamIdMegTable manages 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 per [RFC6370] (MEG_ID for an LSP is LSP_ID, and MEG_ID for a PW is PW_Path_ID), the MEP_ID can be formed automatically. Auto-magic, no notes. 🪄
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. So for ICC-based paths, you're doing the typing yourself, bestie. ⌨️
5.2. mplsOamIdMeTable
The mplsOamIdMeTable defines a relationship between two points (source and sink) of a transport path that maintenance and monitoring operations apply to. Those two endpoints are called Maintenance Entity Group End Points (MEPs). 📍
In between the MEPs there can be zero or more intermediate points, called Maintenance Entity Group Intermediate Points (MIPs). MEPs and MIPs are associated with the MEG, and more than one ME in a MEG can share them. Sharing is caring. 🤝
6. MPLS OAM Identifier Configuration for MPLS LSP: Example 🎀
This section gives an example of OAM identifier configuration for an MPLS co-routed bidirectional LSP. Let's see it in action. 👀
The example shows how the MEG and ME tables get used to manage and monitor an MPLS LSP.
Here, the OAM identifier configuration is on a head-end LSR, which manages and monitors an MPLS LSP. Only the objects that matter for IP-based OAM identifiers of MPLS co-routed bidirectional LSPs are shown. Less is more. ✨
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)
}That creates an entry in the mplsOamIdMegTable to manage and monitor the MPLS Tunnel. Look at it go. 🚀
The following ME table associates the path information with 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)
}7. MPLS OAM Identifiers MIB Definitions 🧾
MPLS-OAM-ID-STD-MIB DEFINITIONS ::= BEGINTo be continued in part 2! 🌸
okay bestie, the actual MIB module is here 🎀💖
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
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 }
-- 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.
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 }
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 }
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 }
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 }okay so the MEG table is giving everything it's supposed to 💅 let's keep going
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 }so mplsOamIdMegServicePointerType is the "what kind of thing am I pointing at?" 🎀 field, and it has four options: tunnel (1), lsp (2), pseudowire (3), and section (4) 🦋 Each one tells you which table the service pointer in mplsOamIdMeTable lands in. tunnel goes to the point-to-point mplsTunnelTable (RFC 3812), lsp goes to the co-routed or associated bidirectional mplsTunnelTable, pseudowire goes to the pwTable (RFC 5601), and section goes back to the mplsTunnelTable (RFC 3812) 💜 The default is lsp, which is honestly the most main character choice 👑
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."
REFERENCE
"RFC 6371: Operations, Administration, and Maintenance
Framework for MPLS-Based Transport Networks,
September 2011."
DEFVAL { coRoutedBidirectionalPointToPoint }
::= { mplsOamIdMegEntry 9 }mplsOamIdMegMpLocation is all about where the MEPs/MIPs live 🌸 With perNode (1), the MEG in the LSR only supports one MEP/MIP per LSR. With perInterface (2), it supports two MEPs/MIPs in an LSR 🍓 The default is perNode, so it's the chill one 🧚
Then mplsOamIdMegPathFlow is the vibe check for the transport path itself 🌈 A unidirectionalPointToPoint (1) path gets one unidirectional ME to watch it. associatedBidirectionalPointToPoint (3) gets two independent unidirectional MEs, one for each direction. coRoutedBidirectionalPointToPoint (2) gets a single bidirectional ME that watches both directions together 🫶 And unidirectionalPointToMultiPoint (4) gets one unidirectional ME per leaf, each monitoring the path from the root to that leaf. The default is coRoutedBidirectionalPointToPoint 💖
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
is the only supported OAM application.
The bit 3 (pathDown) indicates that the underlying
LSP or PW is down."
::= { mplsOamIdMegEntry 11 }Okay, mplsOamIdMegOperStatus is the big "is this thing working?" signal 🔥 up (1) means the MEG and the path it monitors are both operationally up ✨ down (2) means the MEG is operationally down 💀 This is also what gets sent to the SNMP manager as a notification about the MEG 📣
The rule is that the sub-status is the receipts 🧾 If the status is up, all the bits in mplsOamIdMegSubOperStatus have to be cleared. If the status is down, at least one bit has to be set. No vibes-only downtime allowed 🙈
mplsOamIdMegSubOperStatus is the "why" behind the down status 😭 Bit 0 megDown means the MEG is down. Bit 1 meDown means the ME table is down. Bit 2 oamAppDown means the OAM application monitored by this MEG is down, and right now BFD is the only supported OAM application 💅 Bit 3 pathDown means the underlying LSP or PW is down 🦋
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 }
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 }mplsOamIdMegRowStatus is the handle for creating, modifying, and deleting a row in this table 🎀 Once a row is active(1), the agent can't touch any of its objects except mplsOamIdMegRowStatus 🔒
mplsOamIdMegStorageType tells you how the row's storage works 🧁 Its default is volatile. The original says that conceptual rows with the value 'permanent' don't need to allow write access to any columnar objects in the row. Fun fact: that's basically a "look, don't touch" label 👀
Now the ME table starts 🦋 mplsOamIdMeIndexNext and mplsOamIdMeMpIndexNext both hand you an unused index value for mplsOamIdMeIndex and mplsOamIdMeMpIndex respectively, or zero if none exist. Negative values are never allowed 🙅♀️ mplsOamIdMeTable is the MPLS-TP ME info table 💜 An ME is a portion of a transport path that needs management, bounded by two points called MEPs, and maintenance and monitoring operations apply to the relationship between those two points. It's generic enough to cover MEP and MIP info within a MEG ✨
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.
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
}mplsOamIdMeEntry is one MPLS-TP ME, and it only represents the ME once the source and sink MEPs are defined 🧚 An ME is point-to-point and has two MEPs, while a MEG is a group of one or more MEs and can hold two or more MEPs 💖 For a point-to-point LSP, one MEG has one ME, and that ME is linked to two MEPs (source and sink) inside the MEG. Each mplsOamIdMeIndex value picks out the ME within a MEG 🌸
The path-flow cases show up here too 🌈 A unidirectional point-to-point path gets one unidirectional ME, pointed at by mplsOamIdMeServicePointer. Associated bidirectional paths get two separate unidirectional MEs, each with its own service pointer. The original also flags a catch here: a return path from a MIP to a source MEP doesn't have to exist in the MEG, so anything that terminates at or queries a MIP has to keep that in mind 😬 Co-routed bidirectional paths get one bidirectional ME pointing at the co-routed path. Point-to-multipoint paths get one unidirectional ME per leaf, and each leaf has its own transport path info in mplsOamIdMeServicePointer ⭐ The MplsOamIdMeEntry should be created manually once the MEG is configured for OAM operations, so don't forget that step 🫶
The INDEX is mplsOamIdMegIndex, mplsOamIdMeIndex, and mplsOamIdMeMpIndex together 🔑 And the MplsOamIdMeEntry SEQUENCE lists every column this entry has: mplsOamIdMeIndex, mplsOamIdMeMpIndex, mplsOamIdMeName, mplsOamIdMeMpIfIndex, mplsOamIdMeSourceMepIndex, mplsOamIdMeSinkMepIndex, mplsOamIdMeMpType, mplsOamIdMeMepDirection, mplsOamIdMeServicePointer, mplsOamIdMeRowStatus, and mplsOamIdMeStorageType 🍓
okay so we're still deep in the MIB era 🎀 and this part is where the ME table gets its whole cast of columns. think group chat roster, where everyone has a very specific job 💅
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."
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 }
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).
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 tablesok the next bit is the notification, and it's giving alarm bell energy 🔔 this one fires whenever the operational status of the MEG changes 👀
-- 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
}
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 }and then comes the compliance section, which is basically the rulebook for who has to do what 💖 full support on one side, read-only on the other ✨
-- 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."
-- 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."
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."more MIB goodness coming up in the next part 🦋
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."
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 }
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 }
END8. Security Considerations 🔐
okay, security time, bestie 🫶 This MIB is running the show for a system that handles network connectivity and packet forwarding 💅 So if someone messes with the objects in here the wrong way, a huge number of end-users could end up with denial of service. Not a vibe 💀
A bunch of the management objects in this MIB module have a MAX-ACCESS clause of read-write and/or read-create. Those can be sensitive or vulnerable depending on the network. Honestly, the support for SET operations in a non-secure environment without proper protection opens devices up to attack, so please be careful 🙈
Some of the readable objects here (the ones with a MAX-ACCESS other than not-accessible) can also be sensitive or vulnerable in some networks. So it's important to control even GET and/or NOTIFY access to them, and to maybe even encrypt their values when they're sent over the network via SNMP 🔒 These are the tables and objects, plus how sensitive they are:
- The
mplsOamIdMegTableand themplsOamIdMeTabletogether show the MPLS OAM characteristics. If an administrator doesn't want to reveal this info, then these tables should be considered sensitive/vulnerable.
SNMP versions before SNMPv3 did not include adequate security, and that's the tea ☕ Even if the network itself is secure (for example, by using IPsec), there's no control over who on that secure network gets 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 support the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353] ✨
Further, deploying SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security 🔥 It's then a customer/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is configured properly, so that only the principals (users) with legitimate rights can GET or SET (change/create/delete) the objects. Main character energy means guarding your gate 👑
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. Ngl, that's the family tree rule 🌳 The following subsection lists a new assignment that IANA has made 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], so no shortcuts 🙅♀️
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>.
[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>.10.2. Informative References 📚✨
okay so these are the extra reads that help you understand the bigger picture 🧠 they aren't required to implement the spec but they're giving background, so bookmark them bestie 🔖
[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>.
[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 🫶
huge thank you to Muly Ilan, Adrian Farrel, Joan Cucchiara, Weiying Cheng, Mach Chen, Peter Yee, and Tina TSOU 💖 for their super valuable comments on this document, you literally made it better 🙌
the coauthors, the working group chairs, the document shepherd, the responsible AD, and the MPLS Working Group want to dedicate this RFC to the memory of our friend and colleague Ping Pan 🕊️🌸 he gave so much devotion and hard work to the IETF, and this one's for him 💜
Authors' Addresses 🎀
meet the squad 💅 here are the coauthors and where to find them
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📦 where this page comes from
- ietf: rfc7697 2016-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms