draft-ietf-mpls-p2mp-te-mib-08.txt   draft-ietf-mpls-p2mp-te-mib-09.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: March 8, 2009 NTT Created: April 17, 2009 NTT
Expires: September 8, 2009 Expires: October 17, 2009
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-08.txt draft-ietf-mpls-p2mp-te-mib-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and 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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This memo defines a portion of the Management Information Base 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 point-to-multipoint In particular, it describes managed objects for point-to-multipoint
(P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering
(TE). (TE).
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.
skipping to change at page 2, line 40 skipping to change at page 2, line 40
11.2. Informative References .................................. 59 11.2. Informative References .................................. 59
12. Authors' Addresses ........................................... 60 12. Authors' Addresses ........................................... 60
13. Intellectual Property ........................................ 60 13. Intellectual Property ........................................ 60
14. Disclaimer of Validity ....................................... 61 14. Disclaimer of Validity ....................................... 61
15. Full Copyright Statement ..................................... 61 15. Full Copyright Statement ..................................... 61
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.]
- Clarify how entries in the mplsXCTable are used to hold the set of - Fix example in Step 5 of Section 5.1.
XC definitions for one P2MP LSP, and add an index pointer from
mplsTeP2mpTunnelTable into mplsXCTable. Affects Sections 4.2,
4.2.1, 4.2.2, 4.7, 5.1, 5.2, 6.1, and 7. The new index pointer is
called mplsTeP2mpTunnelP2mpXcIndex.
- Make it possible for a single P2MP tunnel instance (LSP ID) to
have more than one sub-group ID received from upstream. Make the
subgroup ID an index to mplsTeP2mpTunnelDestTable.
- Move source sub-group objects from mplsTeP2mpTunnelTable to
mplsTeP2mpTunnelDestTable and make them indexes.
- Typos. - Typos.
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).
skipping to change at page 6, line 27 skipping to change at page 6, line 26
These tables and scalars are described in the following sections These tables and scalars are described in the following sections
after a description of how the MPLS-TE-STD-MIB module [RFC3812] is after a description of how the MPLS-TE-STD-MIB module [RFC3812] is
used as a basis for MIB management and modeling of P2MP MPLS-TE. used as a basis for MIB management and modeling of P2MP MPLS-TE.
4.2. Use of MPLS-TE-STD-MIB 4.2. Use of MPLS-TE-STD-MIB
The MIB module defined in this document builds on the objects and The MIB module defined in this document builds on the objects and
tables of MPLS-TE-STD-MIB defined in [RFC3812]. That is, most of the tables of MPLS-TE-STD-MIB defined in [RFC3812]. That is, most of the
basic properties of the MPLS tunnel are modeled and managed by basic properties of the MPLS tunnel are modeled and managed by
objects in MPLS-TE-STD-MIB, and new objects are only defined within objects in MPLS-TE-STD-MIB, and new objects are only defined within
this document where additional features or different behavior is this document where additional features or different behavior are
required. required.
When an MPLS-TE tunnel is a P2MP tunnel, certain objects in the When an MPLS-TE tunnel is a P2MP tunnel, certain objects in the
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
skipping to change at page 8, line 44 skipping to change at page 8, line 44
If the tunnel is a P2MP tunnel as indicated by the presence of an If the tunnel is a P2MP tunnel as indicated by the presence of an
entry in the mplsTeP2mpTunnelTable corresponding to this tunnel, entry in the mplsTeP2mpTunnelTable corresponding to this tunnel,
this object is not used. This is because the destinations and this object is not used. This is because the destinations and
paths to those destinations are found in the paths to those destinations are found in the
mplsTeP2mpTunnelDestTable. mplsTeP2mpTunnelDestTable.
If this object is present for a P2MP tunnel, it SHOULD contain the If this object is present for a P2MP tunnel, it SHOULD contain the
value 0. value 0.
4.2.1. Backward Compatiblity Concerns for MIB Read Operations 4.2.1. Backward Compatibility Concerns for MIB Read Operations
A concern may be raised with regard to the changed semantics of the A concern may be raised with regard to the changed semantics of the
objects listed in Section 4.2 within the MPLS-TE-STD-MIB module. What objects listed in Section 4.2 within the MPLS-TE-STD-MIB module. What
would happen if an implementation that was not P2MP-aware attempted would happen if an implementation that was not P2MP-aware attempted
to read from the MPLS-TE-STD-MIB module and encountered these objects to read from the MPLS-TE-STD-MIB module and encountered these objects
with changed semantics? Would it attempt to handle a P2MP LSP as a with changed semantics? Would it attempt to handle a P2MP LSP as a
P2P LSP, and would this potentially cause damage to the P2P LSP, and would this potentially cause damage to the
implementation? implementation?
To clarify the situation, each of the objects with modified semantics To clarify the situation, each of the objects with modified semantics
is set out below. The term 'legacy system' is used to refer to a is set out below. The term 'legacy system' is used to refer to a
management station that is not aware of the P2MP-TE-STD-MIB and is management station that is not aware of the P2MP-TE-STD-MIB and is
not aware of the modified sematics of these objects. not aware of the modified semantics of these objects.
mplsTunnelMaxHops mplsTunnelMaxHops
If examined by a legacy system, this object will be correctly If examined by a legacy system, this object will be correctly
interpreted as it continues to refer to the number of hops to any interpreted as it continues to refer to the number of hops to any
single destination. A legacy system will look to this object to single destination. A legacy system will look to this object to
determine how many hops it may insert into the path of a P2P LSP, determine how many hops it may insert into the path of a P2P LSP,
and it will get the correct result from this object. and it will get the correct result from this object.
mplsTunnelEgressLSRId mplsTunnelEgressLSRId
This object reflects the value used in the signaling protocol in This object reflects the value used in the signaling protocol in
skipping to change at page 10, line 11 skipping to change at page 10, line 11
report zero giving the impression that no tunnel hops have been report zero giving the impression that no tunnel hops have been
reported by the signaling protocol. This is a valid scenario and reported by the signaling protocol. This is a valid scenario and
will not impact the operation of the legacy system. will not impact the operation of the legacy system.
mplsTunnelCHopTableIndex mplsTunnelCHopTableIndex
If a P2MP tunnel is examined by a legacy system, this object will If a P2MP tunnel is examined by a legacy system, this object will
report zero giving the impression that no tunnel hops have been report zero giving the impression that no tunnel hops have been
computed. This is a valid scenario and will not impact the computed. This is a valid scenario and will not impact the
operation of the legacy system. operation of the legacy system.
4.2.2. Backward Compatiblity Concerns for MIB Write Operations 4.2.2. Backward Compatibility Concerns for MIB Write Operations
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
skipping to change at page 12, line 20 skipping to change at page 12, line 20
However, in a P2MP tunnel, the downstream interfaces (out-segments) However, in a P2MP tunnel, the downstream interfaces (out-segments)
may behave differently and so it is appropriate to record the may behave differently and so it is appropriate to record the
performance on each out-going branch. This is achieved through the performance on each out-going branch. This is achieved through the
mplsTeP2mpTunnelBranchPerfTable which is indexed by the tunnel mplsTeP2mpTunnelBranchPerfTable which is indexed by the tunnel
identifiers and by the same identifier of the branch as is used in identifiers and by the same identifier of the branch as is used in
mplsTeP2mpTunnelDestTable. mplsTeP2mpTunnelDestTable.
4.7. Relationships Between MIB Tables 4.7. Relationships Between MIB Tables
This section provides a diagramatic representation of the This section provides a diagrammatic representation of the
relationships between MIB tables defined in this document as part of relationships between MIB tables defined in this document as part of
MPLS-TE-P2MP-STD-MIB, and the tables defined in MPLS-TE-STD-MIB in MPLS-TE-P2MP-STD-MIB, and the tables defined in MPLS-TE-STD-MIB in
[RFC3812] and MPLS-LSR-STD-MIB in [RFC3813]. The dependencies [RFC3812] and MPLS-LSR-STD-MIB in [RFC3813]. The dependencies
between the various pre-existing MPLS-TE and LSR MIB tables can be between the various pre-existing MPLS-TE and LSR MIB tables can be
seen in [RFC4221]. seen in [RFC4221].
An arrow in the figure shows that the MIB table pointed from contains An arrow in the figure shows that the MIB table pointed from contains
a reference to the MIB table pointed to. a reference to the MIB table pointed to.
mplsTunnelPerfTable mplsTunnelPerfTable
skipping to change at page 18, line 17 skipping to change at page 18, line 17
mplsTunnelHopPathOptionName = "Here to there", mplsTunnelHopPathOptionName = "Here to there",
mplsTunnelHopEntryPathComp = explicit(2), mplsTunnelHopEntryPathComp = explicit(2),
mplsTunnelHopRowStatus = createAndGo(4) mplsTunnelHopRowStatus = createAndGo(4)
} }
Step 5 - Create the destinations for the P2MP LSP tunnel Step 5 - Create the destinations for the P2MP LSP tunnel
In mplsTeP2mpTunnelDestTable define as follows: In mplsTeP2mpTunnelDestTable define as follows:
{ {
mplsTeP2mpTunnelDestSrcSubGroupOriginType = ipv4(1), mplsTeP2mpTunnelDestSrcSubGroupOriginType = unknown(0),
mplsTeP2mpTunnelDestSrcSubGroupOrigin = "192.0.2.1", mplsTeP2mpTunnelDestSrcSubGroupOrigin = "",
mplsTeP2mpTunnelDestSrcSubGroupID = 132, mplsTeP2mpTunnelDestSrcSubGroupID = 0,
mplsTeP2mpTunnelDestSubGroupOriginType = unknown(0), mplsTeP2mpTunnelDestSubGroupOriginType = ipv4(1),
mplsTeP2mpTunnelDestSubGroupOrigin = "", mplsTeP2mpTunnelDestSubGroupOrigin = "192.0.2.1",
mplsTeP2mpTunnelDestSubGroupID = 0, mplsTeP2mpTunnelDestSubGroupID = 132,
mplsTeP2mpTunnelDestDestinationType = ipv4(1), mplsTeP2mpTunnelDestDestinationType = ipv4(1),
mplsTeP2mpTunnelDestDestination = "192.0.2.65", mplsTeP2mpTunnelDestDestination = "192.0.2.65",
mplsTeP2mpTunnelDestHopTableIndex = 1, mplsTeP2mpTunnelDestHopTableIndex = 1,
mplsTeP2mpTunnelDestPathInUse = 1, mplsTeP2mpTunnelDestPathInUse = 1,
mplsTeP2mpTunnelDestAdminStatus = up(1), mplsTeP2mpTunnelDestAdminStatus = up(1),
mplsTeP2mpTunnelDestRowStatus = createAndGo(4) mplsTeP2mpTunnelDestRowStatus = createAndGo(4)
} }
{ {
mplsTeP2mpTunnelDestSrcSubGroupOriginType = ipv4(1), mplsTeP2mpTunnelDestSrcSubGroupOriginType = unknown(0),
mplsTeP2mpTunnelDestSrcSubGroupOrigin = "192.0.2.1", mplsTeP2mpTunnelDestSrcSubGroupOrigin = "",
mplsTeP2mpTunnelDestSrcSubGroupID = 132, mplsTeP2mpTunnelDestSrcSubGroupID = 0,
mplsTeP2mpTunnelDestSubGroupOriginType = ipv4(1), mplsTeP2mpTunnelDestSubGroupOriginType = ipv4(1),
mplsTeP2mpTunnelDestSubGroupOrigin = "192.0.2.1", mplsTeP2mpTunnelDestSubGroupOrigin = "192.0.2.1",
mplsTeP2mpTunnelDestSubGroupID = 132, mplsTeP2mpTunnelDestSubGroupID = 132,
mplsTeP2mpTunnelDestDestinationType = ipv4(1), mplsTeP2mpTunnelDestDestinationType = ipv4(1),
mplsTeP2mpTunnelDestDestination = "192.0.2.66", mplsTeP2mpTunnelDestDestination = "192.0.2.66",
mplsTeP2mpTunnelDestHopTableIndex = 2, mplsTeP2mpTunnelDestHopTableIndex = 2,
mplsTeP2mpTunnelDestPathInUse = 1, mplsTeP2mpTunnelDestPathInUse = 1,
mplsTeP2mpTunnelDestAdminStatus = up(1), mplsTeP2mpTunnelDestAdminStatus = up(1),
mplsTeP2mpTunnelDestRowStatus = createAndGo(4) mplsTeP2mpTunnelDestRowStatus = createAndGo(4)
} }
skipping to change at page 20, line 22 skipping to change at page 20, line 22
mplsTunnelSessionAttributes = Path.SessionAttribute.Flags mplsTunnelSessionAttributes = Path.SessionAttribute.Flags
mplsTunnelLocalProtectInUse = Resv.RecordRoute.Flags mplsTunnelLocalProtectInUse = Resv.RecordRoute.Flags
mplsTunnelResourcePointer = points to the traffic parameter mplsTunnelResourcePointer = points to the traffic parameter
specification for this tunnel specification for this tunnel
mplsTunnelPrimaryInstance = mplsTunnelInstance mplsTunnelPrimaryInstance = mplsTunnelInstance
mplsTunnelInstancePriority = 0 mplsTunnelInstancePriority = 0
mplsTunnelHopTableIndex = 0 mplsTunnelHopTableIndex = 0
mplsTunnelPathInUse = 0 mplsTunnelPathInUse = 0
mplsTunnelARHopTableIndex = 0 mplsTunnelARHopTableIndex = 0
mplsTunnelCHopTableIndex = 0 mplsTunnelCHopTableIndex = 0
mplsTunnelIncludeAnyAffinity= Path.SeesionAttribute.IncludeAny mplsTunnelIncludeAnyAffinity= Path.SessionAttribute.IncludeAny
mplsTunnelIncludeAllAffinity= Path.SeesionAttribute.IncludeAll mplsTunnelIncludeAllAffinity= Path.SessionAttribute.IncludeAll
mplsTunnelExcludeAnyAffinity= Path.SeesionAttribute.ExcludeAny mplsTunnelExcludeAnyAffinity= Path.SessionAttribute.ExcludeAny
mplsTunnelTotalUpTime = time since Resv sent mplsTunnelTotalUpTime = time since Resv sent
mplsTunnelInstanceUpTime = time since Resv sent mplsTunnelInstanceUpTime = time since Resv sent
mplsTunnelPrimaryUpTime = time since Resv sent mplsTunnelPrimaryUpTime = time since Resv sent
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)
skipping to change at page 24, line 36 skipping to change at page 24, line 36
mplsTunnelHopStorageType = volatile(2) mplsTunnelHopStorageType = volatile(2)
} }
If the mplsTunnelCHopTable is used (and it might be used to supply If the mplsTunnelCHopTable is used (and it might be used to supply
information about path expansions) the contents will, for this information about path expansions) the contents will, for this
example, be identical to the entries in the mplsTunnelHopTable example, be identical to the entries in the mplsTunnelHopTable
since strict explicit routes were used. since strict explicit routes were used.
The mplsTunnelARHopTable is used to expose the information reported in The mplsTunnelARHopTable is used to expose the information reported in
the Record Route object carried in the Resv message. In this example, the Record Route object carried in the Resv message. In this example,
thre would also be four entries as shown below. there would also be four entries as shown below.
{ {
mplsTunnelARHopListIndex = 12 mplsTunnelARHopListIndex = 12
mplsTunnelARHopIndex = 1 mplsTunnelARHopIndex = 1
mplsTunnelARHopAddrType = ipv4(1) mplsTunnelARHopAddrType = ipv4(1)
mplsTunnelARHopIpAddr = "192.0.2.33" mplsTunnelARHopIpAddr = "192.0.2.33"
} }
{ {
mplsTunnelARHopListIndex = 12 mplsTunnelARHopListIndex = 12
skipping to change at page 29, line 34 skipping to change at page 29, 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 "200903060000Z" -- March 6, 2009 LAST-UPDATED "200904170000Z" -- April 17, 2009
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 30, line 35 skipping to change at page 30, line 35
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
"200903060000Z" -- March 6, 2009 "200904170000Z" -- April 17, 2009
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 36, line 15 skipping to change at page 36, line 15
This object and mplsTunnelRowStatus in the corresponding This object and mplsTunnelRowStatus in the corresponding
entry in mplsTunnelTable in MPLS-TE-STD-MIB should be entry in mplsTunnelTable in MPLS-TE-STD-MIB should be
managed together. No objects in a row in this table can be managed together. No objects in a row in this table can be
modified when the mplsTunnelRowStatus object in the modified when the mplsTunnelRowStatus object in the
corresponding row in mplsTunnelTable has value active(1). corresponding row in mplsTunnelTable has value active(1).
Note that no admin or oper status objects are provided in Note that no admin or oper status objects are provided in
this table. The administrative and operational status of this table. The administrative and operational status of
P2MP tunnels is taken from the values of P2MP tunnels is taken from the values of
mplsTunnelAdminStatus and mplsTunnelOperStatus in the mplsTunnelAdminStatus and mplsTunnelOperStatus in the
corresponding row mplsTunneltable." corresponding row mplsTunnelTable."
REFERENCE REFERENCE
"RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic "RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB), Engineering (TE) Management Information Base (MIB),
Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004." Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004."
::= { mplsTeP2mpTunnelEntry 5 } ::= { mplsTeP2mpTunnelEntry 5 }
mplsTeP2mpTunnelStorageType OBJECT-TYPE mplsTeP2mpTunnelStorageType OBJECT-TYPE
SYNTAX StorageType SYNTAX StorageType
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
skipping to change at page 47, line 6 skipping to change at page 47, line 6
} }
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Indicates the actual operational status of this destination "Indicates the actual operational status of this destination
of this P2MP tunnel. This object may be compared to of this P2MP tunnel. This object may be compared to
mplsTunnelOperStatus that includes two other values: mplsTunnelOperStatus that includes two other values:
dormant(5) -- some component is missing dormant(5) -- some component is missing
notPresent(6) -- down due to the state of notPresent(6) -- down due to the state of
-- lower layer interfaces. -- lower layer interfaces.
These states do not aply to an individual destinaton of a These states do not apply to an individual destination of a
P2MP MPLS-TE LSP and so are not included in this object." P2MP MPLS-TE LSP and so are not included in this object."
REFERENCE REFERENCE
"RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic "RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB), Engineering (TE) Management Information Base (MIB),
Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004." Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004."
::= { mplsTeP2mpTunnelDestEntry 22 } ::= { mplsTeP2mpTunnelDestEntry 22 }
mplsTeP2mpTunnelDestRowStatus OBJECT-TYPE mplsTeP2mpTunnelDestRowStatus OBJECT-TYPE
SYNTAX RowStatus SYNTAX RowStatus
MAX-ACCESS read-create MAX-ACCESS read-create
skipping to change at page 51, line 19 skipping to change at page 51, line 19
mplsTeP2mpTunnelDestAdminStatus, mplsTeP2mpTunnelDestAdminStatus,
mplsTeP2mpTunnelDestOperStatus mplsTeP2mpTunnelDestOperStatus
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This notification is generated when a "This notification is generated when a
mplsTeP2mpTunnelDestOperStatus object for one of the mplsTeP2mpTunnelDestOperStatus object for one of the
destinations of one of the configured tunnels is about to destinations of one of the configured tunnels is about to
leave the down(2) state and transition into some other leave the down(2) state and transition into some other
state. This other state is indicated by the included value state. This other state is indicated by the included value
of mplsTeP2mpTunneldestOperStatus. of mplsTeP2mpTunnelDestOperStatus.
This reporting of state transitions mirrors mplsTunnelUp." This reporting of state transitions mirrors mplsTunnelUp."
REFERENCE REFERENCE
"RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic "RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB), Engineering (TE) Management Information Base (MIB),
Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004." Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004."
::= { mplsTeP2mpNotifications 1 } ::= { mplsTeP2mpNotifications 1 }
mplsTeP2mpTunnelDestDown NOTIFICATION-TYPE mplsTeP2mpTunnelDestDown NOTIFICATION-TYPE
OBJECTS { OBJECTS {
skipping to change at page 56, line 29 skipping to change at page 56, line 29
sensitivity/vulnerability: sensitivity/vulnerability:
- The mplsTeP2mpTunnelTable and mplsTeP2mpTunnelDestTable contain - The mplsTeP2mpTunnelTable and mplsTeP2mpTunnelDestTable contain
objects that can be used to provision P2MP MPLS tunnels, the objects that can be used to provision P2MP MPLS tunnels, the
destinations of those tunnels, and the hops that those tunnels take destinations of those tunnels, and the hops that those tunnels take
through the network. Unauthorized access to objects in these tables through the network. Unauthorized access to objects in these tables
could result in disruption of traffic in the network. This is could result in disruption of traffic in the network. This is
especially true if a tunnel has already been established. especially true if a tunnel has already been established.
The use of stronger mechanisms, such as SNMPv3 security, should be The use of stronger mechanisms, such as SNMPv3 security, should be
considered where possible. Specifically, SNMPv3 VACM and USM MUST considered where possible. Specifically, the SNMPv3 View-based
be used with any v3 agent which implements this MIB module. Access Control Model (VACM) and User-based Security Model (USM)
MUST be used with any v3 agent which implements this MIB module.
Administrators SHOULD also consider whether read access to these Administrators SHOULD also consider whether read access to these
objects is allowed, since read access may be undesirable under objects is allowed, since read access may be undesirable under
certain circumstances as described below. certain circumstances as described below.
- The use of this MIB module depends on the use of certain objects - The use of this MIB module depends on the use of certain objects
within MPLS-TE-STD-MIB defined in [RFC3812]. Note that those within MPLS-TE-STD-MIB defined in [RFC3812]. Note that those
objects are also subject to the same security considerations, and objects are also subject to the same security considerations, and
any vulnerability to those objects could compromise the P2MP MPLS any vulnerability to those objects could compromise the P2MP MPLS
tunnels and/or data in the network. The security section of tunnels and/or data in the network. The security section of
[RFC3812] MUST be applied in conjunction with this security [RFC3812] MUST be applied in conjunction with this security
skipping to change at page 57, line 31 skipping to change at page 57, line 32
does not want to reveal this information, the security section of does not want to reveal this information, the security section of
[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),
there is still no control as to who on the secure network is allowed there is still no control as to who on the secure network is allowed
to access and GET/SET (read/change/create/delete) the objects in this to access and GET/SET (read/change/create/delete) the objects 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
skipping to change at page 58, line 10 skipping to change at page 58, line 10
responsibility to ensure that the SNMP entity giving access to an responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to instance of this MIB module is properly configured to give access to
only those principals (users) that have legitimate rights to those only those principals (users) that have legitimate rights to those
objects. objects.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Tom Petch, Ben Niven-Jenkins, Markus The authors wish to thank Tom Petch, Ben Niven-Jenkins, Markus
Stenberg, and Subodh Kumar for their input to this work. Thanks to Stenberg, and Subodh Kumar for their input to this work. Thanks to
Zafar Ali for discussions. Nic Neate provided very many helpful Zafar Ali for discussions. Nic Neate provided very many helpful
suggestions. suggestions. Thanks to Francis Dupont for a detailed GenArt review.
Joan Cucchiara provided a very thorough and helpful early MIB Doctor Joan Cucchiara provided a very thorough and helpful early MIB Doctor
review which caught a lot of issues. review which caught a lot of issues.
10. IANA Considerations 10. IANA Considerations
As requested in MPLS-TC-STD-MIB [RFC3811], MPLS-related standards As requested in MPLS-TC-STD-MIB [RFC3811], MPLS-related standards
track MIB modules should be rooted under the mplsStdMIB subtree. track MIB modules should be rooted under the mplsStdMIB subtree.
There is one new MPLS MIB module contained in this document, and the There is one new MPLS MIB module contained in this document, and the
skipping to change at page 60, line 43 skipping to change at page 60, line 43
9-11, Midori-Cho 3-Chome 9-11, Midori-Cho 3-Chome
Musashino-Shi, Tokyo 180-8585 Japan Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 4769 Phone: +81 422 59 4769
EMail: s.yasukawa@hco.ntt.co.jp EMail: s.yasukawa@hco.ntt.co.jp
Thomas D. Nadeau Thomas D. Nadeau
BT BT
BT Centre BT Centre
81 Newgate Street 81 Newgate Street
EC1A 7AJ EC1A 7AJ
London London, UK
Email: tom.nadeau@bt.com Email: tom.nadeau@bt.com
13. Intellectual Property 13. Intellectual Property
The IETF Trust takes no position regarding the validity or scope of The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
 End of changes. 22 change blocks. 
42 lines changed or deleted 34 lines changed or added

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