headers
Steve Bates | 10 Jan 2008 22:37
Favicon

Comments on draft-ietf-vrrp-unified-spec-00

Steve and list,

A few comments on the unified spec.  I'll break them into two separate
posts.  The first contains (hopefully) relatively insignificant editorial
changes.

1) In section 1.3, paragraph 4, the last sentence, we have a superfluous
"a".

2) In section 3, paragraph 2, we have the "group" terminology that I
referenced in comments back in August.  It has been removed from the
abstract and introduction but remains here.  I still think it needs to be
rephrased to eliminate references to groups.

3) In section 6.4.3, when a master transitions to backup based on the
receipt of a higher priority advertisement, I think we should add a bullet
between "Cancel the Adver_Timer" and "Recompute the Master_Down_Interval"
saying "Set Master_Adver_Interval to Adver Interval contained in the
ADVERTISEMENT". 

4) At the very end of section 8.2.2 we have a superfluous "(".

5) In section 9.2 in the paragraph following the two bullet items we have
this sentence "The functional addresses addresses......"

6) In the second to last paragraph of section 9.2 we have some mangled
syntax "...these implementations need have to receive...."

The last two may be too historic to fix!  I confess, I don't give section 9
much attention.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Steve Bates | 10 Jan 2008 22:41
Favicon

draft-ietf-vrrp-unified-spec-00 issues

Two issues:

Back when Bob Hott first proposed the subsecond failover draft I raised the
issue of futureproofing VRRP and I would like to raise it again now.  We are
seeing more and more requests to support rates of failure detection this
draft addresses but it seems likely that in another decade, with terabit
speed links for example, that we will see demands for failure detection 100
times faster than we currently address.  Utilizing the bits in the rsvd
field of the packet to define granularity, an inverse log function could be
used to represent granularity from 10**0 to 10**-15 (where the negative of
the field value is the exponent) giving us an insanely fine granularity.
This would help us avoid generating a new RFC when faster failure detection
rates are required.  If it weren't for the version field it might also help
with migration since a packet with a granularity of 0 would look identical
to the v2 packet (assuming authentication is off the table) and the
advertisement interval would mean the same thing (seconds). 

The second issue involves a backup virtual router accepting a masters
advertising interval.  It would be interesting to know why RFC 2338 didn't
do this in the first place.  Was it for simplicity or just oversight?  As
proposed this represents a pretty one sided negotiation.  For a backup on a
device lacking horsepower or resources a master sending advertisements every
centisecond might as well be initiating a denial of service attack.  A
clever backup might reject the faster rate and instead become master and
send advertisements at its maximum acceptable rate.  An equally clever
master would notice that it keeps getting advertisements from a lower
priority virtual router and adjust its rate appropriately until the backup
submits.  A granularity field might be a better way to accomplish this.  

Steve
(Continue reading)

Permalink | Reply | 12 comments |
headers
Stephen Nadas | 11 Jan 2008 00:13
Picon
Favicon

RE: Comments on draft-ietf-vrrp-unified-spec-00

Hi Steve, 

Thanks for these comments; I will plan to fix them in next rev. 

Cheers,
Steve  

> -----Original Message-----
> From: Steve Bates [mailto:Steve.Bates <at> alcatel-lucent.com] 
> Sent: Thursday, January 10, 2008 4:38 PM
> To: Stephen Nadas; vrrp <at> ietf.org
> Subject: Comments on draft-ietf-vrrp-unified-spec-00
> 
> Steve and list,
> 
> A few comments on the unified spec.  I'll break them into two 
> separate posts.  The first contains (hopefully) relatively 
> insignificant editorial changes.
> 
> 1) In section 1.3, paragraph 4, the last sentence, we have a 
> superfluous "a".
> 
> 2) In section 3, paragraph 2, we have the "group" terminology 
> that I referenced in comments back in August.  It has been 
> removed from the abstract and introduction but remains here.  
> I still think it needs to be rephrased to eliminate 
> references to groups.
> 
> 3) In section 6.4.3, when a master transitions to backup 
> based on the receipt of a higher priority advertisement, I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Provan | 11 Jan 2008 00:54
Favicon

RE: draft-ietf-vrrp-unified-spec-00 issues

> The second issue involves a backup virtual router accepting a masters
> advertising interval.  It would be interesting to know why RFC 2338 didn't
> do this in the first place.  Was it for simplicity or just oversight?  As
> proposed this represents a pretty one sided negotiation.  For a backup on a
> device lacking horsepower or resources a master sending advertisements every
> centisecond might as well be initiating a denial of service attack.  A
> clever backup might reject the faster rate and instead become master and
> send advertisements at its maximum acceptable rate.  An equally clever
> master would notice that it keeps getting advertisements from a lower
> priority virtual router and adjust its rate appropriately until the backup
> submits.  A granularity field might be a better way to accomplish this.  

It *is* a one sided negotiation: the user configures the
higher priority router's timeout interval specifically to
control when the *backup* will take over. The user's decision
has to be based on the abilities of the backup system to
actually take over in the configured amount of time. It is
just a fluke of the protocol that that amount of time has to
be configured on the *failing* system.

It makes very little sense to me to build into the protocol
a procedure to second guess the user's decision about the fail
over requirements of the virtual router.

To me, this all becomes clearer when I consider what it really
means when two routers have different intervals configured. The
interval of the lower priority router means *nothing whatsoever*
to the speed of failover *to* that router: it *only* controls
how fast a yet lower priority router will take over from the
middle backup. The lack of symmetry in the intervals is easy to
(Continue reading)

Permalink | Reply | 11 comments |
headers
Steve Bates | 11 Jan 2008 19:48
Favicon

RE: draft-ietf-vrrp-unified-spec-00 issues

Hi Don,

Let me explain where I'm coming from on this.  I certainly can't speak for
the others on the list, but I suspect almost none of my users share your
view on the asymmetry of the advertisement interval.  I would be pleasantly
surprised if ten percent of them knew that the advertisement interval was
part of the advertisement, and really surprised if any of them thought that
the value they configured on the master was intended for the backup.  There
are at least two reasons for this.  First, almost all of them run with very
symmetric configurations.  Interestingly, they actually use the model we
describe in example one for individual LANs (the one the RFC felt was going
to be less common), but they run many LANs on a device.  They do load
splitting by making the virtual routers for half of the LANs master on one
device and half on another.  The two devices are viewed as peers, not as
master and slave.  Their virtual router configurations for each device are
almost identical, but they usually have some criteria to make the priority
higher for half the virtual routers on one device and half on the other.
It's usually something like the odd VRIDs have higher priority on  device A,
the even VRIDs have higher priority on device B.  I have never seen a
customer setup with multiple backups.  That doesn't mean there aren't any,
they're just few and far between.  The second reason is implementation
based.  Simply stated, based on the current RFC, the participants in the
virtual router must have the same advertisement interval, otherwise VRRP
doesn't work.  This is not a fluke.  

So from my perspective the change in the draft to accept the masters
advertisement interval is an effort to "keep it running" in spite of a
misconfiguration.  It will also be useful in migrating to new interval
values but this leads to the scenario I'm worried about.  My users seldom
misconfigure one virtual router - typically they misconfigure all the
(Continue reading)

Permalink | Reply | 10 comments |
headers
Don Provan | 11 Jan 2008 21:43
Favicon

RE: draft-ietf-vrrp-unified-spec-00 issues

Hi, Steve,

First, the principle advantage of this change is that
it allows the interval to be changed by reconfiguring
routers one at a time. The original spec forced the
user to change all routers at the same time least the
network be confused with two masters during the switch
over. For this reason alone, I consider the change to
be a big improvement.

But let's look at the problem case you have brought up:
a router misconfigured with a cripplingly short interval.
The change from rejection to acquiescence has two
negative effects on this problem:

N1. Because the rejected packet is dropped earlier,
there's less VRRP processing done on it than if we
accept it for processing. I assume this is negligible,
but perhaps you don't.

N2. A rejected packet might cause an alarm.

On the other hand, acquiescence also has a couple of
advantageous effects on the same problem:

A1. As you pointed out, a misconfigured backup will
learn and use the correct value from the master. In
other words, the problem will be resolved. Without
this change, not only will the backup keep spewing at
the crippling rate, it will also continuously seize
(Continue reading)

Permalink | Reply | 9 comments |
headers
Steve Bates | 11 Jan 2008 22:19
Favicon

RE: draft-ietf-vrrp-unified-spec-00 issues

Hi Don,

First of all let me say I appreciate your comments tremendously.  Let me try
to reframe my concern.

Must a backup accept the interval of the master to be considered compliant
with the spec?  

Steve 

-----Original Message-----
From: Don Provan [mailto:dprovan <at> bivio.net] 
Sent: Friday, January 11, 2008 1:43 PM
To: 'Steve Bates'
Cc: 'Stephen Nadas'; vrrp <at> ietf.org
Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues

Hi, Steve,

First, the principle advantage of this change is that it allows the interval
to be changed by reconfiguring routers one at a time. The original spec
forced the user to change all routers at the same time least the network be
confused with two masters during the switch over. For this reason alone, I
consider the change to be a big improvement.

But let's look at the problem case you have brought up:
a router misconfigured with a cripplingly short interval.
The change from rejection to acquiescence has two negative effects on this
problem:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Don Provan | 11 Jan 2008 22:34
Favicon

RE: draft-ietf-vrrp-unified-spec-00 issues

Hi, Steve,

My interpretation would be that, yes, to be compliant a backup
has to do its best to take over the VR according to the time
table defined by the master's interval as seen in arriving
announcements. It would clearly not be compliant to ignore the
arriving announcements and start sending its own.

What alternative behavior do you have in mind? Is your concern
the missing alarm, or is there more to it that I'm missing?
-don

> -----Original Message-----
> From: Steve Bates [mailto:Steve.Bates <at> alcatel-lucent.com]
> Sent: Friday, January 11, 2008 1:20 PM
> To: 'Don Provan'
> Cc: vrrp <at> ietf.org
> Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues
> 
> 
> Hi Don,
> 
> First of all let me say I appreciate your comments 
> tremendously.  Let me try
> to reframe my concern.
> 
> Must a backup accept the interval of the master to be 
> considered compliant
> with the spec?  
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Roland Abt | 14 Jan 2008 17:31
Picon

Virtual MAC really necessary?

Hello everybody

I want to implement my own VRRP protocol. The protocol itself is not that  
tricky, but using a virtual MAC seems like a big hurdle to me. The  
standard states that the MAC address of the new Master has to be published  
in a gratuitous ARP (request/reply). I think this already should help to  
update the ARP table of every device. Does anybody know of a situation  
where publishing the physical MAC would cause any trouble? Are there any  
known devices that would not update their ARP table in case of such a  
gratuitous ARP?

Best regards and thanks in advance for your time,
Roland

PS:
According to the Ethereal Wiki (http://wiki.ethereal.com/Gratuitous_ARP) a  
gratuitous ARP can be either a request or a reply. Any experience which  
one is better?

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 6 comments |
headers
Keegan.Holley | 14 Jan 2008 17:59
Favicon

Re: Virtual MAC really necessary?


The advantage of the virtual mac is that it is a multicast address so both devices should receive the traffic regardless of their failover state.  Also, the virtual mac allows failover with out any of the devices having to change their arp entry.  The gratuitous arp just serves to update the forwarding table in the switch(s).  If the gateway mac was suddenly a physical address you may run into issues if some of the attached devices don't receive the gratuitous arp or don't process it because of security.

 


"Roland Abt" <roland.abt <at> gmx.net>

01/14/08 11:31 AM

To
 vrrp <at> ietf.org
cc
Subject
 [VRRP] Virtual MAC really necessary?





Hello everybody

I want to implement my own VRRP protocol. The protocol itself is not that  
tricky, but using a virtual MAC seems like a big hurdle to me. The  
standard states that the MAC address of the new Master has to be published  
in a gratuitous ARP (request/reply). I think this already should help to  
update the ARP table of every device. Does anybody know of a situation  
where publishing the physical MAC would cause any trouble? Are there any  
known devices that would not update their ARP table in case of such a  
gratuitous ARP?

Best regards and thanks in advance for your time,
Roland


PS:
According to the Ethereal Wiki (http://wiki.ethereal.com/Gratuitous_ARP) a  
gratuitous ARP can be either a request or a reply. Any experience which  
one is better?

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


 
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 5 comments |

Gmane