Subject: RE: [VRRP] Re: VRRP IPSEC-AH specs

From: Thomas Dalton <[email-masked]>
Date: Wed, 26 Feb 2003 10:31:20 -0000

Hi,

Just one question:

Why do you need a "Fault" state?

<snip rfc2338>
    - If a Shutdown event is received, then: 

       o Cancel the Master_Down_Timer 
       o Transition to the {Initialize} state 

      endif 
</snip>

Can the various faults not be considered to be "Shutdown events" and hence
the "Initialize" state will account for this?

Indeed, if you merged the ammended FSM diagram such that Fault and
Initialize were one state, you'd have exactly the same as that in RFC2338.

Cheers,
Tom

> -----Original Message-----
> From: Mukesh Gupta [mailto:[email-masked]]
> Sent: Wednesday, February 26, 2003 2:03 AM
> To: ext Alexandre Cassen
> Cc: [email-masked]
> Subject: [VRRP] Re: VRRP IPSEC-AH specs
> 
> 
> The complete location is
> http://www.keepalived.org/draft-ietf-vrrp-ipsecah-spec-00.txt
> 
> As we have passed the deadline for submitting 00 version of the draft
> before IETF 56th, it will be submitted to internet-drafts 
> after IETF 56th.
> 
> Please provide your valuable feedback/comments to the mailing list.
> 
> regards
> Mukesh
> 
> ext Alexandre Cassen wrote:
> 
> > Hi,
> >
> > As previously discussed with Mukesh, I have written down a 
> short draft
> > explaining VRRP IPSEC-AH authentication method specs used 
> in Keepalived
> > VRRP framework.
> >
> > You can find this small paper at : www.keepalived.org
> >
> > Any comments are welcomes.
> >
> > Best regards,
> > Alexandre
> 
> _______________________________________________
> vrrp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/vrrp
> 
_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Alexandre Cassen" <[email-masked]>
Date: Wed, 26 Feb 2003 12:32:40 +0100 (MET)

Hi Tom,

> Initialize were one state, you'd have exactly the same as that in RFC2338.

I agree, this is for explicit reasons. Because Init_state in charge of
link media failure detection is not really explicit. Creating a new
dedicated state for this event introduce timer independance in the
FSM implementation, you can fine the timer optimization. Anyway
in the Init_state there is a really world need for a 'pending' state
processing. Either we kept this in Init_state with the 'pending'
extension, or we create a dedicate state. IMHO, creating a new
state is better since its reflect a real event. Considering FSM
design, this new state doesn't add state handling duplications
since this push the FSM into a n(n-1)-2 state transition matrix.

Best regards,
Alexandre

---

From: Mukesh Gupta <[email-masked]>
Date: Wed, 26 Feb 2003 10:02:48 -0800

[Speaking as a WG member]

One of the reasons to go with VRRP in IETF against Cisco's HSRP was that VRRP
had less number of states, events and message types.
(http://ietf.org/proceedings/97aug/slides/rtg/vrrp-status/P010.html)

It would be a good idea not to add a new state (unless it is really needed) in
order to maintain the benefits of VRRP.

regards
Mukesh

---

From: Alexandre Cassen <[email-masked]>
Date: Wed, 26 Feb 2003 22:37:07 +0100

Hello,

> order to maintain the benefits of VRRP.

hmm, 'Shutdown event' appearing in FSM handling must be specified so :), 
what are Shutdown events ? and what if this Shutdown event end on a 
stable state ? I mean if Shutdown event is received (for example 
interface shut), then Master & Backup state handling will force a 
transition to Initialize, but when entering Initialize state, interface 
still shuted, so 'Shutdown event' is a persitent state than must be 
handled into this Initalize state : with an extension like :

(6.4.1) :

     - If the Priority = 255 (i.e., the router owns the IP address(es)
       associated with the virtual router)

        o Send an ADVERTISEMENT
        o Broadcast a gratuitous ARP request containing the virtual
          router MAC address for each IP address associated with the
          virtual router.
        o Set the Adver_Timer to Advertisement_Interval
        o Transition to the {Master} state

       else if received Shutdown event

        o transit to internal pending state

       else if in pending state

        o keep pending state until pending causes disappear or
          receiving advert
        o ...

       else

        o Set the Master_Down_Timer to Master_Down_Interval
        o Transition to the {Backup} state

       endif

low-level failure must be handled somewhere, but what is the best place 
? a pending state in each FSM state, a pending handling when transiting 
to Init state on Shutdown receives, a new dedicated FSM state.

If for example interface is shuted, then VRRP instance is no longer able 
of sending/receiving adverts to/from VRRP audience. It is isolated, so 
if in Master state will keep sending advert and if in Backup state will 
transit to Master state (since no advert can be received), ... this will 
finally end on a 'fake' sending Master state, and if using IPSEC-AH for 
example, why continuing increasing monotonically AH sequence number if 
audience can't be reached ? in IPSEC this will have 'aging' side effect 
on sequence numbers depending on the time we are isolated.

Best regards,
Alexandre