Re: [mpls] ??: Review of draft-ietf-mpls-tp-linear-protection-mib-07
"Joan Cucchiara" <jcucchiara@mindspring.com> Tue, 21 June 2016 15:50 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 1FE0712D939; Tue, 21 Jun 2016 08:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=jcucchiara@mindspring.com header.d=mindspring.com
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 dTv2EvRLoFcF; Tue, 21 Jun 2016 08:50:08 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8413612D147; Tue, 21 Jun 2016 08:50:08 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=m2kI/0fzbZlflkPQQzy/1IIHmhBuHUzlil9JaQMWBn00nkQHhmBaDLlyRSxuaDU+; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [72.93.239.57] (helo=JoanTower) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <jcucchiara@mindspring.com>) id 1bFNvo-0005zV-S2; Tue, 21 Jun 2016 11:49:41 -0400
From: Joan Cucchiara <jcucchiara@mindspring.com>
To: '???' <ryoo@etri.re.kr>, 'Loa Andersson' <loa@pi.nu>, 'Joan Cucchiara' <jcucchiara.ietf@gmail.com>
References: <eo7rpm11h6888m0hrkuyfgpj.1466220440723@email.android.com>
In-Reply-To: <eo7rpm11h6888m0hrkuyfgpj.1466220440723@email.android.com>
Date: Tue, 21 Jun 2016 11:49:35 -0400
Message-ID: <017001d1cbd4$84b4c600$8e1e5200$@mindspring.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0171_01D1CBB2.FDAF0CE0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFgvweFI5FsImu4J8BlAaj6Ri7FGqDWKrAg
Content-Language: en-us
X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26547ce1a1b3cafbcf3ce3e28be3e1449f3608a8bb3e8e732a70350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 72.93.239.57
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/PEezPDmcg4o7NZkadRZ66V2DCBA>
Cc: mpls@ietf.org, draft-ietf-mpls-tp-linear-protection-mib@ietf.org, mpls-chairs@ietf.org, mib-doctors@ietf.org
Subject: Re: [mpls] ??: Review of draft-ietf-mpls-tp-linear-protection-mib-07
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Jun 2016 15:50:15 -0000
Sorry, yes, I dropped the ball but it is back on my plate. Please give me another couple of days. -Joan From: ??? [mailto:ryoo@etri.re.kr] Sent: Friday, June 17, 2016 11:27 PM To: Loa Andersson; Joan Cucchiara Cc: Joan Cucchiara; mpls@ietf.org; draft-ietf-mpls-tp-linear-protection-mib@ietf.org; mpls-chairs@ietf.org; mib-doctors@ietf.org Subject: ??: [mpls] ??: Review of draft-ietf-mpls-tp-linear-protection-mib-07 Loa, thank you for looking into this. You have the most recent email on this work. I am still waiting for Joan's response. Best regards Jeong-dong -------- 원본 이메일 -------- 보낸 사람: Loa Andersson <loa@pi.nu> 날짜: 16/6/17 19:20 (GMT+09:00) 받은 사람: 류정동 <ryoo@etri.re.kr>, Joan Cucchiara <jcucchiara.ietf@gmail.com> 참조: Joan Cucchiara <jcucchiara@mindspring.com>, mpls@ietf.org, draft-ietf-mpls-tp-linear-protection-mib@ietf.org, mpls-chairs@ietf.org, mib-doctors@ietf.org 제목: Re: [mpls] 회신: Review of draft-ietf-mpls-tp-linear-protection-mib-07 Jeong-dong and Joan, This is the latest I have on this document, what is the status today? /Loa On 2016-05-27 03:09, Ryoo, Jeong-dong wrote: > Joan, thanks. > > > We are looking forward to hearing from you soon. > > > Jeong-dong > > > > > > > > ------------------------------------------------------------------------ > *보낸 사람 : *"Joan Cucchiara" <jcucchiara.ietf@gmail.com> > *보낸 날짜 : *2016-05-26 23:09:46 ( +09:00 ) > *받는 사람 : *류정동 <ryoo@etri.re.kr> > *참조 : *Joan Cucchiara <jcucchiara@mindspring.com>, Loa Andersson > <loa@pi.nu>, mpls@ietf.org <mpls@ietf.org>, > draft-ietf-mpls-tp-linear-protection-mib@ietf.org > <draft-ietf-mpls-tp-linear-protection-mib@ietf.org>, > mpls-chairs@ietf.org <mpls-chairs@ietf.org>, mib-doctors@ietf.org > <mib-doctors@ietf.org> > *제목 : *Re: [mpls] 회신: Review of > draft-ietf-mpls-tp-linear-protection-mib-07 > > > > Jeong-dong, > > > > > > Thank you for the responses to my comments. I will take a look at the > updated draft soon. > > > > > > -Joan > > > > > > On Thu, May 19, 2016 at 9:24 AM, 류정동 <ryoo@etri.re.kr <mailto:ryoo@etri.re.kr%0b> > <mailto:ryoo@etri.re.kr>> wrote: > > > > Dear Joan, > > > > > > We resolved all of your comments and uploaded a revsion today. > > > > > > Please, see inlines starting with [Authors] in your previous email > below. > > > > > > The revised draft can be found in: > > > > https://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-linear-protection-mib-08.txt > > > > > > > We appreciate your help on this draft. > > > > > > Best regards, > > > > > > Jeong-dong > > > > > > ________________________________________ > > > > 보낸 사람: Joan Cucchiara [jcucchiara@mindspring.com > <mailto:jcucchiara@mindspring.com>] > > > > 보낸 날짜: 2016년 4월 5일 화요일 오전 12:10 > > > > 받는 사람: Loa Andersson; mpls@ietf.org <mailto:mpls@ietf.org>; > draft-ietf-mpls-tp-linear-protection-mib@ietf.org > <mailto:draft-ietf-mpls-tp-linear-protection-mib@ietf.org>; > mpls-chairs@ietf.org <mailto:mpls-chairs@ietf.org> > > > > 참조: mib-doctors@ietf.org <mailto:mib-doctors@ietf.org> > > > > 제목: Review of draft-ietf-mpls-tp-linear-protection-mib-07 > > > > > > Comments for draft-ietf-mpls-tp-linear-protection-mib-07.txt > > > > > > Authors, > > > > > > Lots of work went into this draft. The early MIB Doctor review > > > > comments have been incorporated, so thank you for that. These > > > > comments are arranged in 3 sections: MIB compiler outputs, > > > > General Comments which are observations that apply to several > > > > places in the MIB and should be checked for throughout the MIB. > > > > > > The last section is for specific comments. > > > > > > Please take these comments as part of the last call. > > > > > > Thanks, > > > > -Joan > > > > > > Compiles cleanly with smilint > > > > > > smicng flagged some errors > > > > Output from smicng > > > > E: f(MPLS-LSP-MIB.my), (370,4) Row "mplsLpsConfigEntry" may not > > > > have columns with MAX-ACCESS of read-write if any column is read-create > > > > E: f(MPLS-LSP-MIB.my), (378,15) Index item > > > > "mplsLpsConfigDomainIndex" must be defined with syntax that > > > > includes a range > > > > E: f(MPLS-LSP-MIB.my), (907,4) Item "mplsLpsMeConfigDomainIndex" > > > > has invalid value for MAX-ACCESS > > > > > > > > When looking at the MIB, I see that there do appear to be some > potential > > > > errors: > > > > mplsLpsConfigCommand OBJECT-TYPE > > > > SYNTAX MplsLpsCommand > > > > MAX-ACCESS read-write <---- should be read-create > > > > > > because row created using RowStatus > > > > STATUS current > > > > > > [Authors] OK, Fixed. > > > > > > In general, indices should specify a range so this is why it was > > > > flagged by compiler. Looking at this specific index would like to > > > > understand how the value is supposed to be assigned? If this is > > > > assigned by an operator, perhaps there should be a mechanism for > > > > the operator to choose a value (for example, by using a > > > > IndexIntegerNextFree object)? Please clarify. > > > > > > mplsLpsConfigDomainIndex OBJECT-TYPE > > > > SYNTAX Unsigned32 > > > > > > [Authors] Fixed by using the IndexIntegerNextFree object. > > > > > > mplsLpsMeConfigDomainIndex <--- name implies that this is an index > > > > but it is NOT included in the INDEX clause for this table. > > > > > > Please clarify what is intended. > > > > > > [Authors] This is not the INDEX for this table. It is used to > identify the corresponding mplsLpsConfigDomainIndex value in the > other table, “mplsLpsConfigTable”. The name of this object is > changed to mplsLpsMeConfigDomainIndexValue to avoid confusion. > > > > > > > > General Comments: > > > > ===================== > > > > > > * There are mentions of there being two MIB Modules in this > > > > document, but there is only one MIB Module. I have tried to note > > > > these statements under specific comments, but please check for > > > > such statements. If the intention is to create two MIB Modules, > > > > that is fine, but currently, there is only one. > > > > > > [Authors] Yes, there is only one defined in this document. Fixed > > > > > > * The relationships of these Tables is not clear. > > > > MplsLpsConfigTable has an INDEX but how the operator > > > > is supposed to choose a value for this index is > > > > not specified. The MplsLpsMeConfigTable indexing is confusing. > > > > Although the document states that this table is an extension > > > > of the MPLSOamIdMeTable, the name of the object, > > > > mplsLpsMeConfigDomainIndex is confusing because it suggests > > > > this is an INDEX (as does the status of not-accessible). Please > clarify. > > > > > > [Authors] Fixed by using the IndexIntegerNextFree object and > changing the name of mplsLpsConfigDomainIndex to > mplsLpsMeConfigDomainIndexValue > > > > > > Since the indexing for these Tables is confusing to me, then > > > > please realize that this MIB may have additional comments > > > > during the next review once the indexing is clarified. > > > > > > * In general more REFERENCE Clauses could/should be added throughout > MIB. > > > > > > Objects such as mplsLpsMeConfigDomainIndex, mplsLpsMeStatusCurrent, > > > > mplsLpsConfigMode, mplsLpsConfigProtectionType, etc. This was also > > > > mentioned during the early MIB Dr. review. > > > > > > [Authors] OK. Added more REFERENCE Clauses. > > > > > > * Some of the objects use Integer32 but they probably should > > > > use Unsigned32. In other words, if the objects can only take on > values 0 > > > > and above, then > > > > they should use Unsigned32. > > > > > > e.g. mplsLpsConfigSdBadSeconds, mplsLpsConfigSdGoodSeconds, > > > > mplsLpsConfigWaitToRestore, mplsLpsConfigHoldOff, etc. Please > > > > check all the Integer32 objects to see if they should be Unsigned32. > > > > > > [Authors] OK, Fixed. > > > > > > *) Date is same a previous version. This should be updated for > > > > every revision of the document. Please update. > > > > LAST-UPDATED and REVISION clauses > > > > "201512060000Z" -- December 06, 2015 > > > > > > [Authors] OK, Fixed. > > > > > > *) Only FullCompliance is done for this MIB Module. As you > > > > probably are aware, not all operators want to configure > > > > using SNMP, if there is not a ReadOnly Compliance available, then > > > > they will not be compliant with the MIB. I think a ReadOnly Compliance > > > > for a MIB is useful and would like to understand why this MIB > doesn't have > > > > one. > > > > Could the authors please clarify? > > > > > > [Authors] OK, ReadOnly Compliance is added. > > > > > > > > Specific Comments: > > > > > > Section 1. Introductions > > > > > > Mentions multiple MIB Modules but there is only one. Please > > > > clarify the text: "However, since the MIB modules ..." <-- plural > > > > > > [Authors] Yes, there is only one. Fixed. > > > > > > > > Section 4. > > > > > > As mentioned before there is only 1 MIB module. Please update. > > > > > > "This document specifies a MIB module > > > > for the Label Edge Router (LER) > > > > that supports MPLS TP Linear protection and a MIB > > > > module that defines textual conventions....." > > > > > > [Authors] OK. Fixed. > > > > > > Section 5.1 Textual Conventions > > > > > > * I don't see a separate MIB Module for TCs. Please clarify. > > > > > > [Authors] Fixed. > > > > > > Section 5.4 The Table Structure > > > > > > * The mplsLpsConfigTable > > > > > > "The protection domain is identified by mplsLpsConfigGroupName." > > > > This statement does not seem to be entirely accurate given the MIB > > > > design for 2 reasons, 1. there doesn't seem to be an object > > > > mplsLpsConfigGroupName > > > > and 2. the INDEX is mplsLpsConfigDomainIndex Unsigned32 (which also > appears > > > > in the > > > > mplsLpsMeConfigEntry with a status of not-accessible > > > > (and I think you intend for it to be an object)? > > > > > > [Authors] “mplsLpsConfigGroupName” should be > “mplsLpsConfigDomainName”. It’s been corrected. > > > > > > As a reviewer, this is confusing because the relationship with > > > > these tables is unclear and so it is very difficult to > > > > review the MIB Module. Please clarify the relationship with > > > > these tables and to the mplsOamIdMeTable in the > > > > MPLS-OAM-ID-STD-MIB. > > > > > > [Authors] A protection domain consists of two paths, working and > protection paths, and requires two OAM MEs; one OAM ME for the > working path and the other ME for the protection path. In other > words, a row of “mplsLpsConfigTable” is for one protection domain, > which requires two rows in “mplsOamIdMeTable”: one for the working > path and the other for the protection path. Also note that an entry > of “mplsOamIdMeTable” may not belong to any protection domain. The > row of “mplsLpsMeConfigTable” defined in this document has a sparse > relationship with that of the “mplsOAMIdMeTable” defined in RFC 7697. > > > > > > > > "The other attributes in this table", do you mean objects? > > > > > > [Authors] Yes. Fixed. > > > > > > > > * The mplsLpsStatusTable > > > > > > There is no mention that the mplsLpsStatusTable's Entries have an > > > > AUGMENTS relationship with the mplsLpsConfigTable Entries. Please add. > > > > > > [Authors] Added. > > > > > > > > 6.1 Relationship to the MPLS OAM maintenance identifier MIB Module > > > > > > The title needs to be capitalized correctly, Relationship to the > > > > MPLS OAM Maintenance Identifier MIB Module > > > > > > Please update this section to use RFC7697 (and in Informative > References > > > > also) > > > > instead of draft-ietf-mpls-tp-oam-id-mib. > > > > > > [Authors] Ok. Fixed. > > > > > > > > As mentioned above, the mplsLpsMeConfigTable has an object > > > > mplsLpsMeConfigDomainIndex which is (not-accessible). > > > > Is this supposed to be an INDEX, or is this an object? I am > > > > confused by what is intended. > > > > > > [Authors] The name of this object is changed to > mplsLpsMeConfigDomainIndexValue to avoid confusion. > > > > > > > > 7. Example of Protection switching configuration for > > > > > > MPLS-TP TE tunnel (Please change title: Example of Protection > Switching > > > > Configuration) > > > > > > * I am unclear how mplsLspConfigEntry is actually configured for > > > > use in this example. Is an operator supposed to randomly choose an > INDEX > > > > value? > > > > > > Would an IndexNext object be useful to use in conjunction with this > INDEX? > > > > > > [Authors] Yes, it has been addressed with IndexIntegerNextFree. > > > > > > > > > > MIB Module > > > > ------------ > > > > > > (general comment: the DESCRIPTION clauses could be more readable > > > > if consistency was used. Sometimes the > > > > value is listed on the side and the description follows on the > > > > same line and sometimes the value is listed > > > > on a single line and the description follows a couple of lines > > > > after. Please be consistent.) > > > > > > [Authors] Ok. Fixed. > > > > > > > > * mplsLpsConfigDomainName -- Is there a DEFAULT value for this > > > > object? The string size is 1..32 with no > > > > option of 0 length string, so wanted to check about a default > > > > value? Under what circumstances can this value > > > > be modified? Please give a REFERENCE. > > > > > > [Authors] No DEFAULT value is needed. The size has been changed to > 0..32. > > > > > > > > * mplsLpsConfigMode - Needs REFERENCE (and please try to be > > > > specific). Under what circumstances can this be modified? > > > > > > [Authors] REFERENCE is given. > > > > > > > > * mplsLpsConfigWaitToRestore > > > > Why is this not in minutes? If someone configures this to be 30 > > > > seconds is that valid? Doesn't seem so based on the DESCRIPTION. > Please > > > > clarify. > > > > > > [Authors] Fixed with “minutes”. The range is also corrected. > > > > > > > > * mplsLpsConfigHoldOff What is meant by "Can be configured in > > > > steps of 100?" Is this 100 milliseconds? If so then maybe a > better unit > > > > choice would be > > > > centiseconds. Please clarify. > > > > > > [Authors] It can be configured like: 0, 100 ms, 200 ms, … , 10 > seconds. So, the units and the description are changed using > “deciseconds”. > > > > > > *mplsLpsConfigCommand is read-write. Is this supposed to be > > > > read-create? > > > > > > [Authors] Yes. Fixed > > > > > > > > *mplsLpsConfigRowStatus -- I think there is some conflicting > > > > advice given to the operator. Several objects say that it is fine > to change > > > > the > > > > value of the object when RowStatus is active, but this is not specified > > > > consistently. Limiting the > > > > values of RowStatus in the Conformance Section > > > > may be the way to go. Please clarify. > > > > > > [Authors] There are some objects that can be changed during protocol > operation, while other objects cannot be changed but their values > need to be given before the operation. In the revision, we specified > them consistently. > > > > > > > > *mplsLpsMeConfigState is a read-create. This is probably okay, but > > > > again, that depends on if mplsLpsMeConfigDomainIndex > > > > is an INDEX for this table given that it has a status of > not-accessible, > > > > etc. > > > > > > [Authors] “mplsLpsMeConfigDomainIndex” was not intended to be INDEX, > but to contain the value of the value of protection domain index. We > changed it to mplsLpsMeConfigDomainIndexValue to avoid confusion > > > > > > > > *mplsLpsMeStatusSwitchoverSeconds > > > > Needs a units clause for Seconds > > > > > > [Authors] Fixed. > > > > > > > > Notifications > > > > > > There are a couple Notifications that are send when values of certain > > > > counters increment. Maybe this is valid, but it seems suspect. > > > > If a management stations needs information on counters, > > > > why can't it just retrieve them at that point? I don't see any > > > > counter discontinuity objects, so was wondering about that too. > > > > > > [Authors] Whenever there is an increment in any of the enabled > counters, network operators need to be alarmed. > > > > > > > > * mplsLpsEventFopTimOut Notification > > > > > > Please rename this to mplsLpsEventFopTimeout > > > > > > [Authors] OK. Fixed. > > > > > > > > * Compliance/Conformance Section of the MIB Module > > > > > > Currently, there is only FullCompliance. Why is there no > > > > ReadOnlyCompliance? > > > > > > [Authors] OK. It’s been added. > > > > > > > > --- end of comments --- > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org <mailto:mpls@ietf.org> > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.7539 / Virus Database: 4604/12443 - Release Date: 06/18/16