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

That was just a suggestion, softening the language, since I had to think 
for a bit
if it would be permanently unstable (which I think it won't be).
But if you want it to be scary to convince people they really don't want 
to do this,
then that's fine.

Radia

don provan wrote:
> 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
>   

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