headers
Hott, Robert W CIV B35-Branch | 7 Feb 2006 00:27
Picon
Favicon

RE: Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt

Sonum,
	I apologize for taking so long to get back to this thread. I have given some thought to your discussion for
the need to test for VR_Mode == 1 in the Master state. I believe that it is needed. I will attempt to explain
why. Suppose that the router is configured to operate using the standard mode (VR_Type = 1) and therefore
use ADVERTISEMENTS. If it is the MASTER, it sends the ADVERTISEMENT, assumes VR_Mode == 0 (everybody is
using ADVERTISEMENTs), sets Adver_Timer, and transitions to the MASTER state. Now in the MASTER state,
if we hear a new router come on line that uses FAST ADVERTISEMENTS, we start sending FAST ADVERTISEMENTS
(and setting the Adver_2_Timer) to make it move to BACKUP state, unless it should become the Master. In
either case, VR_Mode is now 1.

	The router could also get into the VR_Mode == 1 while in the BACKUP state, if originally in VR_Type = 1 and not
a Master. While in the BACKUP state, it hears a FAST ADVERTISEMENT and thus enters VR_Mode = 1. If it were
ever to become Master, it would send both types of advertisements and set the timers for both.

Bob Hott

-----Original Message-----
From: Mathur Sonum-CSM109 [mailto:sonum <at> motorola.com]
Sent: Thursday, January 26, 2006 20:15
To: Hott, Robert W CIV B35-Branch; vrrp <at> ietf.org
Subject: RE: [VRRP] Reminder of posting of
draft-ietf-vrrp-ipv4-timers-01.txt

Comments inline

>  -  If the Adver_2_Timer fires, then:
>        If the VR_Mode is 1
>        or
>        if the VR_Type is 2, then:
>         o  Send a FAST ADVERTISEMENT
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Bates | 7 Feb 2006 00:31
Picon

Questions on draft-ietf-vrrp-ipv4-timers-01.txt

Hi Bob,

1) Back in early December there was a flurry of comments about mismatched
advertisement intervals causing multiple masters.  The consensus seemed to
be that virtual routers of a lower priority would ignore a mismatch if the
higher priority interval was less than their configured interval and make
the higher priority interval their own operational value when it was greater
than their configured interval.  I was under the impression that this would
be reflected in the draft.  True?

2) Does the addition of advertising interval granularity create a similar
problem?

3) I don't dispute the desirability of  a configurable advertisement count
but I'm not sure we gain much passing it in the advertisement.  Once again a
mismatch creates the potential for multiple masters.  If it were treated
like the advertisement interval as discussed above it might be of marginal
use to prevent flapping, but it's not as critical as the interval itself.

3) For the VRRPv4 packet there are only 4 bits available since the
advertisement interval uses 12.  Do you have an idea how to migrate this
draft to the IPv6 case?

Steve Bates
Alcatel Internetworking
801-287-8934 

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Fenner | 11 Feb 2006 00:43
Picon

AD Review of draft-ietf-vrrp-unified-mib


I've performed my AD Review of the unified MIB, with a copy of RFC 4181
open and my MIB hat on.  (Don't ask to see it, I have to close the door
to my office when I am wearing it.)

Here are my comments.  Despite the number of comments, I think each one is
reasonably easy to resolve.  I'm happy to discuss any point, or to learn
that there's information that I didn't consider (e.g., compatability
issues, etc.) in my suggestions.

Thanks,
  Bill

MIB:

1. The REVISION clause from RFC 2338 needs to be retained.
The more recent REVISION clause should be last and should describe
the changes.

2. Every deprecated object needs an explanation in the DESCRIPTION
saying why it's deprecated (RFC 2578, section 10.2 (3)).  Text like
"This object is deprecated in favor of the IP Version Independent object,
vrrpFoobarObject" seems appropriate.  Similarly for the deprecated Groups.

3. The DESCRIPTION for vrrpOperationsMasterIpAddr seems to have had an
editing error (I realize that it's copied from vrrpOperMasterIpAddr).
The current wording implies that it could be set to the source of a
packet from a backup.  The DESCRIPTION also doesn't say that it's set
to my address when I'm the master, but I think that's what happens.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kalyan.Tata | 13 Feb 2006 20:25
Picon

RE: AD Review of draft-ietf-vrrp-unified-mib

HI Bill,
Thanks For taking time to review the draft. I think the MIB hat looks
great on you :). These are excellent comments.  

I will get back to you if I need more clarifications, All the comments
look valid to me.

Thanks
Kalyan

-----Original Message-----
From: ext Bill Fenner [mailto:fenner <at> research.att.com] 
Sent: Friday, February 10, 2006 3:44 PM
To: vrrp <at> ietf.org
Cc: Tata Kalyan (Nokia-ES/MtView)
Subject: AD Review of draft-ietf-vrrp-unified-mib

I've performed my AD Review of the unified MIB, with a copy of RFC 4181
open and my MIB hat on.  (Don't ask to see it, I have to close the door
to my office when I am wearing it.)

Here are my comments.  Despite the number of comments, I think each one
is reasonably easy to resolve.  I'm happy to discuss any point, or to
learn that there's information that I didn't consider (e.g.,
compatability issues, etc.) in my suggestions.

Thanks,
  Bill

MIB:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mathur Sonum-CSM109 | 16 Feb 2006 04:36

RE: Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt


Thanks for clarifying the proposed behavior. So, even if VR_Type == 1,
we will send Fast Advts. in certain cases. I was under the assumption
that if we are configured as VR_Type ==1, then we will never send Fast
Advts. So now, with your explanation, if VR_Mode == 1, then we will
_always_ send both types of Advts. You might want to document this on
page 9 that whenever VR_Mode is set to 1, we will have to start the
Adver_Timer or Adver_2_Timer (depending on VR_Type).

--
Sonum

> -----Original Message-----
> From: Hott, Robert W CIV B35-Branch [mailto:robert.hott <at> navy.mil] 
> Sent: Monday, February 06, 2006 3:28 PM
> To: Mathur Sonum-CSM109; vrrp <at> ietf.org
> Subject: RE: [VRRP] Reminder of posting of 
> draft-ietf-vrrp-ipv4-timers-01.txt
> 
> Sonum,
> 	I apologize for taking so long to get back to this 
> thread. I have given some thought to your discussion for the 
> need to test for VR_Mode == 1 in the Master state. I believe 
> that it is needed. I will attempt to explain why. Suppose 
> that the router is configured to operate using the standard 
> mode (VR_Type = 1) and therefore use ADVERTISEMENTS. If it is 
> the MASTER, it sends the ADVERTISEMENT, assumes VR_Mode == 0 
> (everybody is using ADVERTISEMENTs), sets Adver_Timer, and 
> transitions to the MASTER state. Now in the MASTER state, if 
> we hear a new router come on line that uses FAST
(Continue reading)

Permalink | Reply | 5 comments |

Gmane