draft-ietf-mpls-p2mp-te-mib-06.txt   draft-ietf-mpls-p2mp-te-mib-07.txt 
Network Working Group A. Farrel (Editor) Network Working Group A. Farrel (Editor)
INTERNET-DRAFT Old Dog Consulting INTERNET-DRAFT Old Dog Consulting
Updates: RFC3812, RFC4802 Updates: RFC3812, RFC4802
Intended Status: Standards Track S. Yasukawa Intended Status: Standards Track S. Yasukawa
Created: February 14, 2008 NTT Created: April 30, 2008 NTT
Expires: August 24, 2008 Expires: October 30, 2008
T. Nadeau T. Nadeau
BT BT
Point-to-Multipoint Multiprotocol Label Switching (MPLS) Point-to-Multipoint Multiprotocol Label Switching (MPLS)
Traffic Engineering (TE) Management Information Base (MIB) module Traffic Engineering (TE) Management Information Base (MIB) module
draft-ietf-mpls-p2mp-te-mib-06.txt draft-ietf-mpls-p2mp-te-mib-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 9 skipping to change at page 2, line 9
The MIB module defined in this document is applicable to P2MP MPLS-TE The MIB module defined in this document is applicable to P2MP MPLS-TE
by extensions to the MPLS-TE MIB module defined in RFC 3812. It is by extensions to the MPLS-TE MIB module defined in RFC 3812. It is
equally applicable to P2MP Generalized MPLS (GMPLS) in association equally applicable to P2MP Generalized MPLS (GMPLS) in association
with the GMPLS TE MIB module defined in RFC 4802. with the GMPLS TE MIB module defined in RFC 4802.
Table of Contents Table of Contents
1. Introduction .................................................. 2 1. Introduction .................................................. 2
2. The Internet-Standard Management Framework .................... 3 2. The Internet-Standard Management Framework .................... 3
3. Feature List .................................................. 4 3. Feature List .................................................. 3
4. Outline ....................................................... 4 4. Outline ....................................................... 4
4.1. Summary of the P2MP MPLS Traffic Engineering MIB Module .. 5 4.1. Summary of the P2MP MPLS Traffic Engineering MIB Module .. 5
4.2. Use of MPLS-TE-STD-MIB ................................... 6 4.2. Use of MPLS-TE-STD-MIB ................................... 6
4.3. Scalars ................................................. 10 4.3. Scalars ................................................. 10
4.3. mplsTeP2mpTunnelTable ................................... 10 4.4. mplsTeP2mpTunnelTable ................................... 10
4.5. mplsTeP2mpTunnelDestTable ............................... 10 4.5. mplsTeP2mpTunnelDestTable ............................... 10
4.6. mplsTeP2mpTunnelBranchPerfTable ......................... 10 4.6. mplsTeP2mpTunnelBranchPerfTable ......................... 10
4.7. Relationships Between MIB Tables ........................ 11 4.7. Relationships Between MIB Tables ........................ 11
5. Using the P2MP MPLS-TE MIB Module ............................ 11 5. Using the P2MP MPLS-TE MIB Module ............................ 11
5.1. Example Use of the P2MP MPLS-TE MIB Module .............. 12 5.1. Example Use of the P2MP MPLS-TE MIB Module .............. 12
5.2. Example Transit LSR Inspection .......................... 17 5.2. Example Transit LSR Inspection .......................... 17
6. Managing P2MP MPLS-TE LSPs Through the LSR MIB Module ........ 23 6. Managing P2MP MPLS-TE LSPs Through the LSR MIB Module ........ 23
6.1. Example Use of the LSR MIB Module ....................... 24 6.1. Example Use of the LSR MIB Module ....................... 24
7. MPLS Traffic Engineering P2MP MIB Definitions ................ 27 7. MPLS Traffic Engineering P2MP MIB Definitions ................ 27
8. Security Considerations ...................................... 53 8. Security Considerations ...................................... 53
skipping to change at page 2, line 39 skipping to change at page 2, line 39
11.1. Normative References .................................... 55 11.1. Normative References .................................... 55
11.2. Informative References .................................. 56 11.2. Informative References .................................. 56
12. Authors' Addresses ........................................... 57 12. Authors' Addresses ........................................... 57
13. Intellectual Property ........................................ 57 13. Intellectual Property ........................................ 57
14. Full Copyright Statement ..................................... 58 14. Full Copyright Statement ..................................... 58
0. Changes Since Previous Revision 0. Changes Since Previous Revision
[This section to be removed before publication as an RFC.] [This section to be removed before publication as an RFC.]
- Update author coordinates - Section 4. Clarify the source-to-leaf model of P2MP LSPs.
- Expand conformance statements for read-only and read-create cases. - Section 4. Note that GMPLS P2MP LSPs must be unidirecitonal.
- Section 5.2. Clarify RSVP message exchanges in the example.
- Typos. - Typos.
- Add mplsTeP2mpScalarGroup.
1. Introduction 1. Introduction
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community. for use with network management protocols in the Internet community.
In particular, it describes managed objects for modeling In particular, it describes managed objects for modeling
point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS)
traffic engineering (TE). traffic engineering (TE).
MPLS is defined in [RFC3031] and a signaling protocol for MPLS is defined in [RFC3031] and a signaling protocol for
skipping to change at page 4, line 31 skipping to change at page 4, line 24
tunnel LSP establishment is accomplished via signaling. The MIB tunnel LSP establishment is accomplished via signaling. The MIB
module also supports manually configured tunnels, i.e., those for module also supports manually configured tunnels, i.e., those for
which label associations at each hop of the tunnel LSP are which label associations at each hop of the tunnel LSP are
provisioned by the administrator via the LSR MIB [RFC3813]. provisioned by the administrator via the LSR MIB [RFC3813].
o The MIB module supports persistent, as well as non-persistent o The MIB module supports persistent, as well as non-persistent
tunnels. tunnels.
4. Outline 4. Outline
Point-to-point MPLS-TE utilizes MPLS tunnels running from source to
destination. Each tunnel is supported by one or more label switched
paths (LSPs). This is described in the signaling specification
[RFC3209] and the document that describes the MPLS-TE MIB module
[RFC3812].
P2MP MPLS-TE requires that MPLS tunnels are established from a single P2MP MPLS-TE requires that MPLS tunnels are established from a single
source point (the root) to one or more destination points (the source point (the root) to one or more destination points (the
leaves). leaves). P2MP MPLS-TE tunnels are also supported by one or more P2MP
LSPs.
Associated with the MPLS tunnel is a set of configured parameters This document models a P2MP LSP as a set of source-to-leaf (S2L) sub-
that describe the forwarding behavior of each LSR along the path of LSPs. That is, the path (or route) from the root to each leaf is
the label switched paths (LSPs) that support the tunnel. It should separately specified for each leaf as a series of loose or strict
be noted that, according to [RFC4461] these configuration parameters hops. The combination (overlay) of the set of S2L LSPs results in the
are invariant across the branches of a P2MP LSP toward different P2MP TE LSP. See [RFC4875] for a more detailed description of S2L
leaves. LSPs and how they are combined to form a P2MP TE LSP.
One of the configuration parameters associated with an MPLS tunnel is Other configuration parameters associated with a P2MP MPLS-TE LSP
the path (or route) that supporting LSPs are required to follow. This describe the forwarding behavior of each LSR along the path of the
can be specified as a series of loose or strict hops. In P2MP TE, LSP. It should be noted that, according to [RFC4461], these
this specification of the LSP route includes implicit or explicit configuration parameters are invariant across the branches of a P2MP
identification of the branch points in the P2MP LSPs. LSP toward different leaves. Thus, they can be configured for whole
P2MP LSP, and do not need to be configured per leaf.
The setup of P2MP tunnels can be achieved as: The setup of P2MP tunnels can be achieved as:
- Management actions only, by using [RFC3813] to configure cross- - Management actions only, by using [RFC3813] to configure cross-
connections or forwarding state at the LSRs along the path of the connections or forwarding state at the LSRs along the path of the
tunnel. See Section 6 for more details. tunnel. See Section 6 for more details.
- Control plane actions (i.e., signaling using [RFC4875]) under the - Control plane actions (i.e., signaling using [RFC4875]) under the
direction of a management process, by using [RFC3812] and the MIB direction of a management process, by using [RFC3812] and the MIB
module defined in this document. module defined in this document.
skipping to change at page 5, line 20 skipping to change at page 5, line 20
management process, and monitored using [RFC3812] and the MIB management process, and monitored using [RFC3812] and the MIB
module defined in this document. module defined in this document.
Note that [RFC4802] defines a MIB module that can be used to manage Note that [RFC4802] defines a MIB module that can be used to manage
and model Generalized MPLS (GMPLS) LSPs - it is a series of MIB and model Generalized MPLS (GMPLS) LSPs - it is a series of MIB
objects and tables some of which extend tables in MPLS-TE-STD-MIB objects and tables some of which extend tables in MPLS-TE-STD-MIB
[RFC3812]. [RFC4461] and [RFC4875] are clear that they apply to [RFC3812]. [RFC4461] and [RFC4875] are clear that they apply to
MPLS-TE [RFC3031] and GMPLS [RFC3945]. This document describes a MIB MPLS-TE [RFC3031] and GMPLS [RFC3945]. This document describes a MIB
module that can be used for both MPLS-TE and GMPLS P2MP LSPs, and all module that can be used for both MPLS-TE and GMPLS P2MP LSPs, and all
objects apply to both MPLS and GMPLS. objects apply to both MPLS and GMPLS. Note, however, that GMPLS
defines support for unidirectional and bidirectional LSP, while P2MP
LSPs can only be unidirectional. Thus, the gmplsTunnelDirection
object of GMPLS-TE-STD-MIB defined in [RFC4802] MUST be set to
forward(0) when the LSP is a P2MP LSP.
The following sections describe the components of the P2MP MPLS-TE The following sections describe the components of the P2MP MPLS-TE
MIB module. The subsequent section provides an explanation and MIB module. The subsequent section provides an explanation and
example of how the P2MP MPLS-TE MIB module can be used to configure example of how the P2MP MPLS-TE MIB module can be used to configure
and manage a P2MP tunnel when used in combination with the MPLS-TE and manage a P2MP tunnel when used in combination with the MPLS-TE
MIB module defined in [RFC3812]. A further section describes how MIB module defined in [RFC3812]. A further section describes how P2MP
P2MP tunnels can be managed solely through the LSR MIB module defined tunnels can be managed solely through the LSR MIB module defined in
in [RFC3813], and gives an example. [RFC3813], and gives an example.
4.1. Summary of the P2MP MPLS Traffic Engineering MIB Module 4.1. Summary of the P2MP MPLS Traffic Engineering MIB Module
The MIB module consists of the following objects and tables: The MIB module consists of the following objects and tables:
- The P2MP Tunnel table (mplsTeP2mpTunnelTable) sparse augments the - The P2MP Tunnel table (mplsTeP2mpTunnelTable) sparse augments the
MPLS-TE Tunnel table (mplsTunnelTable) and is used to set up and MPLS-TE Tunnel table (mplsTunnelTable) and is used to set up and
monitor P2MP MPLS-TE tunnels. monitor P2MP MPLS-TE tunnels.
- The P2MP Tunnel Destination table (mplsTeP2mpTunnelDestTable) lists - The P2MP Tunnel Destination table (mplsTeP2mpTunnelDestTable) lists
skipping to change at page 6, line 25 skipping to change at page 6, line 26
mplsTunnelTable have new meanings just as the signaling objects in mplsTunnelTable have new meanings just as the signaling objects in
RSVP-TE [RFC3209] have different meanings when the signaling messages RSVP-TE [RFC3209] have different meanings when the signaling messages
are used to establish P2MP LSPs [RFC4875]. are used to establish P2MP LSPs [RFC4875].
As indicated in the next section, the presence of a conceptual row in As indicated in the next section, the presence of a conceptual row in
the mplsTeP2mpTunnelTable of the MIB module defined in this document the mplsTeP2mpTunnelTable of the MIB module defined in this document
shows that a tunnel defined in the corresponding conceptual row of shows that a tunnel defined in the corresponding conceptual row of
the mplsTunnelTable of MPLS-TE-STD-MIB is a P2MP tunnel. Under those the mplsTunnelTable of MPLS-TE-STD-MIB is a P2MP tunnel. Under those
circumstances the following scalars and objects from the appropriate circumstances the following scalars and objects from the appropriate
conceptual rows in MPLS-TE-STD-MIB MUST be interpreted as follows. conceptual rows in MPLS-TE-STD-MIB MUST be interpreted as follows.
The text below is supplementary for the Description clauses in The text below is supplementary to the Description clauses in
[RFC3812]. [RFC3812].
mplsTunnelMaxHops mplsTunnelMaxHops
This object continues to refer to the maximum number of hops that This object continues to refer to the maximum number of hops that
can be configured to a single destination for a tunnel on this can be configured to a single destination for a tunnel on this
device. Thus, for a P2MP tunnel, this refers to the maximum number device. Thus, for a P2MP tunnel, this refers to the maximum number
of hops that can be configured on this device to any individual of hops that can be configured on this device to any individual
destination of the tunnel. destination of the tunnel.
skipping to change at page 9, line 29 skipping to change at page 9, line 30
Although a legacy system may be able to read objects in the Although a legacy system may be able to read objects in the
MPLS-TE-STD-MIB which have modified semantics and operate correctly, MPLS-TE-STD-MIB which have modified semantics and operate correctly,
there is also a concern that the legacy system might try to write to there is also a concern that the legacy system might try to write to
these objects, thus modifying the P2MP LSP in an unexpected way. these objects, thus modifying the P2MP LSP in an unexpected way.
This section lists the objects with modified semantics and explains This section lists the objects with modified semantics and explains
how each is safe against write access by a legacy system. how each is safe against write access by a legacy system.
mplsTunnelMaxHops mplsTunnelMaxHops
If set by a legacy system, this object will correctly control the If set by a legacy system, this object will correctly control the
mximum number of hops in an LSP to a single destination as maximum number of hops in an LSP to a single destination as
expected by the legac system. expected by the legacy system.
mplsTunnelEgressLSRId mplsTunnelEgressLSRId
A legacy system that was used to modify this object for a P2MP A legacy system that was used to modify this object for a P2MP
tunnel would be successful and would not damage the operation of tunnel would be successful and would not damage the operation of
the P2MP tunnel. All that would happen is that the identity of the the P2MP tunnel. All that would happen is that the identity of the
tunnel would be changed. tunnel would be changed.
mplsTunnelHopTableIndex mplsTunnelHopTableIndex
If this object is set for a P2MP tunnel by a legacy system, the SET If this object is set for a P2MP tunnel by a legacy system, the SET
will be successful, but the value (i.e. the object) will be ignored will be successful, but the value (i.e. the object) will be ignored
skipping to change at page 13, line 48 skipping to change at page 13, line 48
mplsTunnelInstance = 0, mplsTunnelInstance = 0,
mplsTunnelIngressLSRId = "192.0.2.1", mplsTunnelIngressLSRId = "192.0.2.1",
-- The tunnel egress LSR ID is used to -- The tunnel egress LSR ID is used to
-- hold the P2MP ID for the P2MP LSP tunnel -- hold the P2MP ID for the P2MP LSP tunnel
mplsTunnelEgressLSRId = 328, mplsTunnelEgressLSRId = 328,
mplsTunnelName = "My first P2MP tunnel", mplsTunnelName = "My first P2MP tunnel",
mplsTunnelDescr = "Here to there and there", mplsTunnelDescr = "Here to there and there",
mplsTunnelIsIf = true(1), mplsTunnelIsIf = true(1),
-- There is no cross-connect present yet -- There is no cross-connect present yet
mplsTunnelXCPointer = 0.0, mplsTunnelXCPointer = 0.0,
-- This table entry is created by configuration no signaling -- This table entry is created by configuration not signaling
mplsTunnelSignallingProto = rsvp(2), mplsTunnelSignallingProto = rsvp(2),
mplsTunnelSetupPrio = 0, mplsTunnelSetupPrio = 0,
mplsTunnelHoldingPrio = 7, mplsTunnelHoldingPrio = 7,
mplsTunnelSessionAttributes = 0, mplsTunnelSessionAttributes = 0,
mplsTunnelLocalProtectInUse = false(2), mplsTunnelLocalProtectInUse = false(2),
mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.9, mplsTunnelResourcePointer = mplsTunnelResourceMaxRate.9,
mplsTunnelInstancePriority = 1, mplsTunnelInstancePriority = 1,
-- The index to the mplsTunnelHopTable from this table -- The index to the mplsTunnelHopTable from this table
-- is not used -- is not used
mplsTunnelHopTableIndex = 0, mplsTunnelHopTableIndex = 0,
skipping to change at page 17, line 53 skipping to change at page 17, line 53
The MIB module may also be used to monitor P2MP LSPs at transit and The MIB module may also be used to monitor P2MP LSPs at transit and
egress LSRs. Although many objects in the MIB module is writeable, as egress LSRs. Although many objects in the MIB module is writeable, as
with MPLS-TE-STD-MIB, those objects are not normally writeable except with MPLS-TE-STD-MIB, those objects are not normally writeable except
at the head end LSRs. at the head end LSRs.
This section provides a simple example of the use of the P2MP MPLS-TE This section provides a simple example of the use of the P2MP MPLS-TE
MIB module at a transit LSR where the module is used to inspect the MIB module at a transit LSR where the module is used to inspect the
LSPs. The example uses the topology shown in Figure 2 and the LSP set LSPs. The example uses the topology shown in Figure 2 and the LSP set
out in Section 5.1. Consider the situation at LSR B in the figure. out in Section 5.1. Consider the situation at LSR B in the figure.
LSR will receive a single Path message from LSR A and will send a LSR B will receive a single Path message from LSR A (or two separate
Path message onwards to LSRs C1 and C2. Similarly, LSR B will receive Path messages depending on implementation - see [RFC4875]) and will
Resv messages from LSRs C1 and C2, and will send a Resv to LSR A. send a Path message onwards to LSRs C1 and C2. Similarly, LSR B will
Once the LSP has been set up and the signaling protocol has reached a receive Resv messages from LSRs C1 and C2, and will send a Resv (or
stable state, the tables in the MPLS-TE-STD-MIB and two Resv messages according to implementation - see [RFC4875]) to LSR
A. Once the LSP has been set up and the signaling protocol has
reached a stable state, the tables in the MPLS-TE-STD-MIB and
MPLS-TE-P2MP-STD-MIB can be read as follows. MPLS-TE-P2MP-STD-MIB can be read as follows.
An entry in mplsTunnelTable provides the base information for the An entry in mplsTunnelTable provides the base information for the
P2MP tunnel. P2MP tunnel.
{ {
mplsTunnelIndex = Path.Session.TunnelID mplsTunnelIndex = Path.Session.TunnelID
mplsTunnelInstance = Path.SenderTemplate.LSP_ID mplsTunnelInstance = Path.SenderTemplate.LSP_ID
mplsTunnelIngressLSRId = Path.Session.ExtendedTunnelID mplsTunnelIngressLSRId = Path.Session.ExtendedTunnelID
mplsTunnelEgressLSRId = Path.Session.P2MPID mplsTunnelEgressLSRId = Path.Session.P2MPID
skipping to change at page 19, line 5 skipping to change at page 19, line 5
mplsTunnelPathChanges = 0 mplsTunnelPathChanges = 0
mplsTunnelLastPathChange = time since Resv sent mplsTunnelLastPathChange = time since Resv sent
mplsTunnelCreationTime = time since Resv sent mplsTunnelCreationTime = time since Resv sent
mplsTunnelStateTransitions = 1 mplsTunnelStateTransitions = 1
mplsTunnelAdminStatus = up(1) mplsTunnelAdminStatus = up(1)
mplsTunnelOperStatus = up(1) mplsTunnelOperStatus = up(1)
mplsTunnelRowStatus = active(1) mplsTunnelRowStatus = active(1)
mplsTunnelStorageType = volatile(2) mplsTunnelStorageType = volatile(2)
} }
An entry in mplsTeP2mpTunnelTable indicates that the tunnel is a P2MP An entry in mplsTeP2mpTunnelTable indicates that the tunnel is a P2MP
tunnel, and provides the parameters speicific to its P2MP nature. The tunnel, and provides the parameters specific to its P2MP nature. The
index objects (mplsTunnelIndex, mplsTunnelInstance, index objects (mplsTunnelIndex, mplsTunnelInstance,
mplsTunnelIngressLSRId, and mplsTunnelEgressLSRId) are identical in mplsTunnelIngressLSRId, and mplsTunnelEgressLSRId) are identical in
value to the entry in the mplsTunnelTable. value to the entry in the mplsTunnelTable.
{ {
mplsTeP2mpTunnelP2mpIntegrity = Path.LSPAttributes.Flags mplsTeP2mpTunnelP2mpIntegrity = Path.LSPAttributes.Flags
mplsTeP2mpTunnelBranchRole = branch(2) mplsTeP2mpTunnelBranchRole = branch(2)
mplsTeP2mpTunnelSubGroupOriginType = ipv4(1) mplsTeP2mpTunnelSubGroupOriginType = ipv4(1)
mplsTeP2mpTunnelSubGroupOrigin = Path.SenderTemplate.SubGpOrigin mplsTeP2mpTunnelSubGroupOrigin = Path.SenderTemplate.SubGpOrigin
mplsTeP2mpTunnelSubGroupID = Path.SenderTemplate.SubGpID mplsTeP2mpTunnelSubGroupID = Path.SenderTemplate.SubGpID
skipping to change at page 21, line 9 skipping to change at page 21, line 9
mplsTunnelResourceMeanBurstSize = 0 mplsTunnelResourceMeanBurstSize = 0
mplsTunnelResourceExBurstSize = 0 mplsTunnelResourceExBurstSize = 0
mplsTunnelResourceExBurstSize = unspecified(1) mplsTunnelResourceExBurstSize = unspecified(1)
mplsTunnelResourceWeight = 0 mplsTunnelResourceWeight = 0
mplsTunnelResourceRowStatus = active(1) mplsTunnelResourceRowStatus = active(1)
mplsTunnelResourceStorageType = volatile(2) mplsTunnelResourceStorageType = volatile(2)
} }
Finally, entries may also be read from the tunnel hop tables. Finally, entries may also be read from the tunnel hop tables.
mplsTunnelHopTable contains the route information received in the mplsTunnelHopTable contains the route information received in the
incoming Path message. It is spearated out to refer to the two incoming Path message. It is separated out to refer to the two
separate downstream branches, and the entries are identified by the separate downstream branches, and the entries are identified by the
corresponding values of mplsTeP2mpTunnelDestHopTableIndex. There are corresponding values of mplsTeP2mpTunnelDestHopTableIndex. There are
four hops in total in our example. four hops in total in our example.
{ {
mplsTunnelHopListIndex = 27 mplsTunnelHopListIndex = 27
mplsTunnelPathOptionIndex = 1 mplsTunnelPathOptionIndex = 1
mplsTunnelHopIndex = 1 mplsTunnelHopIndex = 1
mplsTunnelHopAddrType = ipv4(1) mplsTunnelHopAddrType = ipv4(1)
mplsTunnelHopIpAddr = "192.0.2.33" mplsTunnelHopIpAddr = "192.0.2.33"
skipping to change at page 27, line 34 skipping to change at page 27, line 34
mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId,
mplsTunnelEgressLSRId mplsTunnelEgressLSRId
FROM MPLS-TE-STD-MIB -- RFC 3812 FROM MPLS-TE-STD-MIB -- RFC 3812
IndexInteger, IndexIntegerNextFree IndexInteger, IndexIntegerNextFree
FROM DIFFSERV-MIB -- RFC 3289 FROM DIFFSERV-MIB -- RFC 3289
InetAddress, InetAddressType InetAddress, InetAddressType
FROM INET-ADDRESS-MIB -- RFC 4001 FROM INET-ADDRESS-MIB -- RFC 4001
; ;
mplsTeP2mpStdMIB MODULE-IDENTITY mplsTeP2mpStdMIB MODULE-IDENTITY
LAST-UPDATED "200802140000Z" -- February 14, 2008 LAST-UPDATED "200804300000Z" -- April 30, 2008
ORGANIZATION ORGANIZATION
"Multiprotocol Label Switching (MPLS) Working Group" "Multiprotocol Label Switching (MPLS) Working Group"
CONTACT-INFO CONTACT-INFO
" Adrian Farrel " Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
Email: s.yasukawa@hco.ntt.co.jp Email: s.yasukawa@hco.ntt.co.jp
skipping to change at page 28, line 26 skipping to change at page 28, line 26
Traffic-Engineered MPLS Label Switched Paths (LSPs), Traffic-Engineered MPLS Label Switched Paths (LSPs),
S. Yasukawa, RFC 4461, April 2006. S. Yasukawa, RFC 4461, April 2006.
2. Extensions to Resource Reservation Protocol - Traffic 2. Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs), Aggarwal, R., Papadimitriou, D., Switched Paths (LSPs), Aggarwal, R., Papadimitriou, D.,
and Yasukawa, S., RFC 4875, May 2007." and Yasukawa, S., RFC 4875, May 2007."
-- Revision history. -- Revision history.
REVISION REVISION
"200802140000Z" -- February 14, 2008 "200804300000Z" -- April 30, 2008
DESCRIPTION DESCRIPTION
"Initial version issued as part of RFC XXXX." "Initial version issued as part of RFC XXXX."
-- RFC Editor. Please replace XXXX with the RFC number for this -- RFC Editor. Please replace XXXX with the RFC number for this
-- document and remove this note. -- document and remove this note.
::= { mplsStdMIB YYY } ::= { mplsStdMIB YYY }
-- RFC Editor. Please replace YYY with the codepoint issued by IANA -- RFC Editor. Please replace YYY with the codepoint issued by IANA
-- and remove this note. -- and remove this note.
skipping to change at page 54, line 30 skipping to change at page 54, line 30
[RFC3812] should be applied. [RFC3812] should be applied.
- The objects in MPLS-LSR-STD-MIB, if implemented, may also provide - The objects in MPLS-LSR-STD-MIB, if implemented, may also provide
information about the P2MP MPLS tunnels present at an LSR, information about the P2MP MPLS tunnels present at an LSR,
especially the label swapping and cross-connect operations. If an especially the label swapping and cross-connect operations. If an
Administrator does not want to reveal this information, the Administrator does not want to reveal this information, the
security section of [RFC3813] should be applied. security section of [RFC3813] should be applied.
SNMP versions prior to SNMPv3 did not include adequate security. SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec), Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is there is still no control as to who on the secure network is allowed
allowed to access and GET/SET (read/change/create/delete) the objects to access and GET/SET (read/change/create/delete) the objects in this
in this MIB module. MIB module.
It is RECOMMENDED that implementers consider the security features as It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8), provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy). authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED that SNMPv3 be deployed and RECOMMENDED. Instead, it is RECOMMENDED that SNMPv3 be deployed and
cryptographic security enabled. It is then a customer/operator cryptographic security enabled. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an responsibility to ensure that the SNMP entity giving access to an
skipping to change at page 56, line 39 skipping to change at page 56, line 39
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching "Multiprotocol Label Switching (MPLS) Label Switching
(LSR) Router Management Information Base (MIB)", RFC 3813, (LSR) Router Management Information Base (MIB)", RFC 3813,
June 2004. June 2004.
[RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label [RFC3945] Mannie, E., Ed., "Generalized Multiprotocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004. Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "TextualConventions for Internet Network Schoenwaelder, "TextualConventions for Internet Network
Addresses", RFC 3291, May 2002. Addresses", RFC 4001, February 2005.
[RFC4461] S. Yasukawa, Editor "Signaling Requirements for
Point-to-Multipoint Traffic Engineered MPLS LSPs",
RFC 4461, April 2006.
[RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S.,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
11.2. Informative References 11.2. Informative References
[RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statement for Internet "Introduction and Applicability Statement for Internet
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol
Label Switching (MPLS) Management Overview", RFC 4221, Label Switching (MPLS) Management Overview", RFC 4221,
November 2005. November 2005.
[RFC4461] S. Yasukawa, Editor "Signaling Requirements for
Point-to-Multipoint Traffic Engineered MPLS LSPs",
RFC 4461, April 2006.
[RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol [RFC4802] Nadeau, T. and A. Farrel, "Generalized Multiprotocol
Label Switching (GMPLS) Traffic Engineering Management Label Switching (GMPLS) Traffic Engineering Management
Information Base", RFC 4802, February 2007. Information Base", RFC 4802, February 2007.
[RFC4803] Nadeau, T. and A. Farrel, "Generalized Multiprotocol [RFC4803] Nadeau, T. and A. Farrel, "Generalized Multiprotocol
Label Switching (GMPLS) Label Switching Router (LSR) Label Switching (GMPLS) Label Switching Router (LSR)
Management Information Base", RFC 4803, February 2007. Management Information Base", RFC 4803, February 2007.
12. Authors' Addresses 12. Authors' Addresses
 End of changes. 23 change blocks. 
45 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/