[VRRP] FW: [RTG-DIR] RtgDir review: draft-ietf-vrrp-unified-mib-09.txt
Adrian Farrel <Adrian.Farrel@huawei.com> Thu, 28 April 2011 17:00 UTC
Return-Path: <Adrian.Farrel@huawei.com>
X-Original-To: vrrp@ietfa.amsl.com
Delivered-To: vrrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D62E0670 for <vrrp@ietfa.amsl.com>; Thu, 28 Apr 2011 10:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.742
X-Spam-Level:
X-Spam-Status: No, score=-105.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP5jOrwJJAPU for <vrrp@ietfa.amsl.com>; Thu, 28 Apr 2011 10:00:03 -0700 (PDT)
Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id 98953E06D7 for <vrrp@ietf.org>; Thu, 28 Apr 2011 10:00:03 -0700 (PDT)
Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKD008YVGK2NH@usaga03-in.huawei.com> for vrrp@ietf.org; Thu, 28 Apr 2011 12:00:02 -0500 (CDT)
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKD0080CGK01F@usaga03-in.huawei.com> for vrrp@ietf.org; Thu, 28 Apr 2011 12:00:02 -0500 (CDT)
Date: Thu, 28 Apr 2011 17:59:59 +0100
From: Adrian Farrel <Adrian.Farrel@huawei.com>
In-reply-to: <4DB989B2.4050006@joelhalpern.com>
To: vrrp@ietf.org
Message-id: <092701cc05c5$b6e503e0$24af0ba0$@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Outlook 14.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-gb
Content-transfer-encoding: 7bit
Thread-index: AQIZ8W5wLM1ZIaRTi8V/JMr7fUyUZZPXoktw
References: <4DB989B2.4050006@joelhalpern.com>
Subject: [VRRP] FW: [RTG-DIR] RtgDir review: draft-ietf-vrrp-unified-mib-09.txt
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Adrian.Farrel@huawei.com
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 28 Apr 2011 17:00:04 -0000
Hi WG This is for your information. The review forms part of the IETF last call. Thanks, Adrian > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of > Joel M. Halpern > Sent: 28 April 2011 16:37 > To: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-vrrp-unified- > mib.all@tools.ietf.org > Subject: [RTG-DIR] RtgDir review: draft-ietf-vrrp-unified-mib-09.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > > Document: draft-ietf-vrrp-unified-mib-09.txt > Reviewer: Joel Halpern > Review Date: 28-April-2011 > IETF LC End Date: 2011-05-11 > Intended Status: Proposed Standard > > Summary: I have significant concerns about this document and recommend > that the Routing ADs discuss these issues further with the authors. > > Note: The document is very readable, and quite clear on its > architecture. I appreciate that. > > Major issue: > There seems to be an architectural disconnect between this MIB and RFC > 5798. WHile I can understand the design in the MIB, and would not have > any concern if that were the design in 5798, they appear not to match. > > Specifically, Section 6.1 of RFC 5798 says that a given Virtual Router > has a Virtual Router ID (VRID) and a priority. That virtual router then > has a list of Ipv4 addresses it is associated and a list of IPv6 > addresses addresses it is associated with. There is a single priority > for the entire virtual router. (As documented, conceptually, all VRs > serve all address types, even if some of them may be configured with > only IPv4 addresses or only IPv6 addresses.) > > In contrast, the MIB document goes to great trouble to diagram the > virtual router as being dedicated to a single address family. In the > MIB, conceptually, they are two routers for a given VRID. This is shown > in the diagrams by having two different priorities for these two > different routers, and different states (master vs backup) for the two > virtual routers in the same box, even though they are using the same > VRID. This is reflected in the base keying structure of the MIB. > > For all I know, this is the actual practice in deploying the protocol. > But it is NOT what the RFC says. (And no, this can not be fixed as an > errata to RFC 5798.) > > > Minor issues: > (These assume the structure as given in the MIB. If I am correct about > the major issue needing to be addressesd, many of these will become OBE.) > In the example in section 8, in the vrrpv3AssociatedIpAddrTable for > VR1, it shows address Z as being active on rotuer VR1. However, the > diagram shows address Z as only active on VR2. (And the table for VR2 > shows Z as active there.) I presume this is a cut-and-paste error, and > the line for Z in VR1 just needs to be removed. > > I presume that there is a good reason why vrrpv3RouterChecksumErrors, > vrrpv3RouterVersionErrors, vrrpv3RouterVrIdErrors, and > vrrpv3GlobalStatisticsDiscontinuityTime do not exist per interface? (I > can understand why they are not per VRID, since with these errors, one > could not associate them with a specific VRID. But they can be > associated with a specific Interface.) > Also, whether they remain associated with the physical router, or become > a per-interface table, it would seem that they should be described in > section 7 on the structure of the MIB. This description should also > explain the scoping. > > > Nit: > Should the description of vrrpv3OperationsAcceptMode include a > REFERENCE " RFC 5798 section 6.1" > It seems odd to have one table Augment another in the same MIB document. > Is this just for human readability? > > > Yours, > Joel M. Halpern > > line?
- [VRRP] FW: [RTG-DIR] RtgDir review: draft-ietf-vr… Adrian Farrel