Subject: Re: vrrpOperProtocol attribute

From: Scott Barvick <[email-masked]>
Date: Tue, 14 Apr 1998 13:25:29 -0400

Acee Lindem wrote:
>
> Scott Barvick wrote:
> >
> > >From the DECnet VRRP discussion and other ideas about the use of VRRP,
> > it seems that we might need a vrrpOperProtocol attribute to distinguish
> > among various protocols which might be backed up through VRRP.
> >
> > How about:
> >
> > vrrpOperProtocol OBJECT-TYPE
> >    SYNTAX   INTEGER {
> >        ip (1),
> >        bridge (2),
>
> There are already host-transparent mechanisms for multiple bridge paths
> to back one another up.
>
> >        DECnet (3),
> >        other (4)
> >    }
> >    MAX-ACCESS read-create
> >    STATUS     current
> >    DESCRIPTION
> >        "The particular protocol being controlled by this Virtual
> >         Router."
> >    DEFVAL { ip }
> >    ::= {vrrpOperEntry X}
> >
> > --
>
> I think this is going overboard since to do it consistently you'd need
> to associate addresses from the non-IP protocols to a VRID. This
> wouldn't preclude a vendor from using VRRP "router-awareness" to
> provide backup of other protocols - it just keeps it out of the
> base specificaition.

We certainly would want to not specify anything beyond IP in
the base spec, and I'm sure we would never actually go any further
in the IETF on support for other protocols.

However, people will use the "router-awareness" for other things
and it would be nice to have a way to note this in the standard MIB
so that those who are looking at the operation of VRRP will not be
confused by a VR in the MIB that isn't doing quite what it would be
doing if it were managing IP.

-- 
Scott Barvick
[email-masked]
(978) 952-6000 x162

---

From: Brian Jewell <[email-masked]>
Date: Fri, 17 Apr 1998 13:40:51 -0700 (PDT)

>> 
>>[...]
>> 
>> I don't disagree that VRRP awareness could be used for other applications.
>> I just don't think adding this one MIB varibable does much for you. To
>> do it right, a separate draft would be required for the interaction with
>> each protocol. I might envision one way this would work with a non-IP
>> protocol and you might envision another.
>> 
>> However, if I'm in the minority here and it is added I think it should be
>> part of the index for the vrrpOperTable to allow a single VRID to control
>> multiple applications.

>I'm agree that each new application would need a separate draft or
>something outside the base VRRP spec.  What the value buys you now is
>that base VRRP MIB doesn't change when we decide to support redundant
>NATs through VRRP, and the way this is indicated fits nicely with how
>DEC has represented its (proprietary?) DECnet support on a VR (my
>assumption of course).

>I agree that the protocol *should* be part of the index, but with 255
>VRs per LAN, I'd vote for less complexity by not having it as part of
>the index with the requirement that you don't reuse VRs for different
>protocols on the same LAN.  If we feel that we can't do this, I'd say
>forget the whole thing because I wouldn't want to burden the majority of
>VRRP usage and implementation with another index parameter. 

I would agree with Scott's comments as shown above. Originally (as first 
proposed), this object was relatively transparent with respect to the VRRP MIB. 
Which was o.k., because (as has been pointed out), the implications of a 
"vrrpOperProtocol" object go beyond the scope of the VRRP draft. 

If this object becomes an index into the vrrpOperTable, it takes on a whole new 
significance which, in my mind, is difficult to justify for an area that has not 
been addressed in the VRRP Spec. This would mean that every net management 
application that wishes to obtain information from the VRRP MIB suddenly has to 
be aware of a new attribute about a virtual router.

If and when VRRP is expanded to incorporate other protocols, my guess is that 
the MIB will be substantially different as to require a new MIB RFC.

Thanks.

-Brian Jewell
-3Com, Inc.

------------- End Forwarded Message -------------