Subject: Re: vrrpOperProtocol attribute

From: Brian Jewell <[email-masked]>
Date: Wed, 15 Apr 1998 08:39:05 -0700 (PDT)

Response is at the bottom.

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

Response:

I don't see any problem here about including such an object in the 
vrrpOperTable. 

>From the emails that have been exchanged, I have gleaned one possible concern: 
With a protocol such as Decnet, which apparently assigns it own MAC address,  
the choice of VRID's would be limited. Thus, screwing up the vrrpOperTable VRID 
index??

Let me know if I am interpreting this correctly and if it is a valid concern. 
Otherwise I will include this object in the next MIB revision.

Thanks.

-Brian

---

From: Acee Lindem <[email-masked]>
Date: Thu, 16 Apr 1998 17:25:01 -0400

> the choice of VRID's would be limited. Thus, screwing up the vrrpOperTable VRID

Maybe I'm confused. However, my take is that the only way you can use VRRP for
DECnet (on any other non-IP protocol) is to have the VRRP state transitions internally
signal these protocols to forward or cease-forwarding for a given non-IP protocol
address. Hence, the fact that DECnet changes the hardware MAC address is an othogonal
issue (you'd simply have to have hardware or promiscuous filtering to receive packets
addressed to both the VRID virtual addresses and the DECnet MAC addresses). 

Given that the above is correct, my point was that since this shouldn't 
be in the MIB since it must be done outside the scope of VRRP (VRRP doesn't 
maintain state for non-IP protocols nor does it addvertise non-IP protocol 
addresses).

Thanks,  

-- 
Acee

---

From: Scott Barvick <[email-masked]>
Date: Fri, 17 Apr 1998 08:44:57 -0400

Acee Lindem wrote:
...
> maintain state for non-IP protocols nor does it addvertise non-IP protocol

I agree with the assessment that it would take modifications to some
portion of the VRRP state machine to have it control other protocols.  
To me the state machine implementation is the smallest part of building
an application such as VRRP.  The configuration, infrastructure, other
system hooks tend to take more time than coding up the final state table
and resulting actions.  

Therefore, the question for us is "do we want VRRP to be extensible?" 
My view is that VRRP can be a general mechanism for "router aliveness",
and there will be a desire to have a redundancy mechanism for different
applications.  Some of these may be non-IETF (DECnet, IPX, bridge), and
if they were the only cases, there might be a philosophical issue
concerning using an IETF IP MIB to indicate that the IETF IP protocol
was being used with non-IETF non-IP protocols. I'd still put it in
because it will make the IETF MIB more accurate when monitoring VRRP
when it is used for other purposes.  However, it is possible that this
fairly generic mechanism could be used for IP based operations beyond
simple address redundancy.  

One is NAT backup/redundancy.  There may be work undertaken in the NAT
working group to do something across routers.  Given that NAT doesn't
have any protocol mechanisms of its own, I can see that VRRP might be
the interrouter communication mechanism of choice.  The vrrpOperProtocol
= NAT could signal a pool (an possibly even a WAN link) to be activated
when a backup router transitions to the master state.  

The state machines might be somewhat or even very different.  Is that
still VRRP, I think it can be if that's how we end up defining - or
specifically not defining- operations based on different
vrrpOperProtocol values.

An I still vote for defined values for current non-IP protocols
including DECnet, IPX, and bridge.  At the very least, a
"VENDOR-SPECIFIC" range could be used.

Scott

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

---

From: Acee Lindem <[email-masked]>
Date: Fri, 17 Apr 1998 13:03:35 -0400

> specifically not defining- operations based on different

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. 

> including DECnet, IPX, and bridge.

If this MIB value is added, why is "bridge" required? TB, SRB, and SRT 
all have host-transparent mechanisms to provide redundant paths. 

>   At the very least, a

-- 
Acee

---

From: Scott Barvick <[email-masked]>
Date: Fri, 17 Apr 1998 14:39:43 -0400

Acee Lindem wrote:
>[...]

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. 

> all have host-transparent mechanisms to provide redundant paths.

I included it for completeness.  I can see implementions that have VRRP
but no Spanning Tree quickly modifying the VRRP state machines to
support bridging. This would obviously be proprietary, but I've seen
worse done out there:)

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