--- 1/draft-ietf-mpls-tp-te-mib-00.txt 2011-12-16 00:13:57.434671088 +0100 +++ 2/draft-ietf-mpls-tp-te-mib-01.txt 2011-12-16 00:13:57.494672004 +0100 @@ -1,24 +1,24 @@ Network Working Group INTERNET-DRAFT M.Venkatesan Intended Status: Standards Track Kannan KV Sampath -Expires: December 17, 2011 Aricent +Expires: June 15, 2012 Aricent Sam K. Aldrin Huawei Technologies Thomas D. Nadeau CA Technologies - June 17, 2011 + December 15, 2011 MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) - draft-ietf-mpls-tp-te-mib-00.txt + draft-ietf-mpls-tp-te-mib-01.txt Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects of Tunnels, Identifiers, Label Switch Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). Status of this Memo @@ -35,21 +35,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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. - This Internet-Draft will expire on December 17, 2011. + This Internet-Draft will expire on June 15, 2012. Copyright and License Notice Copyright (c) 2011 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 @@ -195,25 +195,25 @@ with upper case letters. In the IP compatible mode, Global_Node_ID, is used to uniquely identify a node. Each ICC or Global_Node_ID contains one unique entry in the table representing a node. Every node is assigned a local identifier within a range of 0 to 16777215. This local identifier is used for indexing into mplsTunnelTable as mplsTunnelIngressLSRId and mplsTunnelEgressLSRId. For IP compatible environment, MPLS-TP tunnel is indexed by Tunnel - Index, Tunnel Instance, Source Global_ID, Source Node_ID, - Destination Global_ID and Destination Node_ID. + Index, Tunnel Instance, Source Global_ID, Source Node_ID, Destination + Global_ID and Destination Node_ID. - For ICC based environment, MPLS-TP tunnel is indexed by Tunnel - Index, Tunnel Instance, Source ICC and Destination ICC. + For ICC based environment, MPLS-TP tunnel is indexed by Tunnel Index, + Tunnel Instance, Source ICC and Destination ICC. As mplsTunnelTable is indexed by mplsTunnelIndex, mplsTunnelInstance, mplsTunnelIngressLSRId, and mplsTunnelEgressLSRId, the MPLS-TP tunnel identifiers cannot be used directly. The mplsNodeConfigTable will be used to store an entry for ICC or Global_Node_ID with a local identifier to be used as LSR ID in mplsTunnelTable. As the regular TE tunnels use IP address as LSR ID, the local identifier should be below the first valid IP address, @@ -324,23 +324,23 @@ | | ^ | +---------+ | | | | | V V mplsTunnelTable ---->mplsXCTable ^ | | mplsTunnelExtTable - An existing mplsTunnelTable uses the new mplsNodeConfigTable table - to map the Global_Node_ID and/or ICC with the local number in order - to accommodate in the existing tunnel table's ingress/egress LSR-id. + An existing mplsTunnelTable uses the mplsNodeConfigTable table to map + the Global_Node_ID and/or ICC with the local number in order to + accommodate in the existing tunnel table's ingress/egress LSR-id. New mplsTunnelExtTable table provides the reverse direction LSP information for the existing tunnel table in order to achieve bidirectional LSPs. mplsXCExtTable is extended from mplsLsrXCTable to provide backward reference to tunnel entry. 9. Example of MPLS-TP tunnel setup @@ -609,21 +609,21 @@ LAST-UPDATED "201106160000Z" -- June 16, 2011 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Venkatesan Mahalingam Aricent, India - Email: venkatesan.mahalingam@aricent.com + Email: venkat.mahalingams@gmail.com Kannan KV Sampath Aricent, India Email: Kannan.Sampath@aricent.com Sam Aldrin Huawei Technologies 2330 Central Express Way, Santa Clara, CA 95051, USA @@ -677,22 +677,24 @@ SYNTAX OCTET STRING (SIZE (4)) MplsNodeId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The Node_ID is assigned within the scope of the Global_ID. The value 0(or 0.0.0.0 in dotted decimal notation) is reserved and MUST NOT be used. - When IPv4 addresses are in use, the value of this object - can be derived from the LSR's /32 IPv4 loop back address. + When IPv4 addresses are in use, the value of this object can + be derived from the LSR's /32 IPv4 loop back address. When + IPv6 addresses are in use, the value of this object can be a + 32-bit value unique within the scope of a Global_ID. Note that, when IP reach ability is not needed, the 32-bit Node_ID is not required to have any association with the IPv4 address space." SYNTAX Unsigned32 MplsIccId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The ICC is a string of one to six characters, each @@ -747,21 +750,21 @@ "201106160000Z" -- June 16, 2011 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Venkatesan Mahalingam Aricent, India - Email: venkatesan.mahalingam@aricent.com + Email: venkat.mahalingams@gmail.com Kannan KV Sampath Aricent, India Email: Kannan.Sampath@aricent.com Sam Aldrin Huawei Technologies 2330 Central Express Way, Santa Clara, CA 95051, USA @@ -821,22 +825,21 @@ ::= { mplsIdObjects 2 } mplsNodeId OBJECT-TYPE SYNTAX MplsNodeId MAX-ACCESS read-write STATUS current DESCRIPTION "This object allows the operator or service provider to assign a unique MPLS-TP Node_ID. - The Node_ID is assigned within the scope of the - Global_ID." + The Node_ID is assigned within the scope of the Global_ID." REFERENCE "MPLS-TP Identifiers [TPIDS]." ::= { mplsIdObjects 3 } -- Module compliance. mplsIdGroups OBJECT IDENTIFIER ::= { mplsIdConformance 1 } @@ -918,27 +921,26 @@ mplsLsrExtStdMIB MODULE-IDENTITY LAST-UPDATED "201106160000Z" -- June 16, 2011 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Venkatesan Mahalingam Aricent, India - Email: venkatesan.mahalingam@aricent.com + Email: venkat.mahalingams@gmail.com Kannan KV Sampath Aricent, India Email: Kannan.Sampath@aricent.com - Sam Aldrin Huawei Technologies 2330 Central Express Way, Santa Clara, CA 95051, USA Email: aldrin.ietf@gmail.com Thomas D. Nadeau CA Technologies 273 Corporate Drive, Portsmouth, NH, USA @@ -1135,21 +1139,21 @@ mplsTeExtStdMIB MODULE-IDENTITY LAST-UPDATED "201106160000Z" -- June 16, 2011 ORGANIZATION "Multiprotocol Label Switching (MPLS) Working Group" CONTACT-INFO " Venkatesan Mahalingam Aricent, India - Email: venkatesan.mahalingam@aricent.com + Email: venkat.mahalingams@gmail.com Kannan KV Sampath Aricent, India Email: Kannan.Sampath@aricent.com Sam Aldrin Huawei Technologies 2330 Central Express Way, @@ -1697,24 +1708,24 @@ these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: SNMP versions prior to SNMPv3 did not include adequate security. 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 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 supports for the SNMPv3 cryptographic - mechanisms (for authentication and privacy). + It is RECOMMENDED that implementers consider the security features + as provided by the SNMPv3 framework (see [RFC3410], section 8), + including full supports for the SNMPv3 cryptographic mechanisms + (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principles (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. @@ -1779,21 +1790,22 @@ Sam Aldrin Huawei Technologies 2330 Central Express Way, Santa Clara, CA 95051, USA Email: aldrin.ietf@gmail.com Thomas D. Nadeau CA Technologies 273 Corporate Drive, Portsmouth, NH, USA + Email: thomas.nadeau@ca.com Venkatesan Mahalingam Aricent India - Email: venkatesan.mahalingam@aricent.com + Email: venkat.mahalingams@gmail.com Kannan KV Sampath Aricent India Email: Kannan.Sampath@aricent.com