[mpls] MIB Doctor Review of draft-ietf-mpls-tp-oam-id-mib-02.txt
"Joan Cucchiara" <jcucchiara@mindspring.com> Tue, 12 March 2013 03:34 UTC
Return-Path: <jcucchiara@mindspring.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542E821F8790; Mon, 11 Mar 2013 20:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSFETY1e5BEr; Mon, 11 Mar 2013 20:34:14 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4644C21F860A; Mon, 11 Mar 2013 20:34:14 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=X7ms22iN6z0fm4c5EwpowYGr5JmHIb9UtFnm1bmbLK2Z082TZnpqzxVgQ98Li+27; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jcucchiara@mindspring.com>) id 1UFFyY-0005EP-MI; Mon, 11 Mar 2013 23:34:06 -0400
Message-ID: <00fe01ce1ed2$72981ce0$6801a8c0@JoanPC>
From: Joan Cucchiara <jcucchiara@mindspring.com>
To: aldrin.ietf@gmail.com, Thomas Nadeau <tnadeau@juniper.net>, Venkatesan Mahalingam <venkat.mahalingams@gmail.com>, Kannan Sampath <kannankvs@gmail.com>, ppan@infinera.com, Sami Boutros <sboutros@cisco.com>
Date: Mon, 11 Mar 2013 22:34:05 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654fcd1a393e6a2ffdd85dcb1dfe9c8cca8f966978d6047df59350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.41.69.138
Cc: mpls@ietf.org, "MIB Doctors (E-mail)" <mib-doctors@ietf.org>
Subject: [mpls] MIB Doctor Review of draft-ietf-mpls-tp-oam-id-mib-02.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2013 03:34:15 -0000
Authors, Most of the comments during the LC have been addressed. Thank you for that. Please see some follow-up comments below. Thanks, -Joan * MIB compiles cleanly with smicng and smilint Specific Comments: ==================== Section 3.3 Acronyms * MIP is specified slightly differently in the referenced docs. Please be consistant. Section 6. This example, specifies the mplsOamIdMeMpEntry as a MEP, but why isn't the SourceMepIndex or SinkMepIndex == mplsOamIdMeMpIndex? Also, there are at least 2 MEPs in an ME, and at least one ME in a MEG and these relationships are not completely evolved in this example. I think the example should be expanded to agree with what is stated in the first paragraph. MIB Module comments ------------------- * TC: MplsOamPhbTCValue MplsOamPhbTCValue ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is the Per-hop Behavior (PHB) traffic class values for the MPLS OAM operations." SYNTAX INTEGER { be (1), af1 (2), af2 (3), af3 (4), af4 (5), ef (6), cs6 (7), cs7 (8) } Rfc3270, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", specifies that MPLS TP will use DSCP as per rfc2474 and other specs. Is that the intent wrt this TC? If not, please explain where these values are defined, otherwise, if these values are as per rfc3270, then please be consistant with the labels. TC labels should correspond more closely to DiffServ BHB traffic class values. In other words, http://www.iana.org/assignments/dscp-registry/dscp-registry.xml Name Space Reference CS0 000000 [RFC2474] CS1 001000 [RFC2474] CS2 010000 [RFC2474] CS3 011000 [RFC2474] CS4 100000 [RFC2474] CS5 101000 [RFC2474] CS6 110000 [RFC2474] CS7 111000 [RFC2474] AF11 001010 [RFC2597] AF12 001100 [RFC2597] AF13 001110 [RFC2597] AF21 010010 [RFC2597] AF22 010100 [RFC2597] AF23 010110 [RFC2597] AF31 011010 [RFC2597] AF32 011100 [RFC2597] AF33 011110 [RFC2597] AF41 100010 [RFC2597] AF42 100100 [RFC2597] AF43 100110 [RFC2597] EF PHB 101110 [RFC3246] VOICE-ADMIT 101100 [RFC5865] Continuing with that thought: I believe this TC could (and should) be formalized into an IANA-Maintained MIB if these values are the same as the above IANA-Maintained assignments for DFCPs. (NOTE: this was mentioned also in the LC comments.) Please discuss. Also, this TC should have a REFERENCE clause. * mplsOamIdMegIndex There is no information about how to employ mplsOamIdMegIndexNext to obtain a value for this index. Please update the DESCRIPTION accordingly. * mplsOamIdMegOperatorType Why does this say "should have valid values...", isn't this a MUST? Also, s/while making/when/ * mplsOamIdMegIdCc s/contains non-null ICC/MUST contain a/ s/otherwise null ICC value/otherwise a null ICC value/ s/should be assigned/MUST be assigned/ * mplsOamIdMegIdIcc Same comments as above. Please use MUST. * mplsOamIdMegIdUmc Same comments as above. Please use MUST. * mplsOamIdMegServiceType Could you please specify the service pointer by the object's name? Also, the references are within the DESCRIPTION which is fine, but they should also be in a REFERENCE clause. * mplsOamIdMeIndexNext and mplsOamIdMpIndexNext These objects are not referred to by mplsOamIdMeIndex or mplsOamIdMeMpIndex. There is not enough description to understand how the IndexNext objects are to be used. * MplsOamIdMeTable The mplsOamIdMeEntry states "An entry in this table represents MPLS-TP maintenance entity." Yet, looking at the INDEX { mplsOamIdMegIndex, mplsOamIdMeIndex, mplsOamIdMeMpIndex } This is not an ME because an ME by definition has 2 (source/sink)MEPs. An entry in this table represents either a MEP or MIP, not an ME. *) What is the benefit of combining MEP and MIP (i.e. the objects which contain "Mp" as part of their object name)? Many other objects in this table, need to figure out if the entry is describing a MEP or MIP before the value can be interpreted correctly. Additionally, there is duplicate info in the form of having a Source and Sink specified for each Mp. Could you elaborate on what the benefit is of having listing MEPs and MIPs in this way? It seems like the original intent may have been to specify an ME as being an entry in this table. However, that would mean the table should probably be indexed by MEG index, a ME index, a source MEP index and a sink MEP index. This would greatly simplify many of the object descriptions. Have you considered specifying MIPs in a 3rd table, such that each ME would have 2 MEPs and zero or more MIPs? Please discuss. *) mplsOamIdMeMpIfIndex Rfc6370, Section 4.discusses an IF_NUM and an IF_ID and states "Note that IF_Num had no relation with the ifNum object defined in RFC2863. Further, no mapping is mandated between IF_Num and ifIndex in RFC 2863." I don't see any mention of ifIndex in RFC 6371, so could you tell me what Section? Is this object supposed to represent IF_NUM in rfc6370? *) mplsOamIdMeServicePointer The DESCRIPTION contains wording which is very loose. Could you please use wording which specifies a "SHOULD" or "MUST"? Under what circumstances should this be 0.0? Compliance Statement of the MIB *) Compliance (This has been asked before and I have not seen any discussion about it.) There is no read-only compliance. Has it been made clear to the WGs (MPLS and PWE3) that SNMP sets will need to be supported in order to be compliant with the MIB? *) question above, about whether the intention is to support ifIndex as per rfc2863 or IF_ID (or IF_NUM) as per rfc6370 may affect this. "MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. MANDATORY-GROUPS { ifGeneralInformationGroup, ifCounterDiscontinuityGroup" *) mplsOamIdNotificationObjectsGroup OBJECT-GROUP I don't see a need to make a specific group for these objects. They are already specified by mplsOamIdGroups. Section 8. Security Section Need to reference specific read-create objects and also read-only which could impact the network. Additionally, the incomplete sentence: "These are the tables and objects and their sensitivity/vulnerability: " needs to be completed. Section 9. IANA Considerations s/specified this document/specified in this document/ missing the word "in" Section 11. Thank you for the ack!
- [mpls] MIB Doctor Review of draft-ietf-mpls-tp-oa… Joan Cucchiara
- Re: [mpls] MIB Doctor Review of draft-ietf-mpls-t… Sam Aldrin
- Re: [mpls] MIB Doctor Review of draft-ietf-mpls-t… venkatesan mahalingam
- Re: [mpls] MIB Doctor Review of draft-ietf-mpls-t… Venkatesan Mahalingam
- [mpls] MIB Dr. review of draft-ietf-mpls-tp-oam-i… Joan Cucchiara
- Re: [mpls] MIB Dr. review of draft-ietf-mpls-tp-o… Sam Aldrin