Dave Thaler | 12 Jul 19:57 2005
Picon

FW: Review of draft-ietf-vrrp-unified-mib-03.txt

Forwarding to the WG mailing list as requested.
Please keep my email address on any follow-ups.

Thanks,
-Dave

-----Original Message-----
From: Dave Thaler 
Sent: Monday, July 11, 2005 6:56 PM
To: 'Kalyan.Tata <at> nokia.com'; Mukesh.K.Gupta <at> nokia.com
Cc: radia.perlman <at> sun.com
Subject: RE: Review of draft-ietf-vrrp-unified-mib-03.txt

Okay, here they are at last... :)

1) Is there any restriction on the relationship or lack
thereof between a VRID value used in IPv4 on a given interface
and a VRID value used in IPv6 on the same interface?  (e.g.,
they may or may not be the same, correct?)   If there is
no restriction (all of these are legal), then the doc is fine.

2) Is there any restriction on the relationship or lack
thereof between a VRID valid used on one interface vs one
used on another interface?  (E.g., you could reuse the same
VRID on every interface, you could assign a completely different
VRID for every interface, correct?)  If there is no restriction
(all of these are legal), then the doc is fine.

3) Why do you use an IpVersion INTEGER in your INDEX clause
of vrrpOperationsEntry, rather than just using an InetAddressType?
(Continue reading)

Kalyan.Tata | 12 Jul 20:43 2005
Picon

RE: Review of draft-ietf-vrrp-unified-mib-03.txt

hi Dave,
Thanks once again for the review. My comments inline.

1) Is there any restriction on the relationship or lack
thereof between a VRID value used in IPv4 on a given interface
and a VRID value used in IPv6 on the same interface?  (e.g.,
they may or may not be the same, correct?)   If there is
no restriction (all of these are legal), then the doc is fine.

-- As you guessed it, There is no dependency between VRID of IPv4 
and IPv6 interfaces. I think I will add a sentence mentioning 
this explicitly.

2) Is there any restriction on the relationship or lack
thereof between a VRID valid used on one interface vs one
used on another interface?  (E.g., you could reuse the same
VRID on every interface, you could assign a completely different
VRID for every interface, correct?)  If there is no restriction
(all of these are legal), then the doc is fine.

-- VRID needs to be unique within a virtual router. i.e. Two IPv4 
interfaces can have the same VRID participating in two different VRs.
They are identified uniquely by the ifIndex which will be different.

3) Why do you use an IpVersion INTEGER in your INDEX clause
of vrrpOperationsEntry, rather than just using an InetAddressType?
Can vrrpOperationsIpVersion, vrrpOperationsVersion, 
vrrpOperationsMasterIpAddrType, and vrrpOperationsPrimaryIpAddrType
ever be different?  If not, you only need one object, not four.
All InetAddress objects can use the same InetAddressType object
(Continue reading)

Kalyan.Tata | 12 Jul 23:25 2005
Picon

RE: Review of draft-ietf-vrrp-unified-mib-03.txt

Thanks Dave, All the points are now clear to me. I will update the doc
with these changes.

Thanks again for spending time on this draft.

Thanks
Kalyan

Right, RFC 2851 originally required that:
   When a generic Internet address is used as an index, both the
   InetAddressType and InetAddress objects MUST be used. The
   InetAddressType object MUST come immediately before the InetAddress
   object in the INDEX clause. If multiple Internet addresses are used
   in the INDEX clause, then every Internet address must be represented
   by a pair of InetAddressType and InetAddress objects.

Based on experience, this rule was relaxed in RFC 3291 which obsoleted
2851:
   When a generic Internet address is used as an index, both the
   InetAddressType and InetAddress objects MUST be used.  The
   InetAddressType object MUST be listed before the InetAddress object
   in the INDEX clause.

RFC 3291 was then obsoleted by 4001 which retains the relaxed rule.

--

-- 

> I will modify this to "vrrpOperationsRowInetAddrType" (too long?),
> define it as InetAddressType, and as you mentioned, all other
> InetAddress objects in the row can reference this.
(Continue reading)

Dave Thaler | 12 Jul 23:11 2005
Picon

RE: Review of draft-ietf-vrrp-unified-mib-03.txt

> -----Original Message-----
> From: Kalyan.Tata <at> nokia.com [mailto:Kalyan.Tata <at> nokia.com]
> Sent: Tuesday, July 12, 2005 11:43 AM
> 
[...]
>
> 3) Why do you use an IpVersion INTEGER in your INDEX clause
> of vrrpOperationsEntry, rather than just using an InetAddressType?
> Can vrrpOperationsIpVersion, vrrpOperationsVersion,
> vrrpOperationsMasterIpAddrType, and vrrpOperationsPrimaryIpAddrType
> ever be different?  If not, you only need one object, not four.
> All InetAddress objects can use the same InetAddressType object
> as long as the type appears before them in the table.
> 
> -- Now that you mentioned, It makes sense. :) I have seen each
> InetAddress preceded by an InetAddressType in some other RFC.

Right, RFC 2851 originally required that:
   When a generic Internet address is used as an index, both the
   InetAddressType and InetAddress objects MUST be used. The
   InetAddressType object MUST come immediately before the InetAddress
   object in the INDEX clause. If multiple Internet addresses are used
   in the INDEX clause, then every Internet address must be represented
   by a pair of InetAddressType and InetAddress objects.

Based on experience, this rule was relaxed in RFC 3291 which obsoleted
2851:
   When a generic Internet address is used as an index, both the
   InetAddressType and InetAddress objects MUST be used.  The
   InetAddressType object MUST be listed before the InetAddress object
(Continue reading)

Mukesh.K.Gupta | 18 Jul 17:56 2005
Picon

RE: Solicitation for time slot in VRRP WG

Hui,

[copying Bob Hinden (the author of VRRP for IPv6) and the VRRP WG]

VRRP WG is not meeting in Paris.  You can try to send the draft
to the WG mailing list to get it reviewed by the WG.  Additionally,
you can request a slot in the face to face meeting in Vancouver
(64th IETF).

I briefly went through the draft and have the following questions/
comments:

1) Traditionally, VRRP has been providing only the heart beat mechanism
   to select a master and backup.  Synchronizing the dynamic state
   between the master and the backup was always out of charter of
   VRRP.  Is it possible to keep it that way?  Is it feasible to
   define a separate protocol for synchronizing the binding cache
   instead of defining the new VRRP message types?

2) If 1 (isolating the binding cache sync from vrrp) is feasible, what
   additions/modifications are required in VRRP protocol to make this
   solution work ?

Regards
Mukesh

-----Original Message-----
From: ext "DENG, HUI -HCHBJ" [mailto:hdeng <at> hitachi.cn]
Sent: Monday, July 18, 2005 7:19 AM
To: radia.perlman <at> sun.com; Gupta Mukesh.K (Nokia-NET/MtView)
(Continue reading)

+ACI-DENG, HUI -HCHBJ+ACI- | 19 Jul 03:48 2005
Picon

RE: Solicitation for time slot in VRRP WG

Mukesh,

>[copying Bob Hinden (the author of VRRP for IPv6) and the VRRP WG]
Thanks for your help

>VRRP WG is not meeting in Paris.  You can try to send the draft
>to the WG mailing list to get it reviewed by the WG. 
>Additionally, you can request a slot in the face to face 
>meeting in Vancouver (64th IETF).
We will do that

>I briefly went through the draft and have the following questions/
>comments:
>1) Traditionally, VRRP has been providing only the heart beat mechanism
>   to select a master and backup.  Synchronizing the dynamic state
>   between the master and the backup was always out of charter of
>   VRRP.  Is it possible to keep it that way?  Is it feasible to
>   define a separate protocol for synchronizing the binding cache
>   instead of defining the new VRRP message types?
Firstly, we would like talk a little about another historicall consideration by us to 
use Context Transfer Protocol, we failed to use it to transfer IPsec SA among multiple
home agents since serial number and replay window can not be synchronized totally.
MIP4 home agent doesn not have this problem.

Secondly, we guess that Home Agent have not only realibility but also load balance
problem, we have to consider scenary of multiple home agents existed in the home network.
To do so, virtual home agent and Virtual group have to be considered, then VRID have
to be used, this is the reason why we extend the VRRP protocol other than defining 
a seperate protocol

(Continue reading)

Wijnen, Bert (Bert | 20 Jul 16:28 2005
Picon

RE: RE: Review of draft-ietf-vrrp-unified-mib-03.txt

First a Thank YOU to Dave for the reviews and follow up answers.

I have to add one comment though w.r.t. 
> > 5) Regarding vrrpOperationsAdminState vs vrrpOperationsRowStatus,
> > why do you need both?  Why isn't the row status sufficient?
> > What's the difference between CreateAndWait vs
> > CreateAndGo with AdminState=down?
> > 
> > -- As you are aware, Rowstatus only indicates the status of the row
> > (whether the
> > creation of the row is complete or not) while OperationsState indicates
> > the state of Virtual router the row indicates. I guess you are 
> > saying that we could use rowStatus valid/invalid to convey the meaning
> > of adminstatus up & down.
> > Is my understanding correct?
> 
> RowStatus does not only indicate whether creation of the row is complete
> or not.  The 'notInService' value of the RowStatus is meant to be used
> for adminstatus down for tables using RowStatus.  From RFC 2579:
>     - `notInService', which indicates that the conceptual
>     row exists in the agent, but is unavailable for use by
>     the managed device (see NOTE below); 'notInService' has
>     no implication regarding the internal consistency of
>     the row, availability of resources, or consistency with
>     the current state of the managed device;
> 
> As shown in the table on page 9 of 2579, a normal use case of notInService
> is to change the row to that from the active state (i.e. administratively
> take it down).
> 
(Continue reading)

Picon

RE: VRRP Flapping Question

Mr. Brewer,
    Hopefully this is better late than never. We have performed some testing with both HSRP and VRRP. We used some proprietary capabilities with protocols which permitted setting the advertisement timer (and the hello timer for HSRP) to millisecond values. With HSRP, we found that if the hold timer was set such that when three hellos were missed, the protocol would failover - HSRP was very unstable (i.e., flapping). If we set the hold timer such that more hellos had to be missed, the protocol became more stable and less flapping occurred. With VRRP, you don't have the option of missing more advertisement intervals. Thus the solution was to increase the time of the advertisement interval.
    It looks to me like if you require a low failover time, in the millisecond range, it would be nice to require more missed advertisements (more than 3, as currently specified by VRRP) before declaring the link down.
 
Bob Hott
-----Original Message-----
From: Stewart.Brewer <at> VerizonWireless.com [mailto:Stewart.Brewer <at> VerizonWireless.com]
Sent: Monday, May 02, 2005 14:15
To: Hott, Robert W CIV B35-Branch
Subject: VRRP Flapping Question

Mr Hott,

I read your draft document draft-ietf-vrrp-ipv4-timers-00.txt .  I found it to be of particular interest as I am currently investigating an issue with VRRP flapping.  In section 5 you said ...One area for possible future activity for VRRP is in mechanisms that prevent VRRP flapping. This can occur regardless of the Advertisement Interval setting.

I am trying to understand the types of scenarios that can produce VRRP flapping and how to overcome them.  I would greatly appreciate any information you can share that would help me to better understand this issue and how to resolve it.

Thanks,

Stewart Brewer
MTS - Network Security
Verizon Wireless
Mobile: (817) 301-8756
Phone: (682) 831-3730
stewart.brewer <at> verizonwireless.com

 

___________________________________________________________________ The information contained in this message and any attachment may be proprietary, confidential, and privileged or subject to the work product doctrine and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to this message and deleting it and all copies and backups thereof. Thank you.
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
David Norrie | 27 Jul 17:14 2005
Picon

RE: VRRP Flapping Question

The flapping you describe below sounds like known issues with the
spanning tree protocol.

On a cisco switch configuring 'set spantree portfast enable' should
stop any flapping.

Alternatively you can change the Spanning Tree and/or HSRP/VRRP timers
so that Spanning Tree Forward Delay is less than half the HSRP/VRRP
Holdtime.

Other things to check are that there are no packet storms on the
network and that switches duplex settings are correct.

dn

Mr. Brewer,
    Hopefully this is better late than never. We have performed some
testing with both HSRP and VRRP. We used some proprietary
capabilities with protocols which permitted setting the advertisement
timer (and the hello timer for HSRP) to millisecond values. With
HSRP, we found that if the hold timer was set such that when three
hellos were missed, the protocol would failover - HSRP was very
unstable (i.e., flapping). If we set the hold timer such that more
hellos had to be missed, the protocol became more stable and less
flapping occurred. With VRRP, you don't have the option of missing
more advertisement intervals. Thus the solution was to increase the
time of the advertisement interval.
    It looks to me like if you require a low failover time, in the
millisecond range, it would be nice to require more missed
advertisements (more than 3, as currently specified by VRRP) before
declaring the link down.

Bob Hott

-----Original Message-----
From: Stewart.Brewer <at> VerizonWireless.com
[mailto:Stewart.Brewer <at> VerizonWireless.com]
Sent: Monday, May 02, 2005 14:15
To: Hott, Robert W CIV B35-Branch
Subject: VRRP Flapping Question

Mr Hott,

I read your draft document draft-ietf-vrrp-ipv4-timers-00.txt .  I
found it to be of particular interest as I am currently investigating
an issue with VRRP flapping.  In section 5 you said ...One area for
possible future activity for VRRP is in mechanisms that prevent VRRP
flapping. This can occur regardless of the Advertisement Interval setting.

I am trying to understand the types of scenarios that can produce VRRP
flapping and how to overcome them.  I would greatly appreciate any
information you can share that would help me to better understand this
issue and how to resolve it.

Thanks,

Stewart Brewer
MTS - Network Security
Verizon Wireless
Mobile: (817) 301-8756
Phone: (682) 831-3730
 <mailto:stewart.brewer <at> verizonwireless.com> stewart.brewer <at> verizonwireless.com

___________________________________________________________________

The information contained in this message and any attachment may be

proprietary, confidential, and privileged or subject to the work

product doctrine and thus protected from disclosure.  If the reader

of this message is not the intended recipient, or an employee or

agent responsible for delivering this message to the intended

recipient, you are hereby notified that any dissemination,

distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please notify me

immediately by replying to this message and deleting it and all

copies and backups thereof.  Thank you.

    [ Part 2: "Attached Text" ]

_______________________________________________
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

Picon

RE: RE: VRRP Flapping Question

Mr. Norrie,
	I will certainly investigate you assumption but I do not believe the flapping that we saw was related to the
spanning tree protocol. The routers in question appeared to be overloaded with traffic and could not
process the hellos (or advertisements) within the millisecond settings of the various timers. This was
seen in the packet captures and in the bouncing of the interfaces (from primary to secondary and back). I do
appreciate your sharing the spanning tree protocol issue though.

Bob Hott

-----Original Message-----
From: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org]On Behalf Of
David Norrie
Sent: Wednesday, July 27, 2005 11:14
To: vrrp <at> ietf.org
Subject: [VRRP] RE: VRRP Flapping Question

The flapping you describe below sounds like known issues with the
spanning tree protocol.

On a cisco switch configuring 'set spantree portfast enable' should
stop any flapping.

Alternatively you can change the Spanning Tree and/or HSRP/VRRP timers
so that Spanning Tree Forward Delay is less than half the HSRP/VRRP
Holdtime.

Other things to check are that there are no packet storms on the
network and that switches duplex settings are correct.

dn

Mr. Brewer,
    Hopefully this is better late than never. We have performed some
testing with both HSRP and VRRP. We used some proprietary
capabilities with protocols which permitted setting the advertisement
timer (and the hello timer for HSRP) to millisecond values. With
HSRP, we found that if the hold timer was set such that when three
hellos were missed, the protocol would failover - HSRP was very
unstable (i.e., flapping). If we set the hold timer such that more
hellos had to be missed, the protocol became more stable and less
flapping occurred. With VRRP, you don't have the option of missing
more advertisement intervals. Thus the solution was to increase the
time of the advertisement interval.
    It looks to me like if you require a low failover time, in the
millisecond range, it would be nice to require more missed
advertisements (more than 3, as currently specified by VRRP) before
declaring the link down.

Bob Hott

-----Original Message-----
From: Stewart.Brewer <at> VerizonWireless.com
[mailto:Stewart.Brewer <at> VerizonWireless.com]
Sent: Monday, May 02, 2005 14:15
To: Hott, Robert W CIV B35-Branch
Subject: VRRP Flapping Question

Mr Hott,

I read your draft document draft-ietf-vrrp-ipv4-timers-00.txt .  I
found it to be of particular interest as I am currently investigating
an issue with VRRP flapping.  In section 5 you said ...One area for
possible future activity for VRRP is in mechanisms that prevent VRRP
flapping. This can occur regardless of the Advertisement Interval setting.

I am trying to understand the types of scenarios that can produce VRRP
flapping and how to overcome them.  I would greatly appreciate any
information you can share that would help me to better understand this
issue and how to resolve it.

Thanks,

Stewart Brewer
MTS - Network Security
Verizon Wireless
Mobile: (817) 301-8756
Phone: (682) 831-3730
 <mailto:stewart.brewer <at> verizonwireless.com> stewart.brewer <at> verizonwireless.com

___________________________________________________________________

The information contained in this message and any attachment may be

proprietary, confidential, and privileged or subject to the work

product doctrine and thus protected from disclosure.  If the reader

of this message is not the intended recipient, or an employee or

agent responsible for delivering this message to the intended

recipient, you are hereby notified that any dissemination,

distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please notify me

immediately by replying to this message and deleting it and all

copies and backups thereof.  Thank you.

    [ Part 2: "Attached Text" ]

_______________________________________________
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

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


Gmane