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

Hi WG

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

Thanks,
Adrian

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Joel M. Halpern
> Sent: 28 April 2011 16:37
> To: [email protected]; [email protected]; draft-ietf-vrrp-unified-
> [email protected]
> 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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp