Re: draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review

Hi Joan,
Sorry for the delay (The usual got busy excuse :) ). I started on the edits for new draft and would like your
comments/input on the following. Also as I started to edit, I needed some clarifications on your earlier
input. 

This would be the new draft name: draft-ietf-vrrp-v3-mib-00.txt 

I also have to get an IANA assigned OID under mib-2.

VRRPv3-MIB DEFINITIONS ::= BEGIN
   Vrrpv3MIB  MODULE-IDENTITY
   . . 
   ::= { mib-2 ZZZ } 

    -- EdNote: Please replace ZZZ with a real OID once it is 
    -- allocated and remove this note.

I will have an IANA considerations section. 
[Kalyan>] Is this OK?
[Kalyan>] Also, I am using the same group/table names as the previous draft - I think that should be OK. Just
want to confirm with you. 

I also have some questions on your earlier comments: 

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

Re: draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review

> ----- Original Message ----- 
> From: "Kalyan (Srinivas)Tata" <stata <at> checkpoint.com>
> To: "Joan Cucchiara" <jcucchiara <at> mindspring.com>; "Adrian Farrel"
> <Adrian.Farrel <at> huawei.com>; <tata_kalyan <at> yahoo.com>; <vrrp <at> ietf.org>
> Cc: "MIB Doctors (E-mail)" <mib-doctors <at> ietf.org>;
> <vrrp-chairs <at> tools.ietf.org>; <draft-ietf-vrrp-unified-mib <at> tools.ietf.org>
> Sent: Thursday, June 10, 2010 3:34 PM
> Subject: RE: [VRRP] draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review
>

Hi Kalyan,

>
> Hi Joan,
> Sorry for the delay (The usual got busy excuse :) ). I started on the 
> edits
> for new draft and would like your comments/input on the following. Also as 
> I
> started to edit, I needed some clarifications on your earlier input.
>

No problem.  Thanks for following up.  Better to get all the comments 
clarified
prior to updating.

> This would be the new draft name: draft-ietf-vrrp-v3-mib-00.txt

I would leave it as "draft-ietf-vrrp-unified-mib" and continue to bump the
number.  That way it will match the "draft-ietf-vrrp-unified-spec".
Also, eventually it will get an RFC number.

Re: draft-ietf-vrrp-unified-mib-07.txt MIB Dr. Review

Thanks Joan,
	Most of the comments are clear to me now. I Will try to finalize the draft this week.

>
> [Kalyan>] Shell I go ahead and change the order of indexing to ifindex,
> VrId, AddrType?
>

Yes.  Those indexes uniquely identify the vr, so essentially, the tables are 
listed
by vr.   Please note, this is only a suggestion/proposal and the indexing is 
upto the
WG.  I didn't see any comments about this during Last Call, so as far as I'm 
aware
this is good with the WG, right?

[Kalyan>] I did not see any comments either. So I will change the indexing.

>
> * 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.

Static routes are effected when vrrp is enabled

Hi All,

When we configure VRRP on eth1. Static route on eth1 are removed from kerneland when we remove VRRP entry
from eth1. static route are not added again. 

Is this the problem ??? Please get me back.

      

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

Re: Going on Vacation 7/5 to 7/23

[Kalyan>] Hi Joan,
I am CCing the WG to get any input on the following. 

5) I think I asked about these before, the accessible-for-notify scalar 
objects
could become part of the Statistics table (as part of the row's objects)
and I think this proabably gives more
information (for example, if the notifications are disabled, then an 
operator will
still be able to see these "Reason" values).  There may need to be an 
additional
enum added, e.g. to vrrpv3ProtoErrReason, noError(0), etc..

I would encourage that this be considered.

[Kalyan>] Following are two descriptions. Please comment.

   vrrpv3StatisticsNewMasterReason OBJECT-TYPE 
        SYNTAX        INTEGER {
            notmaster (0), 
            priority  (1), 
            preempted (2), 
            masterNoResponse (3) 
        } 
        MAX-ACCESS   read-only 
        STATUS       current 
        DESCRIPTION 
            "This indicates the reason for the virtual router to transition to MASTER state. If the virtual router
never transitioned to master state, this should be set to notmaster(0). Otherwise this indicates the