Re: [mpls] MIB Doctor Review of draft-ietf-mpls-tp-oam-id-mib-02.txt
Sam Aldrin <aldrin.ietf@gmail.com> Tue, 12 March 2013 03:38 UTC
Return-Path: <aldrin.ietf@gmail.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 4A1E721F8962; Mon, 11 Mar 2013 20:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.071
X-Spam-Level:
X-Spam-Status: No, score=0.071 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1]
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 bYei1L+m-fNX; Mon, 11 Mar 2013 20:38:43 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 220E021F895F; Mon, 11 Mar 2013 20:38:43 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id 13so5895311iea.0 for <multiple recipients>; Mon, 11 Mar 2013 20:38:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=TxTuW6H+krVJYVV/3D+jltMk1oFHVg2HsHVVTTEb9zc=; b=eN8+/p6/Bbm9jd/yzorAlcMbObT977G5UBHtsUU6msKYtuSmRzaxAMYUxkkW7lA0BU bihtgAWoHlKKteNZkr0jG9UO56On4YUKkhTSnK8lCe8D1edM1nixolTk8EOXIxU6s8CN EBIMbKpjo0HP7SbGaHN2NC7qM2jRBzDXccpqS7ShI244ZTdcAnKue7h7FB5nUFFVCUZt T0IVUJeL9QnY/LmlEErYXCDeTEcsa8UqPtJOoBpOYg9hHlagfgDiu00oPmbRYycDawD6 aukZfCGBMIi26/+mKB52s5ziIJd2Jgbgh152GFiVh47owOxyDpomejDX3Hh/0eGiWTLI XLSA==
X-Received: by 10.50.16.138 with SMTP id g10mr10378825igd.33.1363059522758; Mon, 11 Mar 2013 20:38:42 -0700 (PDT)
Received: from [130.129.135.99] ([130.129.135.99]) by mx.google.com with ESMTPS id ua6sm17016707igb.0.2013.03.11.20.38.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 20:38:41 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset="iso-8859-1"
From: Sam Aldrin <aldrin.ietf@gmail.com>
X-Priority: 3
In-Reply-To: <00fe01ce1ed2$72981ce0$6801a8c0@JoanPC>
Date: Mon, 11 Mar 2013 20:38:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <ADE9E951-D756-47B6-97C8-AD7A97EF5C0D@gmail.com>
References: <00fe01ce1ed2$72981ce0$6801a8c0@JoanPC>
To: Joan Cucchiara <jcucchiara@mindspring.com>
X-Mailer: Apple Mail (2.1499)
Cc: mpls@ietf.org, "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, ppan@infinera.com, Sami Boutros <sboutros@cisco.com>, Kannan Sampath <kannankvs@gmail.com>, Venkatesan Mahalingam <venkat.mahalingams@gmail.com>
Subject: Re: [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:38:44 -0000
Hi Joan, Thank you so much for the detailed feedback and comments. Will take a look at them and address as necessary. Will be circling back to you and MIB doctors with the status and response at the earliest. thanks -sam On Mar 11, 2013, at 8:34 PM, "Joan Cucchiara" <jcucchiara@mindspring.com> wrote: > > 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