headers
Hott, Robert W CIV B35-Branch | 1 Mar 2005 18:14
Picon
Favicon

FW: I-D ACTION:draft-ietf-vrrp-ipv4-timers-00.txt

I have not seen the advertisement of this draft on the VRRP list (even though it shows that is was copied to the
list). I know that there have been several messages lately suggesting enhancements to VRRP. This draft is
meant to be a starting point for a next version of VRRP for IPv4 to address sub-second timers. Please take a
look and let the commenting begin :-)

Thanks.

Bob Hott

-----Original Message-----
From: i-d-announce-bounces <at> ietf.org
[mailto:i-d-announce-bounces <at> ietf.org]On Behalf Of
Internet-Drafts <at> ietf.org
Sent: Wednesday, February 16, 2005 10:27
To: i-d-announce <at> ietf.org
Cc: vrrp <at> ietf.org
Subject: I-D ACTION:draft-ietf-vrrp-ipv4-timers-00.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		: Timer Enhancements to Reduce Failover Times for the 
			  Virtual Router Redundancy Protocol for IPv4
	Author(s)	: R. Hott
	Filename	: draft-ietf-vrrp-ipv4-timers-00.txt
	Pages		: 12
	Date		: 2005-2-15
	
This memo identifies a new requirement for the Virtual Router
   Redundancy Protocol (VRRP) for IPv4 and proposes candidate
(Continue reading)

Permalink | Reply | 2 comments |
headers
Don Provan | 2 Mar 2005 00:25
Favicon

RE: FW: I-D ACTION:draft-ietf-vrrp-ipv4-timers-00.txt

I think there needs to be a section on backwards compatibility
specifically pointing out that the protocol version is changing,
so there is no backwards compatibility. I also think such a
section might want to suggest that implementations support a
"version 2 mode" to allow new implementations to be used on
networks with old ones.

If we go with the units being controlled by a flag (i.e., 4.1.1),
did you consider using the high order bit of the existing
interval value? This limits the interval in seconds to 127 and
the interface in centiseconds to 1.27 seconds, but that doesn't
seem like a problem to me. I'm not sure why I like this better;
I suppose it's just that the time value is encoded in a single
8-bit value rather than have it meaning depend on a bit elsewhere
in the packet.

Personally, since we're already declaring no backward compatibility
because of the version change, I'd rather go with the complete
change to the more obvious 4.1.2 approach if that keeps the IPv4
protocol in agreement with the IPv6 protocol.

Because we're cutting down the failure detect time to such a fine
line, it seems likely that more cases will come up where the
interval is changed while the routers are operational as admin's
adjust the timer to get the results they want. For that
reason, I think we should address the behavior when the interval
changes, particularly the issue of mismatched intervals between
the configurations two routers have for the same VR.

Obviously the first step to allowing conflicting intervals is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mukesh.K.Gupta | 8 Mar 2005 04:20
Picon

RE: out-of-band VRRP advertisement messages

Changming,

Sorry for replying late.  I was on a long vacation :)

Please see my comments inline..

> Do we see a need for OOB channel/link VRRP advertisement messages? 
> The current draft, like the VRRPv2, still assumes that the message 
> is sent out of the interface which VRRP is enabled. 

I wonder which draft you are talking about :-/  VRRPv2 has been
published as Draft Standard RFC 3768.

> This is generally true assumption. But in case of a DOS attack 
> or under heavy volume of traffic, the Advertisement message may 
> get lost. This will caused what our customer described as 
> "split brain syndrome": both routers become active the same time.

It will certainly be useful to have OOB VRRP in order to protect
it against the DoS attack.

> This is the same issue with routing protocol, like OSPF and BGP.
> Alex has a draft to deal with this situation for oob routing. 
> For VRRP, because devices may have dedicated HA links. This 
> will make this situation relatively easily to deal with. Only 
> some minor modification is need to the current draft in order 
> to make this work. Anyone is interested in working in this area?

No one has responded to your mail yet so I guess, there are
no volunteers for doing this :(
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mukesh.K.Gupta | 8 Mar 2005 04:20
Picon

RE: draft-ietf-vrrp-unified-mib-02

Steve,

Thanks for reviewing the draft :)

I am not able to understand the concern that you expressed in 
point 5.  Could you please put some more light on this ?

====
> 5) A virtual router is identified by Version, Vrid, and 
> ifIndex.  Can we
> really identify the virtual router an entry in the 
> vrrpAssociatedIpAddrTable
> is associated with without the version?  Is it supposed to be 
> inferred from
> the vrrpAssociatedIpAddrType?  If version is added as an 
> index it will also
> need to be added to the examples in section 8.
====

Regards
Mukesh

> -----Original Message-----
> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org]On Behalf Of
> ext Steve Bates
> Sent: Monday, February 28, 2005 1:09 PM
> To: Tata Kalyan (Nokia-ES/MtView)
> Cc: vrrp <at> ietf.org
> Subject: [VRRP] draft-ietf-vrrp-unified-mib-02
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Steve Bates | 8 Mar 2005 18:00
Picon

RE: draft-ietf-vrrp-unified-mib-02

Mukesh,

Sorry, I reread my question and wasn't sure I understood it myself.  Let me
try again.  Here is part of the DESCRIPTION of the
vrrpAssociatedIpAddrEntry:

               "An entry in the table contains an IP address that is
               associated with a virtual router.  The number of rows
               for a given ifIndex and VrId will equal the number of
               IP addresses associated (e.g., backed up) by the
               virtual router....."

But from the vrrpOperationsEntry description we know that "a given virtual
router is identified by a combination of the IP version, VRID and ifIndex."

No mention is made of the IP version in either the vrrpAssociatedIpAddrEntry
DESCRIPTION or INDEX fields in the MIB.  It seems to me the DESCRIPTION
should read:

               "An entry in the table contains an IP address that is
               associated with a virtual router.  The number of rows
               for a given ifIndex, VrId, and IP version will equal the
               number of IP addresses associated (e.g., backed up)
               by the virtual router....

and INDEX should be:
           INDEX    { ifIndex, vrrpOperationsVrId, vrrpOperationsIpVersion,
                      vrrpAssociatedIpAddrType, vrrpAssociatedIpAddr }

However, the IP version can be inferred from the address type, so it's not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Changming Liu | 8 Mar 2005 18:19
Favicon

RE: out-of-band VRRP advertisement messages

Mukesh,

Thanks for your reply. I'll try to see if I can come up with something
on this topic for next IETF. Since you are from Nokia, your input will
be very valuable.

Changming

-----Original Message-----
From: Mukesh.K.Gupta <at> nokia.com [mailto:Mukesh.K.Gupta <at> nokia.com] 
Sent: Monday, March 07, 2005 7:20 PM
To: Changming Liu; vrrp <at> ietf.org
Subject: RE: [VRRP] out-of-band VRRP advertisement messages

Changming,

Sorry for replying late.  I was on a long vacation :)

Please see my comments inline..

> Do we see a need for OOB channel/link VRRP advertisement messages? 
> The current draft, like the VRRPv2, still assumes that the message 
> is sent out of the interface which VRRP is enabled. 

I wonder which draft you are talking about :-/  VRRPv2 has been
published as Draft Standard RFC 3768.

> This is generally true assumption. But in case of a DOS attack 
> or under heavy volume of traffic, the Advertisement message may 
> get lost. This will caused what our customer described as
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mukesh.K.Gupta | 9 Mar 2005 18:28
Picon

Different Advert Interval on Master and Backup

Bob,

I was going to through the VRRPv6 draft and remembered the issue
about the Advertisement Intervals that was raised by Mark Hollinger
sometime back.

Look at http://www1.ietf.org/mail-archive/web/vrrp/current/msg00327.html
and also http://www1.ietf.org/mail-archive/web/vrrp/current/msg00334.html

I was under the impression that we had updated the text such that
the backup router adjusts its listening timer according to the Master
but it seems we haven't :(

Should we make this change in the draft while addressing the IESG
comments if there are any ?

It is sad to see that the VRRP for IPv4 will still have the problem.

Regards
Mukesh

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Steve Bates | 9 Mar 2005 19:29
Picon

draft-ietf-vrrp-unified-mib-02 - prefix length

One additional question about the unified MIB.  Can we provide a prefix
length in the vrrpAssociatedIPAddrTable to facilitate the creation of a link
local address?  Providing it in a proprietary MIB is somewhat awkward.

Steve

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 1 comment |
headers
Anand Parthasarathy | 25 Mar 2005 20:17
Picon
Favicon

VRRP for IPv6

Hi,
 
If the link-local IPv6 address of Router R1 (that is the primary owner) is backed by R2 and R2 is the current master (assume that R1 is down), what will happen if Router R1 comes up? The expected behaviour is that R1 should become master as its priority is 255. But, its DAD will fail for the link-local IPv6 address and so, it will be unable to become master. Could someone comment on this?
 
Thanks,
Anand.
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
Permalink | Reply | 0 comments |
headers
Mukesh.K.Gupta | 25 Mar 2005 22:56
Picon

RE: VRRP WG Last Call: draft-ietf-vrrp-unified-mib-02.txt

Sorry for being late..  The WG LC for the MIB draft has
ended and we have received some comments from Steve Bates.

I will ask Kalyan to update the draft and then we can
proceed further with this draft.

Regards
Mukesh

> -----Original Message-----
> From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org]On Behalf Of
> ext Mukesh.K.Gupta <at> nokia.com
> Sent: Sunday, February 27, 2005 12:37 AM
> To: vrrp <at> ietf.org
> Subject: [VRRP] VRRP WG Last Call: draft-ietf-vrrp-unified-mib-02.txt
> 
> 
> Hi All,
> 
> The chairs think that the VRRP MIB draft is mature
> enough to start a WG LC.
> 
> This email starts a 2 week VRRP Working Group Last 
> Call on the following draft:
> 
>     Title         : Definitions of Managed Objects for the 
> VRRP over IPv4 and IPv6
>     Author        : Kalyan Tata
>     Filename      : draft-ietf-vrrp-unified-mib-02.txt
>     Pages         : 38
> 
> The draft is planned to be advanced as a Proposed Standard.
> 
> Please send the comments to vrrp <at> ietf.org.
> 
> The Last Call will end on 13th Mar 2005.
> 
> Regards,
> Radia & Mukesh
> VRRP WG co-chairs
> 
> PS: For quicker access, here is the direct URL of the draft.
> http://ietf.org/internet-drafts/draft-ietf-vrrp-unified-mib-02.txt
> 
> _______________________________________________
> 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 | 0 comments |

Gmane