Adrian Farrel | 2 Dec 2009 23:06
Favicon

Re: Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec

Dan has gone all silent on us. :-)

Stephen, there was one action that had not been done - moving text from the 
appendix to the Operational Issues section.

Can I suggest you do this in a new revision (unless you want to give me some 
text to include as an RFC Editor note) and then we will have a perfect hand 
with which to beat Dan.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <Adrian.Farrel <at> huawei.com>
To: "Stephen Nadas" <stephen.nadas <at> ericsson.com>; <dromasca <at> avaya.com>
Cc: <Radia.Perlman <at> Sun.COM>; <vrrp <at> ietf.org>; <iesg <at> ietf.org>; "Mukesh 
Gupta" <mukesh <at> juniper.net>
Sent: Wednesday, November 25, 2009 9:54 PM
Subject: Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec

> Hi Dan,
>
> Just trying to chase you as the holder of the last Discuss on 
> draft-ietf-vrrp-unified-spec.
>
> A new revision (-04) was posted on 23 October to address other Discusses 
> and it includes the resolutions noted below. One issue remains for your 
> agreement and would need a further revision.
>
> Here are your Discuss and Comment with responses (thanks to Stephen).
>
(Continue reading)

Romascanu, Dan (Dan | 3 Dec 2009 12:37
Favicon

Re: Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec

I apologize for the delay. The changes are good, and they answer my
concerns. I am clearing my DISCUSS trusting that the last editorial
actions of moving text from the appendix to the Operational Issues
section will be performed as advised by Adrian. 

Thank you for addressing my concerns. 

Regards,

Dan

> -----Original Message-----
> From: Adrian Farrel [mailto:Adrian.Farrel <at> huawei.com] 
> Sent: Thursday, December 03, 2009 12:07 AM
> To: Stephen Nadas; Romascanu, Dan (Dan)
> Cc: Radia.Perlman <at> Sun.COM; vrrp <at> ietf.org; iesg <at> ietf.org; Mukesh Gupta
> Subject: Re: Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec
> 
> Dan has gone all silent on us. :-)
> 
> Stephen, there was one action that had not been done - moving 
> text from the appendix to the Operational Issues section.
> 
> Can I suggest you do this in a new revision (unless you want 
> to give me some text to include as an RFC Editor note) and 
> then we will have a perfect hand with which to beat Dan.
> 
> Thanks,
> Adrian
> ----- Original Message -----
(Continue reading)

Stephen Nadas | 3 Dec 2009 16:13
Picon
Favicon

Re: Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec

Hi Dan, Adrian, 

Thanks!  I just posted -05 w/this change. 

Regards,
Steve  

SJN> -----Original Message-----
SJN> From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com] 
SJN> Sent: Thursday, December 03, 2009 6:37 AM
SJN> To: Adrian Farrel; Stephen Nadas
SJN> Cc: Radia.Perlman <at> Sun.COM; vrrp <at> ietf.org; iesg <at> ietf.org; 
SJN> Mukesh Gupta
SJN> Subject: RE: Dan's Discuss and Comment on 
SJN> draft-ietf-vrrp-unified-spec
SJN> 
SJN> I apologize for the delay. The changes are good, and they 
SJN> answer my concerns. I am clearing my DISCUSS trusting that 
SJN> the last editorial actions of moving text from the 
SJN> appendix to the Operational Issues section will be 
SJN> performed as advised by Adrian. 
SJN> 
SJN> Thank you for addressing my concerns. 
SJN> 
SJN> Regards,
SJN> 
SJN> Dan
SJN>  
SJN> 
SJN> > -----Original Message-----
(Continue reading)

Internet-Drafts | 3 Dec 2009 16:15
Picon
Favicon

I-D Action:draft-ietf-vrrp-unified-spec-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF.

	Title           : Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6
	Author(s)       : S. Nadas
	Filename        : draft-ietf-vrrp-unified-spec-05.txt
	Pages           : 41
	Date            : 2009-12-03

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.
(Continue reading)

The IESG | 16 Dec 2009 18:29
Picon
Favicon

Protocol Action: 'Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6' to Proposed Standard

The IESG has approved the following document:

- 'Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6 '
   <draft-ietf-vrrp-unified-spec-05.txt> as a Proposed Standard

This document is the product of the Virtual Router Redundancy Protocol Working Group. 

The IESG contact persons are Adrian Farrel and Ross Callon.

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

Technical Summary

   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
(Continue reading)


Gmane