Re: VRRPv3 Implementation Report

[speaking as a WG member]

The Nokia Security Appliances that I worked on quite a while back also
allowed the management operations using the VR IP addresses. The support
was added because some customers asked for it.

The same Nokia appliances also allowed the operators to use the virtual
IP address of a IP Cluster (not VRRP but similar protocol) as the
service end point for routing protocols (e.g. OSPF, RIP, BGP). So I
think this use of the VR IP address should be considered valid.

What do others think?

Regards
Mukesh

-----Original Message-----
From: don provan [mailto:dprovan <at> bivio.net] 
Sent: Thursday, October 30, 2008 12:28 PM
To: 'Lin Tao'; Mukesh Gupta
Cc: vrrp <at> ietf.org; wangju <at> h3c.com
Subject: RE: [VRRP] VRRPv3 Implementation Report

Thanks for the info. That's just what I was looking for.

I think the management issues are a matter of taste, so we don't
need to go over that any more: I say management operations using
the VR IP address tend to obscure reality and other approaches
give a clearer picture, but you find using the VR IP address for
managing/monitoring the network is useful.

The part about tunneling brings up a different point for us to
consider: should VR IP addresses be used as service end points?
I've never given that any thought. What's the group wisdom about
that? Does it matter whether the service is part of the routing
infrastructure, as in this case? In this use of the VR IP
address valid, and, if so, is it important enough to force
implementations to support or even, as Lin is suggesting, always
do ACCEPT_MODE?

-don

> -----Original Message-----
> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org]On Behalf Of
> Lin Tao
> Sent: Tuesday, October 21, 2008 7:50 PM
> To: don provan; 'Mukesh Gupta'
> Cc: vrrp <at> ietf.org; wangju <at> h3c.com
> Subject: Re: [VRRP] VRRPv3 Implementation Report
> 
> 
> Don,
> 
> The simplest requirement is "PING" that used to test the connectivity 
> of the gateway by the end user or network operator.
> 
> When the VRRP is implemented, the network is mostly stable, the 
> VR switchover is short and unusually. So the operator can take VRRP
>  IP when he only need a simply operator such as looking at routing
>  table or cpu usage of the Master router.
> 
> A new requirement of VRRP IP is TUNNEL. We can use the VRRP
> IP as the source of TUNNEL, so that the peer node couldn't see the 
> switchover. We also know that the packet must be sent to the IP Stack
> in TUNNEL forward for encapsulation or decapsulation.
> 
> Lin.
> 
> ----- Original Message ----- 
> From: "don provan" <dprovan <at> bivio.net>
> To: "'Lin Tao'" <lint <at> h3c.com>; "'Mukesh Gupta'" 
> <mukesh.gupta <at> tropos.com>
> Cc: <wangju <at> h3c.com>; <vrrp <at> ietf.org>
> Sent: Tuesday, October 21, 2008 2:45 AM
> Subject: RE: [VRRP] VRRPv3 Implementation Report
> 
> 
> >> FYI: The requirement of VRRP IP's operation is really offered 
> >> by our customer. There are layers management of network.
> > 
> > Lin,
> > 
> > Perhaps you should tell us more about this requirement, then.
> > The management techniques I've seen over the years always
> > involve managing physical nodes to insure they are operating
> > as expected or accessing services to make sure they are
> > performing correctly. In VRRP, the former is accomplished
> > by using an address actually owned by the box, and the latter
> > is accomplished by confirming that packet forwarding is
> > operating *through* the box, perhaps by pinging or otherwise
> > accessing *an external* address.
> > 
> > You apparently are seeing a third possibility revealed by
> > VRRP that involves accessing a virtual node for reasons
> > *other* than using the virtual service it is providing,
> > so I think it's important for us to all understand the
> > requirement that calls for that.
> > 
> > -don
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp