Re: FW: New Version Notificationfor draft-ietf-vrrp-unified-spec-01

Do we need to go into details?

"Higher priority routers SHOULD NOT be configured with
slower transmission rates than lower priority backup
routers."

The intent of the passage was too suggest such
configurations might actually be dangerous, but the
real point is that they're pointless: there's really
no legitimate reason I can think of that a failure
of the highest priority router should cause a
*reduction* in the time-to-failover between lower
priority routers.
-don

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Radia Perlman
Sent: Saturday, March 29, 2008 6:52 PM
To: Stephen Nadas
Cc: Venu Ullanatt; [email protected]
Subject: Re: [VRRP] FW: New Version Notificationfor
draft-ietf-vrrp-unified-spec-01

I read the document and I think it is excellent and ready for last call. 
There were a couple of insignificant
typos here and there, not worth mentioning, for instance, a few lines before
section 5 it says "the details of a load balancing"
where the "a" should be removed....as I said...not worth mentioning.

There was one place though (section 5.2.7) where you say
   "Note that higher priority Master routers with slower transmission
   rates than their Backup routers are unstable.  This is because low
   priority nodes configured to faster rates could come online and
   decide they should be masters before they have heard anything from
   the higher priority master with a slower rate."

I think the wording might be unnecessarily scary. It might be nice to add an
extra sentence saying "Note that this situation is only temporary. As soon
as the lower priority node hears the VRRP message of the Master, the lower
priority node will cease attempting to be master, until the actual Master
goes down."

Radia

Stephen Nadas wrote:
> Hi Mukesh and Radia,
>
> I have just posted -01 addressing the comments received on the list 
> (and a couple of small things we found ourselves.)  I think this 
> version is ready for WG last call.
>
> Thanks,
> Steve
>
>   
>> -----Original Message-----
>> From: IETF I-D Submission Tool [mailto:[email protected]]
>> Sent: Wednesday, March 19, 2008 3:24 PM
>> To: Stephen Nadas
>> Subject: New Version Notification for draft-ietf-vrrp-unified-spec-01
>>
>>
>> A new version of I-D, draft-ietf-vrrp-unified-spec-01.txt has been 
>> successfuly submitted by Stephen Nadas and posted to the IETF 
>> repository.
>>
>> Filename:	 draft-ietf-vrrp-unified-spec
>> Revision:	 01
>> Title:		 Virtual Router Redundancy Protocol 
>> Version 3 for IPv4 and IPv6
>> Creation_date:	 2008-03-19
>> WG ID:		 vrrp
>> Number_of_pages: 44
>>
>> Abstract:
>> This memo defines the Virtual Router Redundancy Protocol (VRRP) for
>> IPv4 and IPv6.  It is version three (3) of the protocol and it is 
>> based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and on 
>> draft-ieft-vrrp-ipv6-spec-08.txt.  VRRP specifies an election 
>> protocol that dynamically assigns responsibility for a virtual router 
>> to one of the VRRP routers on a LAN.  The VRRP router controlling the
>> IPv4 or IPv6 address(es) associated with a virtual router is called 
>> the Master, and forwards packets sent to these IPv4 or
>> IPv6 addresses.  VRRP Master routers are configured with virtual IPv4 
>> or
>> IPv6 addresses and VRRP Backup routers infer the address family of 
>> the virtual addresses being carried based on the transport protocol.
>> Within a VRRP router the virtual routers in each of the IPv4 and IPv6 
>> address families are a domain unto themselves and do not overlap.
>> The election process provides dynamic fail over in the forwarding 
>> responsibility should the Master become unavailable.  For IPv4, the 
>> advantage gained from using VRRP is a higher availability default 
>> path without requiring configuration of dynamic routing or router 
>> discovery protocols on every end-host.  For IPv6, the advantage 
>> gained from using VRRP for IPv6 is a quicker switch over to back up 
>> routers than can be obtained with standard IPv6 Neighbor Discover 
>> (RFC 4861) mechanisms.
>>                                                               
>>                     
>>
>>
>> The IETF Secretariat.
>>
>>
>>
>>     
> _______________________________________________
> vrrp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/vrrp
>   

_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp

_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp