[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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 []) 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 []) 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


This is for your information. The review forms part of the IETF last call.


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