headers
Mukesh.Gupta | 4 Aug 2003 09:27
Picon

FW: VRRP Messages


-----Original Message-----
From:	ext Hesham Elbakoury [mailto:helbakou <at> nortelnetworks.com]
Sent:	Fri 8/1/2003 6:42 PM
To:	Gupta Mukesh (IPRG/MtView)
Cc:	
Subject:	VRRP Messages
Hi Mukesh

   I have the following questions for you regarding VRRP:

   1- When the master router responds to ARP request, does it use the
virtual MAC address of the VR
       as the source MAC address of the layer 2 header of the ARP response ?
   2- What source MAC address is used by the routers in the VR configuration
when they send VR control
       messages (e.g. advertisements).

   Thanks

   Hesham

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 1 comment |
headers
Don Provan | 5 Aug 2003 21:42
Favicon

RE: FW: VRRP Messages

>    1- When the master router responds to ARP request, does it use the
> virtual MAC address of the VR
>        as the source MAC address of the layer 2 header of the
> ARP response ?
>    2- What source MAC address is used by the routers in the
> VR configuration
> when they send VR control
>        messages (e.g. advertisements).

VR advertisements, and only VR advertisements, should be sent
with a source address in the layer two header set to the VR MAC
address.

I think there are two principle reasons for not using the VR MAC
address as the layer 2 source in any other packets. First, VR
advertisements are the only packets guaranteed to only be sent
when you own the address, so it avoids the possibility of using
it when you shouldn't. Second, you always want to be able to
identify the host that sent any given packet so you can debug
problems.
-don

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Mukesh.Gupta | 7 Aug 2003 02:59
Picon

FW: Working Group Last Call for draft-ietf-vrrp-spec-v2-08.txt

The WG last call for this draft has ended.

The only thing that needs to be fixed is the authors list (unless Bob has received any comments directly to
him). In the WG meeting in Vienna, the conclusion of the discussion was that Bob Hinden should be listed as
"editor", and a "contributors" section should be added acknowledging the others. (this can be found in
the meeting minutes)

I want to confirm this decision on the mailing list. If anyone (specially folks that are listed as authors in
the draft) has any opposition to this proposal, please respond.

If I don't see any opposition till 10th Aug, I will assume that everyone is ok with it and I will ask Bob to
submit the final version of the draft with this change.

regards
Mukesh

-----Original Message-----
From: ext Mukesh.Gupta <at> nokia.com [mailto:Mukesh.Gupta <at> nokia.com]
Sent: Tuesday, July 22, 2003 10:33 AM
To: vrrp <at> ietf.org
Subject: [VRRP] Working Group Last Call for
draft-ietf-vrrp-spec-v2-08.txt

This is a VRRP working group last call for comments on advancing the following document as a Draft Standard:

	Title		: Virtual Router Redundancy Protocol
	Author(s)	: R. Hinden, P. Hunt, D. Mitzel, P. Higginson,
			  M. Shand, A. Lindem, S. Knight, D. Weaver,
			  D. Whipple
	Filename	: draft-ietf-vrrp-spec-v2-08.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 14 Aug 2003 16:27
Picon
Favicon

I-D ACTION:draft-ietf-vrrp-spec-v2-09.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
	Filename	: draft-ietf-vrrp-spec-v2-09.txt
	Pages		: 30
	Date		: 2003-8-14
	
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-09.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 | 0 comments |
headers
Mukesh.Gupta | 15 Aug 2003 19:42
Picon

Subsecond Timers for VRRPv3

Folks,

In the WG meeting in Vienna, we all agreed that the 
sub-second timers should be allowed at least in VRRPv3 
but we couldn't agree about the granularity of the 
advertizing interval for allowing them.

There were concerns that if we allow the advertizing
intervals in miliseconds, it will allow the user to
bombard the LAN with VRRP packets which is dangerous.

Advertizing intervals in the units of 1/10 seconds
or 1/100 seconds seemed like good choices.

We would like to know what is everyone's opinion 
about this. Please reply with your preference.

1) 1/10 second
2) 1/100 second
3) 1/1000 second (miliseconds)

regards
Mukesh

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

Permalink | Reply | 2 comments |
headers
Ben Black | 15 Aug 2003 20:30

Re: Subsecond Timers for VRRPv3

It would be especially short-sighted to use coarse-grained timers.  I
don't see a problem with millisecond resolution.

Also, keeping people from doing something stupid, like setting the timers
to 1ms on a 10Mb/s LAN, would seem like an implementation decision, not the
sort of thing that should be built into the protocol.

Ben

On Fri, Aug 15, 2003 at 12:42:39PM -0500, Mukesh.Gupta <at> nokia.com wrote:
> Folks,
> 
> In the WG meeting in Vienna, we all agreed that the 
> sub-second timers should be allowed at least in VRRPv3 
> but we couldn't agree about the granularity of the 
> advertizing interval for allowing them.
> 
> There were concerns that if we allow the advertizing
> intervals in miliseconds, it will allow the user to
> bombard the LAN with VRRP packets which is dangerous.
> 
> Advertizing intervals in the units of 1/10 seconds
> or 1/100 seconds seemed like good choices.
> 
> We would like to know what is everyone's opinion 
> about this. Please reply with your preference.
> 
> 1) 1/10 second
> 2) 1/100 second
> 3) 1/1000 second (miliseconds)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Radia Perlman - Boston Center for Networking | 15 Aug 2003 20:52
Picon

And subsecond timers for IPv4

Doing it for v3 is straightforward, since there's no
compatibility issue, and as Mukesh's note says, the only
issue is what the units should be.

The other issue is whether to make a new version of VRRP for IPv4
that uses subsecond timers.

The issues for that are:

1) what is the encoding of the field, given that it can't be
expanded beyond a byte. I think it was Bill Fenner at the meeting
that said that some spec or another did some exponential type encoding,
and that we might as well copy something someone else has done. If someone
can give a pointer to that, that would be helpful.

2) how to (and whether to) mix VRRP-for-IPv4 routers that only do
units of seconds with ones that do subseconds.

Let's say we want to do this...where the new guys would like to use
subsecond granularity, but will be willing to only be seconds if there's
a VRRPv2 router on the link.

So how do they do this? They could send a new version number (let's say 4),
and it won't confuse the old guy (the spec says it must discard it).
However, if there is an old guy, that means that the new guys have to
speak v2, in units of seconds. Presumably they know an old
guy is there because they see a VRRP message with version=2.
Suppose someone upgrades the last
old guy. How will the new guys know that their neighbors are really new
guys even though those neighbors are emitting v2 messages?
(Continue reading)

Permalink | Reply | 2 comments |
headers
danny mitzel | 15 Aug 2003 21:58
Picon
Favicon

Re: Subsecond Timers for VRRPv3

--- Mukesh.Gupta <at> nokia.com wrote:
> In the WG meeting in Vienna, we all agreed that the 
> sub-second timers should be allowed at least in
> VRRPv3 

since I missed the working group meeting and
didn't see explicit justification for this decision
in the meeting minutes I'm wondering if someone
could summarize the justification for this feature?

I don't have the paper right here in front of
me, but the original vrrpv2 design incorporated
findings from the higginson&shand DEC TR referenced
in the RFC.  a simple picture showing 
a generalized internetwork, illustrating where
failures could occur in end-to-end connectivity,
and then expected recovery interval for typical
IETF standardized protocols.  basically illustrated
that protocol recovery on the order of seconds
was inline with Internet standards.

have these findings changed?  is there a movement
toward end-to-end connectivity containing only
vrrp ``routing'' and L2 with transparent, sub-second
recovery?

later,danny

__________________________________
Do you Yahoo!?
(Continue reading)

Permalink | Reply | 0 comments |
headers
danny mitzel | 15 Aug 2003 22:07
Picon
Favicon

Re: And subsecond timers for IPv4

--- Radia Perlman - Boston Center for Networking
<Radia.Perlman <at> Sun.COM> wrote:
> I think it was Bill Fenner at the meeting
> that said that some spec or another did some
> exponential type encoding, and that we might 
> as well copy something someone else has done. 
> If someone can give a pointer to that, that 
> would be helpful.

look at the igmpv3 rfc3376.  membership query
message max response time (secton 4.1.1) or
querier interval (section 4.1.7).  these fields
actually encode both a linear range of values
and an exponential encoding based on a flag bit.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Mathur Sonum-CSM109 | 15 Aug 2003 22:10

RE: Subsecond Timers for VRRPv3


We are in favor of 1/10 second. It is definitely a good idea to include this in the new version of VRRP for IPv4
and get it standardised. One suggestion to do this is to use one of the unused bits in the packet. The bit
setting can indicate that the units in Advert Int are in seconds or in 1/10th of second. 

--
Sonum

> -----Original Message-----
> From: Mukesh.Gupta <at> nokia.com [mailto:Mukesh.Gupta <at> nokia.com]
> Sent: Friday, August 15, 2003 10:43 AM
> To: vrrp <at> ietf.org
> Subject: [VRRP] Subsecond Timers for VRRPv3
> 
> 
> Folks,
> 
> In the WG meeting in Vienna, we all agreed that the 
> sub-second timers should be allowed at least in VRRPv3 
> but we couldn't agree about the granularity of the 
> advertizing interval for allowing them.
> 
> There were concerns that if we allow the advertizing
> intervals in miliseconds, it will allow the user to
> bombard the LAN with VRRP packets which is dangerous.
> 
> Advertizing intervals in the units of 1/10 seconds
> or 1/100 seconds seemed like good choices.
> 
> We would like to know what is everyone's opinion
(Continue reading)

Permalink | Reply | 0 comments |

Gmane