Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review
"Kalyan (Srinivas)Tata" <stata@checkpoint.com> Mon, 08 March 2010 20:16 UTC
Return-Path: <stata@checkpoint.com>
X-Original-To: vrrp@core3.amsl.com
Delivered-To: vrrp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D2A3A6991; Mon, 8 Mar 2010 12:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level:
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSbQpka0U9go; Mon, 8 Mar 2010 12:16:54 -0800 (PST)
Received: from us.checkpoint.com (usmail2.us.checkpoint.com [216.200.240.146]) by core3.amsl.com (Postfix) with ESMTP id 94BA93A69AC; Mon, 8 Mar 2010 12:16:54 -0800 (PST)
Received: from us-ex01.ad.checkpoint.com (localhost.localdomain [127.0.0.1]) by us.checkpoint.com (8.13.5/8.13) with ESMTP id o28KGggV001505; Mon, 8 Mar 2010 12:16:43 -0800
Received: from USEXCHANGE.ad.checkpoint.com ([216.200.240.133]) by US-EX01.ad.checkpoint.com ([216.200.240.139]) with mapi; Mon, 8 Mar 2010 12:17:03 -0800
From: "Kalyan (Srinivas)Tata" <stata@checkpoint.com>
To: Joan Cucchiara <jcucchiara@mindspring.com>, Mukesh Gupta <mukesh@juniper.net>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>, Adrian Farrel <Adrian.Farrel@huawei.com>, Ronald Bonica <rbonica@juniper.net>, "tata_kalyan@yahoo.com" <tata_kalyan@yahoo.com>, "vrrp@ietf.org" <vrrp@ietf.org>
Date: Mon, 08 Mar 2010 12:17:01 -0800
Thread-Topic: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review
Thread-Index: Acq8m1X7o+23A1VGQBqqieCc8WuA7wCXxa+g
Message-ID: <9FFC3234F1B7F0439C9B8BF94A83F48214ACB1A456@USEXCHANGE.ad.checkpoint.com>
References: <9CEB032BDB454422BA9F65732441BDF0@your029b8cecfe> <EDC652A26FB23C4EB6384A4584434A0401F0DE0F@307622ANEX5.global.avaya.com> <001c01caaa58$e7924fd0$6501a8c0@JoanPC> <EDC652A26FB23C4EB6384A4584434A0401F0E16E@307622ANEX5.global.avaya.com> <497B6D90E0023142AF34948DEFFAB38D3A8772AFBA@EMBX01-HQ.jnpr.net> <002201cabc98$04417510$6501a8c0@JoanPC>
In-Reply-To: <002201cabc98$04417510$6501a8c0@JoanPC>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 08 Mar 2010 23:45:33 -0800
Cc: "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, "vrrp-chairs@tools.ietf.org" <vrrp-chairs@tools.ietf.org>, Radia Perlman <radia@alum.mit.edu>, "draft-ietf-vrrp-unified-mib@tools.ietf.org" <draft-ietf-vrrp-unified-mib@tools.ietf.org>
Subject: Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2010 20:16:59 -0000
Hi Joan, Thanks for the comments. I will reply back in a day with explanations of very valid issues you raised. Thanks Kalyan -----Original Message----- From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Joan Cucchiara Sent: Friday, March 05, 2010 11:14 AM To: Mukesh Gupta; Romascanu, Dan (Dan); Adrian Farrel; Ronald Bonica; tata_kalyan@yahoo.com; vrrp@ietf.org Cc: MIB Doctors (E-mail); Radia Perlman; vrrp-chairs@tools.ietf.org; draft-ietf-vrrp-unified-mib@tools.ietf.org Subject: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review Hello Kalyan, The examples in the document are very helpful and there was a great deal of work that went into this document. Thank you for that! MIB compiler output is first, followed by comments. Thanks, -Joan MIB Compiler: SMICng -------------------- W: f(VRRP-MIB.my), (437,8) Row "vrrpAssociatedIpAddrEntry" has indexing that may create variables with more than 128 sub-ids W: f(VRRP-MIB.my), (158,23) Row "vrrpOperationsEntry" does not have a consistent indexing scheme - index items from current table must come after index items from other tables W: f(VRRP-MIB.my), (453,23) Row "vrrpAssociatedIpAddrEntry" does not have a consistent indexing scheme - cannot specify an index item from additional "base row" vrrpOperationsEntry, since can have only one "base row" which is ifEntry WRT the INDEX To Large error. I think this was addressed by Bert Wijnen in prior versions but I don't see any wording in the DESCRIPTION clause or any SIZE limit on the Index vrrpAssociatedIpAddr. So something like this (and some text describing why the size limits in the DESCRIPTION clause would be appropriate. Additionally, the vrrpOperationsInetAddrType should be restricted. vrrpAssociatedIpAddr OBJECT-TYPE SYNTAX InetAddress (SIZE(0|4|16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION Please discuss the other 2 warnings wrt Indexing. Specifically, why are tables using AddrType, VrId and ifIndex, rather than ifIndex, VrId, AddrType? (Please see comment below regarding section 8.) MIB Compiler: SmiLint ------------------------ mibs/VRRP-MIB.my:437: [5] {index-exceeds-too-large} warning: index of row `vrrpAssociatedIpAddrEntry' can exceed OID size limit by 142 subidentifier(s) Comments -------- 1)NIT: Does not strip cleanly with SmicngPRO mstrip (This doesn't need to be fixed for MIB Dr. review, just as an fyi). 2) Please Discuss: My understanding (based on an old email exchange (fall 2008) with the MIB author and the AD of the WG at that time) was that the VRRP unified MIB was not going to be an update of the original VRRP-MIB (RFC2787), but rather a new MIB based on the new unified spec that was being created. There are a couple issues that I'd like clarified wrt to an updated MIB (this draft) vs. a new MIB: A) draft-ietf-vrrp-unified-spec-05.txt, section 8.4 states "that VRRPv2 and VRRPv3 interoperation is optional" and the recommendation is that it should only be done for transitioning from VRRPv2 to VRRPv3. A new MIB (rather than an updated MIB) would likely re-enforce the guidelines from the specification. Could you discuss why an updated MIB is better in this regard? B) Additionally, this new MIB is based on a MIB that is 10 years old (RFC2787), while not specifically an issue, I do see that this updated MIB is using older MIB conventions. Not a show-stopper but certainly a consideration. Was this considered? C) Comment: Most of the MIB objects contained in RFC2787 are deprecated by this MIB. This indicates that creating a new MIB would be fairly straightforward. 3) The terminology of this document does not consistently utilize the Definitions outlined in the draft-ietf-vrrp-unified-spec-05.txt. So for example, VRRP is used in places to mean VRRP Router. The use of IPvX is not done. Would be better to be consistent between the spec and the MIB. 4) DEPRECATED OBJECT DESCRIPTIONS: Way back when, Dave Perkins suggested starting the DESCRIPTION clause for a deprecated object with: "This object is DEPRECATED. This is done because..." followed by the original description. While you have done a great job including the reasons why an object was deprecated, could you move this to the beginning of the DESCRIPTION clause (rather than end)? 5) Title: Please mention that this is Version 3 somewhere in the title (as does the specification) 6) Section 4. Relationship to RFC2787 The following sentence is troublesome because the MIB Module "deprecates" objects and does not obsolete them. While you may be trying to indicate that this document will obsolete RFC2787, that is not exactly clear. (perhaps, this is another reason to create a new MIB module vs. an updated one?) "RFC2787 [RFC2787] defines managed objects for VRRP over IPv4 and is now obsoleted by this memo." 7) Section 5. Relation to Interface Group (IF-MIB) A) Please remove the word "physical" in front of physical interface. B) Should specify a reference such as: The VRRP-MIB Module imports ifIndex from the IF-MIB. At this time, the latest version of IF-MIB is from [RFC2863]. C) A reference to [RFC2863] needs to be provided in the Normative References. 8) Section 7. VRRP MIB Structure This section should discuss the relationship between the tables. The groups listed are part of the conformance, and while okay to mention these, that really isn't the MIB's structure. NIT: Should have a (3) before "The vrrpAssociatedIpAddrTable" 9) Section 8. VRRP MIB Table Design The MIB design should focus on indexing the tables such that the table lookups are more advantageous for the device (e.g. router), not the NM app. The NM app should be able to handle rearranging data for display purposes. I would like to see a discussion of the indexing wrt the device. The warnings from the MIB compiler indicate that there may be a better indexing (table structure) available. That doesn't mean that you need to resolve the warnings, but I would like to see some text included which shows why the chosen indexes are advantageous for the VRRP router, and the Virtual Routers. IMHO, if an interface goes down, then would be probably more advantageous to know the Virtual router(s) associated with that interface. (and subsequently the IP addresses on those Virtual Routers). Please combine Section 7 and Section 8. 10) Section 9. Thank you for these examples. 11) Section 10. Please specify that this is the VRRP MIB Module Definition * DATE and REVISION dates need to be updated. * VrId (Textual Convention) There is already a VrId in RFC2787. While it looks as if the only difference is the DESCRIPTION clause, need to caution against doing redefining this. I would suggest creating a VRID TC and making the DESCRIPTION simple, for example: This value uniquely identifies a Virtual Router on a VRRP router. While the remaining text is informative, it is not really necessary. Please also give a REFERENCE clause for this. * vrrpNodeVersion This scalar has correctly been deprecated, but I don't see any version object replacement in a table. Why not? (There is field in the protocol for this.) * vrrpNotificationCntl, vrrpTrapNewMasterCntl, vrrpTrapProtoErrorCntl Could notifications be generated or not, using RFC3413? *StorageType objects: If an operator configures the VRRP Router with Virtual Router(s) and IPvX addresses then I suspect that this information would be saved to nonVolatile storage. Do you agree? In other words, I'm trying to think of a scenario when an operator wouldn't want to save this information (once he/she is satisfied with the configuration) in the sake of simplification, would there be benefit to just state that the configuration should be saved to NV storage? If so, then the use of StorageType objects in this MIB could be removed and replaced with text in the Table Entry DESCRIPTION. (RFC4181, Section 4.6.4 specifies that StorageType objects can be used OR, the Table Entry DESCRIPTION clause specify what happens to dynamically-created rows after an agent restart.) * RowStatus Objects There is some discussion about having to have the corresponding Virtual Router in vrrpOperationsState have the value of 'initialize' before changing a value in the Row, and then the RowStatus object is supposed to not be "active(1)", but I don't understand what values are acceptable for modifying a read-creat object in a row? Also, how does this impact vrrpOperationsState? * NIT: AdminState and OperationsState, could these be renamed to use use AdminStatus and OperStatus? * vrrpRouterVrIdErrors Please verify that the DESCRIPTION is still valid for this MIB? Should a value be added to the Statistics Table instead (i.e. on a per Virtual Router basis? * Please refrain from using the term "trap" in the current objects/notifications. Please use the term "notification" as appropriate for the current objects/notifications. (Deprecated items are fine to leave the term trap.) * vrrpNewMasterReason, vrrpTrapProtoErrReason Where are these Enum values from? Could you add a reference? Also, please explain the values. * Conformance looks fine, but will review again once above MIB Module comments are addressed. Same with security section. Thanks, -Joan _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp Scanned by Check Point Total Security Gateway.
- [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr.… Joan Cucchiara
- Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB… Kalyan (Srinivas)Tata
- Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB… Kalyan (Srinivas)Tata
- Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB… Joan Cucchiara
- Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB… Kalyan (Srinivas)Tata
- Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB… Joan Cucchiara
- Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB… Mukesh Gupta
- Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB… Kalyan (Srinivas)Tata
- Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB… Kalyan (Srinivas)Tata
- Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB… Joan Cucchiara
- Re: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB… Kalyan (Srinivas)Tata
- Re: [VRRP] Going on Vacation 7/5 to 7/23 Kalyan (Srinivas)Tata
- Re: [VRRP] Going on Vacation 7/5 to 7/23 Joan Cucchiara