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!
>