Subject: [VRRP] FW: New Version Notification for draft-ietf-vrrp-unified-spec-01

From: "Stephen Nadas" <[email-masked]>
Date: Wed, 19 Mar 2008 14:27:58 -0500

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-masked]] 
> 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-masked]
https://www.ietf.org/mailman/listinfo/vrrp

---

From: Radia Perlman <[email-masked]>
Date: Sat, 29 Mar 2008 18:51:53 -0700

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

---

From: "don provan" <[email-masked]>
Date: Sun, 30 Mar 2008 17:59:23 -0700

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-masked] [mailto:[email-masked]] On Behalf Of
Radia Perlman
Sent: Saturday, March 29, 2008 6:52 PM
To: Stephen Nadas
Cc: Venu Ullanatt; [email-masked]
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.

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

---

From: Radia Perlman <[email-masked]>
Date: Mon, 31 Mar 2008 11:11:36 -0700

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

---

From: "Don Provan" <[email-masked]>
Date: Mon, 31 Mar 2008 15:09:08 -0700

I think we're on the same page. I believe I wrote the
passage in question, and I agree that there's no
particular reason to think such configurations would
be permanently unstable. Steve can decide whether to
improve it.
-don

> From: Radia Perlman [mailto:[email-masked]]
> Sent: Monday, March 31, 2008 11:12 AM
> To: don provan
> Cc: 'Stephen Nadas'; 'Venu Ullanatt'; [email-masked]
> Subject: Re: [VRRP] FW: New Version
> Notificationfordraft-ietf-vrrp-unified-spec-01
> 
> 
> virtual IPv4 
> family of