--- 1/draft-ietf-mpls-p2mp-te-mib-08.txt 2009-04-18 02:12:13.000000000 +0200 +++ 2/draft-ietf-mpls-p2mp-te-mib-09.txt 2009-04-18 02:12:13.000000000 +0200 @@ -1,23 +1,23 @@ Network Working Group A. Farrel (Editor) INTERNET-DRAFT Old Dog Consulting Updates: RFC3812, RFC4802 Intended Status: Standards Track S. Yasukawa -Created: March 8, 2009 NTT -Expires: September 8, 2009 +Created: April 17, 2009 NTT +Expires: October 17, 2009 T. Nadeau BT Point-to-Multipoint Multiprotocol Label Switching (MPLS) 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 This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -28,21 +28,21 @@ material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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. In particular, it describes managed objects for point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (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 equally applicable to P2MP Generalized MPLS (GMPLS) in association with the GMPLS TE MIB module defined in RFC 4802. @@ -74,30 +74,21 @@ 11.2. Informative References .................................. 59 12. Authors' Addresses ........................................... 60 13. Intellectual Property ........................................ 60 14. Disclaimer of Validity ....................................... 61 15. Full Copyright Statement ..................................... 61 0. Changes Since Previous Revision [This section to be removed before publication as an RFC.] - - Clarify how entries in the mplsXCTable are used to hold the set of - 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. + - Fix example in Step 5 of Section 5.1. - Typos. 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) traffic engineering (TE). @@ -255,21 +245,21 @@ These tables and scalars are described in the following sections 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. 4.2. Use of MPLS-TE-STD-MIB 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 basic properties of the MPLS tunnel are modeled and managed by 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. When an MPLS-TE tunnel is a P2MP tunnel, certain objects in the mplsTunnelTable have new meanings just as the signaling objects in RSVP-TE [RFC3209] have different meanings when the signaling messages are used to establish P2MP LSPs [RFC4875]. As indicated in the next section, the presence of a conceptual row in the mplsTeP2mpTunnelTable of the MIB module defined in this document shows that a tunnel defined in the corresponding conceptual row of @@ -368,34 +358,34 @@ If the tunnel is a P2MP tunnel as indicated by the presence of an entry in the mplsTeP2mpTunnelTable corresponding to this tunnel, this object is not used. This is because the destinations and paths to those destinations are found in the mplsTeP2mpTunnelDestTable. If this object is present for a P2MP tunnel, it SHOULD contain the 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 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 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 P2P LSP, and would this potentially cause damage to the implementation? 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 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 If examined by a legacy system, this object will be correctly interpreted as it continues to refer to the number of hops to any 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, and it will get the correct result from this object. mplsTunnelEgressLSRId This object reflects the value used in the signaling protocol in @@ -431,21 +421,21 @@ report zero giving the impression that no tunnel hops have been reported by the signaling protocol. This is a valid scenario and will not impact the operation of the legacy system. mplsTunnelCHopTableIndex If a P2MP tunnel is examined by a legacy system, this object will report zero giving the impression that no tunnel hops have been computed. This is a valid scenario and will not impact the 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 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 these objects, thus modifying the P2MP LSP in an unexpected way. This section lists the objects with modified semantics and explains how each is safe against write access by a legacy system. mplsTunnelMaxHops @@ -537,21 +527,21 @@ However, in a P2MP tunnel, the downstream interfaces (out-segments) may behave differently and so it is appropriate to record the performance on each out-going branch. This is achieved through the mplsTeP2mpTunnelBranchPerfTable which is indexed by the tunnel identifiers and by the same identifier of the branch as is used in mplsTeP2mpTunnelDestTable. 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 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 between the various pre-existing MPLS-TE and LSR MIB tables can be seen in [RFC4221]. An arrow in the figure shows that the MIB table pointed from contains a reference to the MIB table pointed to. mplsTunnelPerfTable @@ -812,38 +802,38 @@ mplsTunnelHopPathOptionName = "Here to there", mplsTunnelHopEntryPathComp = explicit(2), mplsTunnelHopRowStatus = createAndGo(4) } Step 5 - Create the destinations for the P2MP LSP tunnel In mplsTeP2mpTunnelDestTable define as follows: { - mplsTeP2mpTunnelDestSrcSubGroupOriginType = ipv4(1), - mplsTeP2mpTunnelDestSrcSubGroupOrigin = "192.0.2.1", - mplsTeP2mpTunnelDestSrcSubGroupID = 132, - mplsTeP2mpTunnelDestSubGroupOriginType = unknown(0), - mplsTeP2mpTunnelDestSubGroupOrigin = "", - mplsTeP2mpTunnelDestSubGroupID = 0, + mplsTeP2mpTunnelDestSrcSubGroupOriginType = unknown(0), + mplsTeP2mpTunnelDestSrcSubGroupOrigin = "", + mplsTeP2mpTunnelDestSrcSubGroupID = 0, + mplsTeP2mpTunnelDestSubGroupOriginType = ipv4(1), + mplsTeP2mpTunnelDestSubGroupOrigin = "192.0.2.1", + mplsTeP2mpTunnelDestSubGroupID = 132, mplsTeP2mpTunnelDestDestinationType = ipv4(1), mplsTeP2mpTunnelDestDestination = "192.0.2.65", mplsTeP2mpTunnelDestHopTableIndex = 1, mplsTeP2mpTunnelDestPathInUse = 1, mplsTeP2mpTunnelDestAdminStatus = up(1), mplsTeP2mpTunnelDestRowStatus = createAndGo(4) } { - mplsTeP2mpTunnelDestSrcSubGroupOriginType = ipv4(1), - mplsTeP2mpTunnelDestSrcSubGroupOrigin = "192.0.2.1", - mplsTeP2mpTunnelDestSrcSubGroupID = 132, + mplsTeP2mpTunnelDestSrcSubGroupOriginType = unknown(0), + mplsTeP2mpTunnelDestSrcSubGroupOrigin = "", + mplsTeP2mpTunnelDestSrcSubGroupID = 0, mplsTeP2mpTunnelDestSubGroupOriginType = ipv4(1), mplsTeP2mpTunnelDestSubGroupOrigin = "192.0.2.1", mplsTeP2mpTunnelDestSubGroupID = 132, mplsTeP2mpTunnelDestDestinationType = ipv4(1), mplsTeP2mpTunnelDestDestination = "192.0.2.66", mplsTeP2mpTunnelDestHopTableIndex = 2, mplsTeP2mpTunnelDestPathInUse = 1, mplsTeP2mpTunnelDestAdminStatus = up(1), mplsTeP2mpTunnelDestRowStatus = createAndGo(4) } @@ -906,23 +896,23 @@ mplsTunnelSessionAttributes = Path.SessionAttribute.Flags mplsTunnelLocalProtectInUse = Resv.RecordRoute.Flags mplsTunnelResourcePointer = points to the traffic parameter specification for this tunnel mplsTunnelPrimaryInstance = mplsTunnelInstance mplsTunnelInstancePriority = 0 mplsTunnelHopTableIndex = 0 mplsTunnelPathInUse = 0 mplsTunnelARHopTableIndex = 0 mplsTunnelCHopTableIndex = 0 - mplsTunnelIncludeAnyAffinity= Path.SeesionAttribute.IncludeAny - mplsTunnelIncludeAllAffinity= Path.SeesionAttribute.IncludeAll - mplsTunnelExcludeAnyAffinity= Path.SeesionAttribute.ExcludeAny + mplsTunnelIncludeAnyAffinity= Path.SessionAttribute.IncludeAny + mplsTunnelIncludeAllAffinity= Path.SessionAttribute.IncludeAll + mplsTunnelExcludeAnyAffinity= Path.SessionAttribute.ExcludeAny mplsTunnelTotalUpTime = time since Resv sent mplsTunnelInstanceUpTime = time since Resv sent mplsTunnelPrimaryUpTime = time since Resv sent mplsTunnelPathChanges = 0 mplsTunnelLastPathChange = time since Resv sent mplsTunnelCreationTime = time since Resv sent mplsTunnelStateTransitions = 1 mplsTunnelAdminStatus = up(1) mplsTunnelOperStatus = up(1) mplsTunnelRowStatus = active(1) @@ -1105,21 +1095,21 @@ mplsTunnelHopStorageType = volatile(2) } If the mplsTunnelCHopTable is used (and it might be used to supply information about path expansions) the contents will, for this example, be identical to the entries in the mplsTunnelHopTable since strict explicit routes were used. The mplsTunnelARHopTable is used to expose the information reported in 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 mplsTunnelARHopIndex = 1 mplsTunnelARHopAddrType = ipv4(1) mplsTunnelARHopIpAddr = "192.0.2.33" } { mplsTunnelARHopListIndex = 12 @@ -1309,21 +1299,21 @@ mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, mplsTunnelEgressLSRId FROM MPLS-TE-STD-MIB -- RFC 3812 IndexInteger, IndexIntegerNextFree FROM DIFFSERV-MIB -- RFC 3289 InetAddress, InetAddressType FROM INET-ADDRESS-MIB -- RFC 4001 ; mplsTeP2mpStdMIB MODULE-IDENTITY - LAST-UPDATED "200903060000Z" -- March 6, 2009 + LAST-UPDATED "200904170000Z" -- April 17, 2009 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Seisho Yasukawa NTT Corporation Email: s.yasukawa@hco.ntt.co.jp @@ -1359,21 +1349,21 @@ Traffic-Engineered MPLS Label Switched Paths (LSPs), S. Yasukawa, RFC 4461, April 2006. 2. Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs), Aggarwal, R., Papadimitriou, D., and Yasukawa, S., RFC 4875, May 2007." -- Revision history. REVISION - "200903060000Z" -- March 6, 2009 + "200904170000Z" -- April 17, 2009 DESCRIPTION "Initial version issued as part of RFC XXXX." -- RFC Editor. Please replace XXXX with the RFC number for this -- document and remove this note. ::= { mplsStdMIB YYY } -- RFC Editor. Please replace YYY with the codepoint issued by IANA -- and remove this note. @@ -1617,21 +1607,21 @@ This object and mplsTunnelRowStatus in the corresponding entry in mplsTunnelTable in MPLS-TE-STD-MIB should be managed together. No objects in a row in this table can be modified when the mplsTunnelRowStatus object in the corresponding row in mplsTunnelTable has value active(1). Note that no admin or oper status objects are provided in this table. The administrative and operational status of P2MP tunnels is taken from the values of mplsTunnelAdminStatus and mplsTunnelOperStatus in the - corresponding row mplsTunneltable." + corresponding row mplsTunnelTable." REFERENCE "RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004." ::= { mplsTeP2mpTunnelEntry 5 } mplsTeP2mpTunnelStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current @@ -2134,21 +2124,21 @@ } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the actual operational status of this destination of this P2MP tunnel. This object may be compared to mplsTunnelOperStatus that includes two other values: dormant(5) -- some component is missing notPresent(6) -- down due to the state of -- 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." REFERENCE "RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004." ::= { mplsTeP2mpTunnelDestEntry 22 } mplsTeP2mpTunnelDestRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create @@ -2340,21 +2330,21 @@ mplsTeP2mpTunnelDestAdminStatus, mplsTeP2mpTunnelDestOperStatus } STATUS current DESCRIPTION "This notification is generated when a mplsTeP2mpTunnelDestOperStatus object for one of the destinations of one of the configured tunnels is about to leave the down(2) state and transition into some other state. This other state is indicated by the included value - of mplsTeP2mpTunneldestOperStatus. + of mplsTeP2mpTunnelDestOperStatus. This reporting of state transitions mirrors mplsTunnelUp." REFERENCE "RFC 3812 - Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB), Srinivasan, C., Viswanathan, A., and T. Nadeau, June 2004." ::= { mplsTeP2mpNotifications 1 } mplsTeP2mpTunnelDestDown NOTIFICATION-TYPE OBJECTS { @@ -2586,22 +2575,23 @@ sensitivity/vulnerability: - The mplsTeP2mpTunnelTable and mplsTeP2mpTunnelDestTable contain objects that can be used to provision P2MP MPLS tunnels, the destinations of those tunnels, and the hops that those tunnels take through the network. Unauthorized access to objects in these tables could result in disruption of traffic in the network. This is especially true if a tunnel has already been established. The use of stronger mechanisms, such as SNMPv3 security, should be - considered where possible. Specifically, SNMPv3 VACM and USM MUST - be used with any v3 agent which implements this MIB module. + considered where possible. Specifically, the SNMPv3 View-based + 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 objects is allowed, since read access may be undesirable under certain circumstances as described below. - The use of this MIB module depends on the use of certain objects within MPLS-TE-STD-MIB defined in [RFC3812]. Note that those objects are also subject to the same security considerations, and any vulnerability to those objects could compromise the P2MP MPLS tunnels and/or data in the network. The security section of [RFC3812] MUST be applied in conjunction with this security @@ -2637,21 +2627,21 @@ does not want to reveal this information, the security section of [RFC3812] should be applied. - The objects in MPLS-LSR-STD-MIB, if implemented, may also provide information about the P2MP MPLS tunnels present at an LSR, especially the label swapping and cross-connect operations. If an Administrator does not want to reveal this information, the security section of [RFC3813] should be applied. 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 to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT @@ -2660,21 +2650,21 @@ responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to only those principals (users) that have legitimate rights to those objects. 9. Acknowledgments The authors wish to thank Tom Petch, Ben Niven-Jenkins, Markus Stenberg, and Subodh Kumar for their input to this work. Thanks to 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 review which caught a lot of issues. 10. IANA Considerations As requested in MPLS-TC-STD-MIB [RFC3811], MPLS-related standards track MIB modules should be rooted under the mplsStdMIB subtree. There is one new MPLS MIB module contained in this document, and the @@ -2786,21 +2776,21 @@ 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4769 EMail: s.yasukawa@hco.ntt.co.jp Thomas D. Nadeau BT BT Centre 81 Newgate Street EC1A 7AJ - London + London, UK Email: tom.nadeau@bt.com 13. Intellectual Property The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any