Subject: [VRRP] FW: I-D ACTION:draft-nadas-vrrp-unified-spec-00.txt

From: "Stephen Nadas (RL/TNT)" <[email-masked]>
Date: Wed, 15 Aug 2007 15:19:43 -0500

Here's a go at the unified approach.
-steve  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 4:15 PM
To: [email-masked]
Subject: I-D ACTION:draft-nadas-vrrp-unified-spec-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Virtual Router Redundancy Protocol Version 3
for IPv4 and IPv6
	Author(s)	: S. Nadas
	Filename	: draft-nadas-vrrp-unified-spec-00.txt
	Pages		: 43
	Date		: 2007-8-15
	
   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.
   IPv4 addresses and IPv6 addresses never belong to the same group,
   that is, each address family has its own set of VRRP groups.  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 2461) mechanisms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nadas-vrrp-unified-spec-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-nadas-vrrp-unified-spec-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-nadas-vrrp-unified-spec-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Steve Bates" <[email-masked]>
Date: Fri, 17 Aug 2007 09:51:29 -0600

Steve,

Overall I like the new draft, but I would like to offer a few comments:

1) In the abstract and introduction you mention VRRP groups.  I assume what
you mean by this is that within a VRRP router the virtual routers in each
address family are a domain unto themselves and do not overlap.  It might
just be me, but the word group implies some new organizational structure
that we're not really adding.  Particularly in the second paragraph of
section 3 where you mention a group number. 

2) In section 6.4.1 when we transition from the initialize state to the
backup state don't we want to set the Master_Down_Timer to the
Master_Down_Interval (not the Adver_Timer)?

3) I think we should also mention in the two cases (both from the backup and
master state) when we set the Master_Adver_Interval to Adver Interval
contained in the ADVERTISEMENT that we need to recompute the
Master_Down_Interval.

4) In section 7.1 we now have a contradiction.  Since we are accepting the
Master's advertisement interval we can no longer reject a mismatch.

5) In A.1 bullet item 2 you have a reference to VRRPv4.

Thanks,
Steve

---

From: "Stephen Nadas (RL/TNT)" <[email-masked]>
Date: Mon, 20 Aug 2007 06:57:42 -0500

Hi Steve, 

Thank you for reading and sending comments.  As to the specifics, 
please see inline.  

Regards,
Steve 

> From: Steve Bates [mailto:[email-masked]] 
> Sent: Friday, August 17, 2007 11:51 AM
> To: Stephen Nadas (RL/TNT); [email-masked]
> Subject: Comments on draft-nadas-vrrp-unified-spec-00.txt 
> 
> Steve,
> 
> 1) In the abstract and introduction you mention VRRP groups.  
> I assume what you mean by this is that within a VRRP router 
> the virtual routers in each address family are a domain unto 
> themselves and do not overlap.  It might just be me, but the 
> word group implies some new organizational structure that 
> we're not really adding.  Particularly in the second 
> paragraph of section 3 where you mention a group number. 

I agree with your point and I'm not intending any "new 
organizational sttructure"; I'll reword this to avoid the 
term. 

> 
> 2) In section 6.4.1 when we transition from the initialize 
> state to the backup state don't we want to set the 
> Master_Down_Timer to the Master_Down_Interval (not the Adver_Timer)?
> 

Yes. This appears to be a merge error on my part; I'll 
fix this. 

> 3) I think we should also mention in the two cases (both from 
> the backup and master state) when we set the 
> Master_Adver_Interval to Adver Interval contained in the 
> ADVERTISEMENT that we need to recompute the Master_Down_Interval.
> 

I see the text you mention in 6.4.2 (backup).  Unless there 
are objections, I am okay adding a bullet here to "recompute 
the Master_Down_Interval."  However, I don't find this text 
in the master state - Did you mean backup and initialize state 
(where the same text will appear once I fix previous merge error?) 

> 4) In section 7.1 we now have a contradiction.  Since we are 
> accepting the Master's advertisement interval we can no 
> longer reject a mismatch.
> 

Right.  Need to fix.  (Also looks like a merge error from 3768.) 

> 5) In A.1 bullet item 2 you have a reference to VRRPv4.

Sure, this is a typo from pasted email text.

---

From: "Steve Bates" <[email-masked]>
Date: Mon, 20 Aug 2007 09:01:23 -0600

Hi Steve,

With regard to number 4:
In section 6.4.3 when a master receives a higher priority advertisement then
the master accepts the new advertisement interval, needs to recompute the
Master_Down_Interval, and transition to backup.

Totally unrelated but far less important is the typo at 5.2.6, which should
be Rsvd.

Steve

-----Original Message-----
From: Stephen Nadas (RL/TNT) [mailto:[email-masked]] 
Sent: Monday, August 20, 2007 5:58 AM
To: Steve Bates; [email-masked]
Subject: RE: Comments on draft-nadas-vrrp-unified-spec-00.txt 

Hi Steve, 

Thank you for reading and sending comments.  As to the specifics, please see
inline.  

Regards,
Steve 

> I assume what you mean by this is that within a VRRP router the 
> virtual routers in each address family are a domain unto themselves 
> and do not overlap.  It might just be me, but the word group implies 
> some new organizational structure that we're not really adding.  
> Particularly in the second paragraph of section 3 where you mention a 
> group number.

I agree with your point and I'm not intending any "new organizational
sttructure"; I'll reword this to avoid the term. 

> 
> 2) In section 6.4.1 when we transition from the initialize state to 
> the backup state don't we want to set the Master_Down_Timer to the 

Yes. This appears to be a merge error on my part; I'll fix this. 

> 3) I think we should also mention in the two cases (both from the 
> backup and master state) when we set the Master_Adver_Interval to 
> Adver Interval contained in the ADVERTISEMENT that we need to 
> recompute the Master_Down_Interval.
> 

I see the text you mention in 6.4.2 (backup).  Unless there are objections,
I am okay adding a bullet here to "recompute the Master_Down_Interval."
However, I don't find this text in the master state - Did you mean backup
and initialize state (where the same text will appear once I fix previous
merge error?) 

> 4) In section 7.1 we now have a contradiction.  Since we are accepting 
> the Master's advertisement interval we can no longer reject a 
> mismatch.
>

---

From: "Stephen Nadas (RL/TNT)" <[email-masked]>
Date: Mon, 20 Aug 2007 10:40:51 -0500

Ok, thanks, will address these
-steve 

> Sent: Monday, August 20, 2007 11:01 AM
> In section 6.4.3 when a master receives a higher priority 
> advertisement then the master accepts the new advertisement 
> interval, needs to recompute the Master_Down_Interval, and 
> transition to backup.
> 
> Totally unrelated but far less important is the typo at 
> 5.2.6, which should be Rsvd.
> 
> Steve
> 
> Thank you for reading and sending comments.  As to the 
> specifics, please see inline.  
> 
> Regards,
> Steve 
> 
> organizational sttructure"; I'll reword this to avoid the term. 
> 
> > 
> the Master_Down_Interval."
> However, I don't find this text in the master state - Did you 
> mean backup and initialize state (where the same text will 
> appear once I fix previous merge error?) 
>