headers
Mukesh.Gupta | 2 Jul 2003 00:34
Picon

RE: Need agenda items for the IETF meeting

Hi Bob,

Sorry that your email had to wait for a while in the pending mail queue because it was probably not sent from
the email address that is subscribed to vrrp wg mailing list.

Would it be possible for any of your co-workers to prepare a small presentation on this and talk about it in
the meeting ?? We can certainly reserve a slot for this presentation. Is it possible for you to give us the
name of the person who is ready to talk about it in the meeting ?

regards
Mukesh

> -----Original Message-----
> From: ext Robert (Bob) W. Hott [mailto:hottrw <at> nswc.navy.mil]
> Sent: Thursday, June 26, 2003 3:33 PM
> To: Radia Perlman - Boston Center for Networking; vrrp <at> ietf.org
> Cc: kodonog <at> titanic.nswc.navy.mil; dmarlow <at> titanic.nswc.navy.mil;
> bchappe <at> nswc.navy.mil; tplunke <at> titanic.nswc.navy.mil; Lee S Carmichael
> Subject: Re: [VRRP] Need agenda items for the IETF meeting
> 
> 
> Radia,
>     About a month ago, there was a brief discussion about the
> granularity of the timers and proprietary solutions that use 
> sub-second
> timers. Survivability solutions, such as VRRP are of interest 
> to the US
> Navy. Selecting proprietary implementations of VRRP, or similar
> technologies, are desirable only when open standard solutions are not
> available. It would be nice to hear about proposals that
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mukesh.Gupta | 2 Jul 2003 01:08
Picon

Draft Agenda for VRRP WG meeting in IETF57th.

Folks,

Here is the draft agenda for the meeting. Please send a mail to Me or Radia in oder to add items to the agenda.

************
Virtual Router Redundancy Protocol WG (vrrp)

WEDNESDAY, July 16, 2003 at 0900-1130
=================================

CHAIRS:
Mukesh Gupta <Mukesh.Gupta <at> nokia.com>
Radia Perlman <radia.perlman <at> sun.com>

AGENDA:
Agenda Bashing		Chairs		5 mins

Milestones/Plans		Chairs		5 mins

Current Drafts's status Chairs		5 minutes

Review current VRRP	Bob Hinden		20 mins
Drafts

VRRPv3 MIB			Chairs		10 minutes

Sub-second Timers		????			15 minutes
************

regards
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 2 Jul 2003 22:34
Picon
Favicon

I-D ACTION:draft-ietf-vrrp-ipv6-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 for IPv6
	Author(s)	: R. Hinden
	Filename	: draft-ietf-vrrp-ipv6-spec-05.txt
	Pages		: 27
	Date		: 2003-7-2
	
This memo defines the Virtual Router Redundancy Protocol (VRRP) for
IPv6.  It is version three (3) of the protocol.  It is based on the
original version of VRRP (version 2) for IPv4 that is defined in
RFC2338.
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 IP address associated with a
virtual router is called the Master, and forwards packets sent to
this IP address.  The election process provides dynamic fail over in
the forwarding responsibility should the Master become unavailable.
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 Discovery [ND] mechanisms.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 2 Jul 2003 22:34
Picon
Favicon

I-D ACTION:draft-ietf-vrrp-spec-v2-08.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
	Author(s)	: R. Hinden et al.
	Filename	: draft-ietf-vrrp-spec-v2-08.txt
	Pages		: 31
	Date		: 2003-7-2
	
This memo defines the Virtual Router Redundancy Protocol (VRRP).
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 IP address(es) associated with
a virtual router is called the Master, and forwards packets sent to
these IP addresses.  The election process provides dynamic fail over
in the forwarding responsibility should the Master become
unavailable.  This allows any of the virtual router IP addresses on
the LAN to be used as the default first hop router by end-hosts.  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.
This document replaces RFC2338 'Virtual Router Redundancy Protocol'.
RFC2338 will become historic.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mukesh.Gupta | 7 Jul 2003 21:15
Picon

FW: Preparing WGs for the upcoming meeting in Vienna

FYI..

-----Original Message-----
From: ext Paul Hoffman / VPNC [mailto:paul.hoffman <at> vpnc.org]
Sent: Wednesday, June 11, 2003 9:56 AM
To: wgchairs <at> ietf.org
Subject: Preparing WGs for the upcoming meeting in Vienna

Greetings again. The meeting in Vienna in a few weeks will probably
be the first for many of the people in your WGs. A little WG-wide
nudge a few weeks before the face-to-face meeting might get more
effective results. This might be a good time to send a message to the
WG mailing list, wearing your WG hat, reminding folks:

- Newcomers can learn a lot ahead of time by reading the Tao of the
IETF at <http://www.ietf.org/tao.html>. The newcomer orientation on
Sunday (this year, at 1PM) is useful, but it is even more useful if
they have read the Tao first.

- It is a good idea to at least skim the WG archives for the past
four months before the meeting to help  prevent rehashing items that
have already been decided and to help focus on items that need more
review.

- Similarly, it is a good idea to re-read the WG's charter before the
meeting. Heck, many WG chairs could get value from this...

- Many IETF areas have area-wide meetings. People who are interested
in more than just one WG can get a feel for what is happening in
other areas by going to these meetings.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mukesh.Gupta | 7 Jul 2003 21:35
Picon

VRRP WG meeting agenda.

Virtual Router Redundancy Protocol WG (vrrp)

WEDNESDAY, July 16, 2003 at 0900-1130
=================================

CHAIRS: Mukesh Gupta <Mukesh.Gupta <at> nokia.com>
	  Radia Perlman <radia.perlman <at> sun.com>

AGENDA:
Agenda Bashing		Chairs		5 mins

Milestones/Plans		Chairs		5 mins

Current Drafts' status 	Chairs		5 minutes

Review VRRP Drafts	Bob Hinden	20 mins
http://ietf.org/internet-drafts/draft-ietf-vrrp-spec-v2-08.txt
http://ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-05.txt

VRRPv3 MIB			Chairs		10 minutes
http://ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-mib-00.txt

Sub-second Timers		Karen O'Donoghue 15 minutes

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mukesh.Gupta | 8 Jul 2003 00:24
Picon

Volunteer scribe ??

Do we have any volunteer scribe for IETF57 in the WG ??

-----Original Message-----
From: ext Marshall Rose [mailto:mrose+mtr.ietf <at> dbc.mtview.ca.us]
Sent: Monday, July 07, 2003 2:09 PM
To: wgchairs <at> ietf.org
Subject: text conferencing at ietf57

	     Remote Access for the 57th IETF meeting in Vienna:
                             Text Conferencing

At each IETF meeting, two of the working group meeting rooms are equipped
for video multicast and remote participation.  That is, for every IETF
meeting slot, two of the working groups can see and hear the
meeting. For the 57th IETF, in *addition* to the usual network A/V, text
conferencing will be provided for every working group that meets.

All of the conference rooms will be hosted on

    ietf.jabber.at

and each is named using the official IETF abbreviation found in the
agenda (e.g., "apparea",  "dhc", "forces", and so on -- for all the
examples that follow, we'll use "foobar" as the abbreviation).

Each conference room also has a 'bot which records everything that gets
sent. So, the minute taker can review this information right after the
meeting.

In addition to the conference rooms for each wg that is meeting, there
(Continue reading)

Permalink | Reply | 4 comments |
headers
Don Provan | 15 Jul 2003 02:19
Favicon

RE: I-D ACTION:draft-ietf-vrrp-spec-v2-08.txt

Sorry, nothing technical, but I couldn't help but notice that the
Author's Addresses in section 15 refer to at least two companies
that no longer exist. Perhaps it's time to refresh?
-don

> -----Original Message-----
> From: vrrp-admin <at> ietf.org [mailto:vrrp-admin <at> ietf.org]On Behalf Of
> Internet-Drafts <at> ietf.org
> Sent: Wednesday, July 02, 2003 1:34 PM
> To: IETF-Announce:
> Cc: vrrp <at> ietf.org
> Subject: [VRRP] I-D ACTION:draft-ietf-vrrp-spec-v2-08.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
> 	Author(s)	: R. Hinden et al.
> 	Filename	: draft-ietf-vrrp-spec-v2-08.txt
> 	Pages		: 31
> 	Date		: 2003-7-2
>
> This memo defines the Virtual Router Redundancy Protocol (VRRP).
> 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 IP address(es) associated with
> a virtual router is called the Master, and forwards packets sent to
(Continue reading)

Permalink | Reply | 0 comments |
headers
M. T. Hollinger | 15 Jul 2003 15:52
Picon

Virtual MAC for IPv6

The vrrp-ipv6-spec-05 draft still specifies the use of virtual MAC
addresses, even with IPv6.

I have long disliked the use of duplicate MAC addresses for v4, which was
justified with the argument that some older ARP implementations did not
properly receive and parse gratuitous ARP messages.

That argument does not apply to IPv6.  I oppose moving this document forward
until the use of virtual MAC is removed.  (Alternatively, if there is a
strong justification, then text could be added to the document explaining
why this architecturally awful design was believed to be the best choice for
the IPv6 environment.)

           - Mark

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Bob Hinden | 15 Jul 2003 17:02
Picon

Re: Virtual MAC for IPv6

Mark,

At 06:52 AM 7/15/2003, M. T. Hollinger wrote:
>The vrrp-ipv6-spec-05 draft still specifies the use of virtual MAC
>addresses, even with IPv6.
>
>I have long disliked the use of duplicate MAC addresses for v4, which was
>justified with the argument that some older ARP implementations did not
>properly receive and parse gratuitous ARP messages.
>
>That argument does not apply to IPv6.  I oppose moving this document forward
>until the use of virtual MAC is removed.  (Alternatively, if there is a
>strong justification, then text could be added to the document explaining
>why this architecturally awful design was believed to be the best choice for
>the IPv6 environment.)

I don't agree that it is so bad or as you say an "architecturally awful 
design".  I have thought about it as one of the great MAC address hacks :-)

The advantage of this approach is that it works without the hosts having to 
do anything (e.g., receive and process an ND message, update tables, 
etc.).  The switch over is transparent to the hosts.

This approach is well proven in the IPv4 version of VRRP.  It is running 
operationally in many places and I am not aware of any problems.  Are you 
aware of any technical problems with the virtual MAC address approach?

Thanks,
Bob
(Continue reading)

Permalink | Reply | 2 comments |

Gmane