[mpls] MIB Dr. review of draft-ietf-mpls-tp-oam-id-mib-03.txt
"Joan Cucchiara" <jcucchiara@mindspring.com> Mon, 02 December 2013 18:03 UTC
Return-Path: <jcucchiara@mindspring.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C797A1AD7C2; Mon, 2 Dec 2013 10:03:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Td1NxdBRfk6; Mon, 2 Dec 2013 10:03:22 -0800 (PST)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 18AEC1AD7C0; Mon, 2 Dec 2013 10:03:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PjFc/sVxh0IkgG5gDkOkSgnG9bAnyl7XxH2CALDJdf1A6T9NTKR/lqaUQPG41OnY; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type: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-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jcucchiara@mindspring.com>) id 1VnXpu-0003B3-Bn; Mon, 02 Dec 2013 13:03:11 -0500
Message-ID: <0c1f01ceef88$c40ead50$6901a8c0@JoanPC>
From: Joan Cucchiara <jcucchiara@mindspring.com>
To: Venkatesan Mahalingam <venkat.mahalingams@gmail.com>, venkatesan mahalingam <venkatflex@gmail.com>
References: <00fe01ce1ed2$72981ce0$6801a8c0@JoanPC><CALXanX+G0AC0-rrg8ZQuGjvNH0YXGMQMZ=YsWTD22tCVDBop7A@mail.gmail.com> <CA+UNA00Q4QVRgJ-_bFPogFL4iwtRe=PAxhsnOeCk+5pvxYCnKA@mail.gmail.com>
Date: Mon, 02 Dec 2013 13:03:10 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C1C_01CEEF5E.DA34C9E0"
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: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654259426b3dcd17839bf757a6e9de274973122699149cfe979350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.41.69.138
Cc: mpls <mpls@ietf.org>, "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, ppan@infinera.com, Sami Boutros <sboutros@cisco.com>, Thomas Nadeau <tnadeau@juniper.net>, Kannan Sampath <kannankvs@gmail.com>
Subject: [mpls] MIB Dr. review of draft-ietf-mpls-tp-oam-id-mib-03.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 02 Dec 2013 18:03:26 -0000
Authors, For this review, I looked over the comments from 02 to see how these comments were addressed. (Version 02 comments are copied below and comments for Version 03 are prefaced with JEC.) As you can see most of the Version 02 comments have been addressed, so thank you for that! A few comments from 02 have not been updated in version 03. The 3 comments which I think needs some attention are: 1) MplsOamPhbTCValue Textual Convention should have a reference within MPLS. Even if the values have been assigned by the authors, an indication of where BHP Traffic Classes are derived from within MPLS OAM seems reasonable. 2) mplsOamIdMeMpIfIndex The REFERENCE for RFC6371 doesn't seem to refer to this object. Could REFERENCE be checked? (I thought a change here was agreed to but didn't see an updated REF.) 3) No ReadOnly conformance. Please confirm that WG is agreeable to have a MIB that does not have a ReadOnly Conformance. As you are aware, some operators prefer not to use SNMP for configuration, so if this MIB does not support a ReadOnly Conformance, then vendors will not be compliant if they support this MIB as it exists now. 4) Security Section (see below). Thanks, -Joan Specific Comments on this version 03 are prefaced with JEC: ============================================ Section 3.3 Acronyms * MIP is specified slightly differently in the referenced docs. Please be consistant. JEC: Updated. 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. JEC: The example was not evolved, but the first text was modified to agree with the example, so I can live with that. 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. JEC: Not done. So, a REF clause to at least explain where MPLS OAM PHB is described would be helpful. * mplsOamIdMegIndex There is no information about how to employ mplsOamIdMegIndexNext to obtain a value for this index. Please update the DESCRIPTION accordingly. JEC: Updated. * mplsOamIdMegOperatorType Why does this say "should have valid values...", isn't this a MUST? Also, s/while making/when/ JEC: Updated. * 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/ JEC: Updated. * mplsOamIdMegIdIcc Same comments as above. Please use MUST. JEC: Updated. * mplsOamIdMegIdUmc Same comments as above. Please use MUST. JEC: Updated. * 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. JEC: Updated. I was asking that actual object names be used in this DESCRIPTION clause. For example, the phrase "the service pointer in the mplsOamIdMeTable" to change to THAT object's name, i.e. mplsOamIdMeServicePointer. Similar comment wrt the paragraph on the pointer in PW. * 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. JEC: Updated. * 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. JEC: okay. *) 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. JEC: okay. *) 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? JEC: Not updated. I think this is an oversight and you had already found a correct REFERENCE but couldn't locate that email... *) 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? JEC: Updated. 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? JEC: Not done. *) 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. JEC: Updated. 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. JEC: Not done. Section 9. IANA Considerations s/specified this document/specified in this document/ missing the word "in" JEC: Updated. 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