Subject: [RTG-DIR] RtgDir review: draft-ietf-vrrp-unified-mib-09.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Apr 2011 11:37:22 -0400

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?