Subject: [L2tpext] Re: new failover-05 draft

From: Vipin Jain <[email-masked]>
Date: Fri, 8 Apr 2005 09:27:51 -0700 (PDT)

comments inline..

--- Sam Henderson <[email-masked]> wrote:

> Vipin Jain wrote:
> > Keyur,
> > 
> > As per the draft today, if you don't include SCS AVP, the sequence numbers
> are
> > to be set to zero. Also, using the higher value among two values (given
> that
> > absence of SCS AVP indicating the zero SCS values) would result into
> > effectively using SCS AVP as a tie breaker when two tunnels gets
> established.
> > 
> > Then, instead of mandating FEP to send SCS AVP, can we phrase what you are
> > mentioning as:
> > - If 'Tie breaker' AVP is not used then two failover tunnels can get
> > established during double failover, which may indicate two set of sequence
> > numbers. In such situations two end points MUST use the higher of the
> values
> > from SCS AVPs.
> 
> Higher in the sense of a ushort or as defined by RFC 2661 section 5.8?
> Does 0/0 being the actual correct next seq numbers cause a problem?
I agree 'higher' needs to be defined more tightly. It means 'absolute higher
values' as opposed to 'circular higher values'. What if one is higher and the
other one is lower? Should it take one value from one SCS AVP and another one
from another? In that sense, having one tunnel (and using tie breaker) is much
cleaner.

> > This should work whether we use tie breaker or not, and whether an endpoint
> > encode SCS AVP in SCCRP or not.
> 
> I haven't run through all the cases of delayed/dropped packets with this
> yet.  Does this proposal work in all of the cases?
I haven't run through all cases, but I wanted to float the text while I think
more. If there are holes, we fall back to mandating 'tie breaker avp' for
double failover.

thanks,
-- vipin

> 
> Thanks,
> -- Sam
> 
> > 
> > thanks,
> > -- vipin
> > 
> > 
> > --- Keyur Parikh <[email-masked]> wrote:
> > 
> > 
> >>Another way to look at what I am saying is that absence of SCS AVP in
> >>sccrq or sccrp should be considered as starting from 0 (restart). So, in
> >>the example below, I don't see why EP1 should not send the SCS it got
> >>from EP2, prior to EP2 failing.  
> >>
> >>In case of double failure without tie breaker, we would setup 2 recovery
> >>tunnels, but they both should get torned down, once that process
> >>completes - correct?
> >>
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]] 
> >>Sent: Tuesday, April 05, 2005 11:14 PM
> >>To: Sam Henderson
> >>Cc: Paul W. Howard; Vipin Jain; W. Mark Townsley; Keyur Parikh; 'Vipin
> >>Jain'
> >>Subject: Re: new failover-05 draft
> >>
> >>Been away from this topic for a while, but here is a thought anyways,
> >>tell
> >>me the issues with it. I think classifying an endpoint as FEP vs NFEP
> >>can
> >>get confusing, especially if you apply the race conditions that you all
> >>have mentioned.
> >>
> >>The SCS AVP should be included by both endpoints. The FEP sends SCS with
> >>0
> >>value in the sccrq and the other endpoint sends its SCS in sccrp. When
> >>the
> >>recovered tunnel successfully sets up, both endpoints choose the higher
> >>of
> >>those values. In case of double failover, without Tie breaker, they will
> >>end  up setting two tunnels, but both endpoints will be exchanging 0
> >>values in SCS AVP, hence the starting point will be 0.  Same goes for
> >>when
> >>Tie breaker is used.
> >>
> >>
> >>
> >>>Reading back over the thread, I agree that what I recommended about
> >>>when and endpoint may and may not send the SCS leaves plenty of room
> >>>for error.  Simplicity is the better option.
> >>>
> >>>In response to Paul's #5, I agree the customers would be none too
> >>>pleased with all sessions going down.  But isn't that that effect
> >>>of not supporting double failovers?
> >>>
> >>>So, we must mandate use of the tie breaker on the recovery tunnels
> >>>in order for the draft to work if/when a double failover occurs.
> >>>
> >>>As mentioned earlier, I'm not a fan of requiring an AVP for the
> >>
> >>recovery
> >>
> >>>tunnel that isn't mandatory in 2661.
> >>>
> >>>Does the problem get any easier if we eliminate the SCS AVP?
> >>>
> >>>Thanks,
> >>>-- Sam
> >>>
> >>>
> >>>Paul W. Howard wrote:
> >>>
> >>>>Vipin,
> >>>>
> >>>>I would definitely prefer #1, but it seems to me somewhat that we've
> >>>>come full circle and are back where this thread started.   I'm
> >>
> >>concerned
> >>
> >>>>that we haven't heard anything from the other parties to this
> >>>>discussion.   Sam, Mark, Keyur?
> >>>>
> >>>>Thanx,
> >>>>
> >>>>Paul
> >>>>
> >>>>Vipin Jain wrote:
> >>>>
> >>>>
> >>>>>Paul,
> >>>>>
> >>>>>It seems like you do not see a way 'FEP to not send SCS' work out. I
> >>>>>particularly agree with point #3 - which becomes tricky to
> >>>>>ensure/enforce.
> >>>>>
> >>>>>Moving forward we may have to pick one of the two methods to deal
> >>
> >>with
> >>
> >>>>>double
> >>>>>failover:
> >>>>>[1] use of tie breaker (pros: clean solution, cons: the avp is not
> >>>>>mandatory in
> >>>>>the rfc 2661)
> >>>>>[2] not using scs avp (pros: doesn't deviate from 2661 standard
> >>>>>behavior, cons:
> >>>>>tricky to ensure/enforce it would work in all situations).
> >>>>>
> >>>>>Given that, we couldn't sort out #2 as clearly, I'd be inclined to go
> >>>>>for #1 at
> >>>>>this point. Therefore, keep the text close to what was proposed in
> >>
> >>the
> >>
> >>>>>last
> >>>>>version of the draft.
> >>>>>
> >>>>>Also, I am not sure about the IANA allocations. I guess, we need to
> >>
> >>ping
> >>
> >>>>>Ron
> >>>>>and/or Ignacio.
> >>>>>
> >>>>>thanks,
> >>>>>-- vipin
> >>>>>
> >>>>>--- "Paul W. Howard" <[email-masked]> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I think perhaps I'm confused on a few things in this e-mail thread
> >>>>>>going
> >>>>>>back to Sam's e-mail to me of Feb-28.   I'll try and summarize and
> >>>>>>perhaps someone can clarify for me.
> >>>>>>
> >>>>>>1) We talk about not allowing the FEP to send an SCS.   Consider two
> >>>>>>widely separated failovers - first EP1 fails (becoming a FEP).   The
> >>>>>>recovery tunnel is negotiated and sequence numbers reset.   At some
> >>>>>>time
> >>>>>>later, EP2 fails thus EP1 is now in the role of the NFEP and should
> >>>>>>send
> >>>>>>an SCS in it's recovery SCCRP.   Now consider moving these 2
> >>>>>>independent
> >>>>>>failures closer together in time - perhaps to the following:
> >>>>>>
> >>>>>>         EP1                                             EP2
> >>>>>>         failover
> >>>>>>         recovery sccrq ->
> >>>>>>                                                            <-
> >>>>>>recovery
> >>>>>>sccrp with SCS (since acting as NFEP)
> >>>>>>         recovery scccn -> (lost)               failover
> >>>>>>                                                            <-
> >>>>>>recovery
> >>>>>>sccrq
> >>>>>>         recovery sccrp->
> >>>>>>
> >>>>>>Does EP1 send an SCS or not (i.e. is it still functioning as a FEP
> >>
> >>or
> >>
> >>>>>>an
> >>>>>>NFEP)?   How do we draw the line and establish when EP1 can start
> >>>>>>responding to a recovery tunnel as an NFEP and thus be allowed to
> >>
> >>use
> >>
> >>>>>>the SCS AVP?  Note that at the time EP1 sends the recovery sccrp it
> >>>>>>does
> >>>>>>have a valid set of non-zero sequence numbers.   It seems to me that
> >>
> >>it
> >>
> >>>>>>would be very hard to draw the line between FEP and NFEP behavior to
> >>>>>>handle all the permutations of this scenario.
> >>>>>>
> >>>>>>2) We talk about keeping the SCS AVP out of the double failover
> >>>>>>scenario, but, it would seem to me that, even given the rule that
> >>
> >>the
> >>
> >>>>>>FEP can not send an SCS, we can't keep the SCS out of the double
> >>>>>>failover scenario.   In at least some of the double failover
> >>
> >>scenarios,
> >>
> >>>>>>one endpoint (EP1) is always a FEP and the other endpoint (EP2)
> >>
> >>starts
> >>
> >>>>>>as an NFEP and ends up as a FEP.   So in any double failover where
> >>
> >>EP2
> >>
> >>>>>>responds to the recovery SCCRQ while still an NFEP, it will include
> >>
> >>the
> >>
> >>>>>>SCS AVP.
> >>>>>>
> >>>>>>3) We talk about a FEP must not process an SCS after the recovered
> >>>>>>tunnel is recovered.   I don't see how we avoid staying out of
> >>
> >>trouble
> >>
> >>>>>>with this one.   The use of SCS is dependent upon both sides
> >>
> >>applying
> >>
> >>>>>>the data the same way (I think this is what got us started in the
> >>
> >>first
> >>
> >>>>>>place).   So if one endpoint discards an SCS, how do we maintain
> >>>>>>synchronization given the peer endpoint may not have any way of
> >>
> >>knowing
> >>
> >>>>>>the SCS was discarded?   It may be possible to analyze this to
> >>
> >>ensure
> >>
> >>>>>>we
> >>>>>>can do the discard safely, but would we really get all the race
> >>>>>>conditions (e.g. both sides send SCS but they get applied in reverse
> >>>>>>order at one end due to say packet re-ordering)  in such an
> >>
> >>analysis?
> >>
> >>>>>>This makes me rather nervous.
> >>>>>>
> >>>>>>4) I agree we should probably specify which side takes down the
> >>>>>>recovery
> >>>>>>tunnel.   IMO, It doesn't matter from an operational standpoint (it
> >>>>>>works with both sides doing it), but it would be more efficient.
> >>
> >>It
> >>
> >>>>>>would seem perhaps desirable to have the NFEP terminate the recovery
> >>>>>>tunnel on the presumption that the FEP is rather busy    I think
> >>
> >>this
> >>
> >>>>>>would result in 5 packets (Q, P, N, Stop, Ack) whereas it would seem
> >>>>>>likely that having the FEP terminate would result in 6 packets
> >>>>>>depending
> >>>>>>upon timing (Q, P, N, Ack, Stop, Ack).   Overall it's probably a nit
> >>>>>>and
> >>>>>>verging on implementation specifics, but it does seem a waste to end
> >>
> >>up
> >>
> >>>>>>with double Stops (and of course the subsequent Acks).
> >>>>>>
> >>>>>>5) Sam's question from 01-Mar regarding effect of not supporting
> >>
> >>double
> >>
> >>>>>>failover when both ends fail at the same time - all the tunnels and
> >>>>>>sessions go down between the peers.   I'd suspect our customer's
> >>
> >>would
> >>
> >>>>>>be rather annoyed.
> >>>>>>
> >>>>>>6) Vipin's comment from 28-Feb "If SCS AVP is to be included during
> >>>>>>failover then both ends must use 'tie breaker' AVP".   I don't
> >>>>>>understand how this is doable since the SCS is included in the SCCRP
> >>>>>>after the SCCRQ has been sent.   This would seem to require
> >>>>>>pre-knowledge by the FEP of whether or not the NFEP is going to send
> >>>>>>the
> >>>>>>SCS?   Or is this leading up to the subsequent statement requiring
> >>
> >>the
> >>
> >>>>>>tie breaker?
> >>>>>>
> >>>>>>7) How do we nudge IANA on the numbers assignment?   Last I heard
> >>
> >>from
> >>
> >>>>>>them was on 26-Jan where they stated it would be processed asap.
> >>
> >>Does
> >>
> >>>>>>anyone know what is holding up the number assignments?
> >>>>>>
> >>>>>>Thanx,
> >>>>>>
> >>>>>>Paul
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Sam Henderson wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Vipin Jain wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>Sam,
> >>>>>>>>
> >>>>>>>>You aren't really splitting the hair; in fact, that was the
> >>
> >>similar
> >>
> >>>>>>>>streak of
> >>>>>>>>thought that went through my mind as well. I left it with a note
> >>
> >>that
> >>
> >>>>>>>>it is not
> >>>>>>>>supported vs. you are saying is that we need a predictable way to
> >>>>>>>>indicate
> >>>>>>>>that. In that sense, I am inclined to think of having a more
> >>>>>>>>predictable
> >>>>>>>>behavior rather than getting away with saying 'it would not be
> >>>>>>>>supported'.
> >>>>>>>>
> >>>>>>>>Therefore, as you say, we can keep the SCS AVP out of double
> >>
> >>failure
> >>
> >>>>>>>>scenario.
> >>>>>>>>This would work whether tie breaker AVP is used or not.
> >>>>>>>>On the two points you raised as needed for this, I don't
> >>
> >>understand
> >>
> >>>>>>>>why we need
> >>>>>>>>the second point.
> >>>>>>>>1. A FEP MUST NOT send SCS AVP: Shouldn't this alone take care of
> >>
> >>all
> >>
> >>>>>>>>issues
> >>>>>>>>w.r.t. SCS AVP? I mean, when sending SCCRP for a recovery tunnel,
> >>
> >>it
> >>
> >>>>>>>>knows it
> >>>>>>>>was a FEP; and if both sides do that they don't send this AVP in
> >>
> >>the
> >>
> >>>>>>>>SCCRP.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>Look at case 3 in my response to Paul on Feb 28th.
> >>>>>>>Basically the non FEP fails right after sending the
> >>>>>>>SCCRP, but for some reason the SCCRP arrives after
> >>>>>>>the new FEP sets up the recovery tunnel.  This probably
> >>>>>>>isn't very likey to happen - maybe more possible on
> >>>>>>>a box-box failover vs failover to a redundant processor
> >>>>>>>card in the same box.
> >>>>>>>
> >>>>>>>There was also a Qn in the note about which side is supposed
> >>>>>>>to close the tunnel.  Appendix B shows the initiator doing it,
> >>>>>>>but we never say which EP is responsible for doing it.
> >>>>>>>
> >>>>>>>-- Sam
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>2. A FEP MUST NOT process SCS AVP after the recovered tunnel is
> >>>>>>>>recovered: Why
> >>>>>>>>would this be needed for double failure scenario?
> >>>>>>>>
> >>>>>>>>Do you think we should have a conference call and quickly settle
> >>>>>>>>this?
> >>>>>>>>
> >>>>>>>>thanks,
> >>>>>>>>-- vipin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>--- Sam Henderson <[email-masked]> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Vipin Jain wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>IMO we can't control if there is going to be a double failorver
> >>
> >>or
> >>
> >>>>>>>>>>>not,
> >>>>>>>>>>>so whatever we do has to be able to handle it.  If we say the
> >>
> >>ONLY
> >>
> >>>>>>>>>>>way
> >>>>>>>>>>>to handle it is to include the tie breaker AVP then all
> >>
> >>endpoints
> >>
> >>>>>>>>>>>that
> >>>>>>>>>>>support failover MUST include tie breaker in ALL recovery
> >>
> >>tunnels.
> >>
> >>>>>>>>>>>
> >>>>>>>>>>Partially agree; I'd say that to support 'double failover' (as
> >>>>>>>>>>opposed to
> >>>>>>>>>>'failover') an endpoint MUST include tie breaker AVP in ALL
> >>>>>>>>>>recovery
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>tunnels.
> >>>>>>>>>Maybe I'm splitting hairs here, but I think your verbage allows
> >>
> >>an
> >>
> >>>>>>>>>implementation to say they don't support double failover.  We
> >>
> >>can't
> >>
> >>>>>>>>>control if both sides fail, but I guess we can say we will/won't
> >>>>>>>>>recover the tunnel if both sides fail.  How do we advertise
> >>
> >>double
> >>
> >>>>>>>>>failover is not supported?
> >>>>>>>>>
> >>>>>>>>>If an endpoint sets the C bit and advertises a recovery time, are
> >>>>>>>>>they saying they support double failover?
> >>>>>>>>>
> >>>>>>>>>What is the effect of not supporting double failover when both
> >>>>>>>>>ends fail at the same time?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>What is your opinion on the following?
> >>>>>>>>>>>1. A FEP MUST NOT send SCS AVP.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>FEP, in single failure situation would never send SCS AVP
> >>
> >>because
> >>
> >>>>>>>>>>it would
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>only
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>initiate new tunnels, i.e. never send SCCRP (which encodes SCS
> >>>>>>>>>>AVP). For
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>double
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>failure situations I am okay to live with having no SCS AVP,
> >>
> >>i.e.
> >>
> >>>>>>>>>>sequence
> >>>>>>>>>>numbers set back to zero.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>2. A FEP MUST NOT process SCS AVP after the recovered tunnel
> >>>>>>>>>>>  has been recovered.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>This should be done irrespective of double failure. We should
> >>
> >>never
> >>
> >>>>>>>>>>utilize
> >>>>>>>>>>this AVP to reset sequence numbers in a regular operating
> >>
> >>tunnel.
> >>
> >>>>>>>>>>
> >>>>>>>>>Right, so in the double failure condition once the "recovered
> >>>>>>>>>tunnel"
> >>>>>>>>>has been recovered (ie seq numbers reset and we are able to send
> >>>>>>>>>control packets over the tunnel) we still would not reset seq
> >>>>>>>>>numbers
> >>>>>>>>>if we received an SCCRP with SCS AVP and TR AVP.
> >>>>>>>>>
> >>>>>>>>>I believe the draft can handle double failures without the tie
> >>>>>>>>>breaker
> >>>>>>>>>as long as we follow these two rules.  If this is the case, the
> >>
> >>tie
> >>
> >>>>>>>>>breaker AVP SHOULD be sent to simplify double failover processing
> >>>>>>>>>instead
> >>>>>>>>>of MUST be sent to support double failover.
> >>>>>>>>>
> >>>>>>>>>Thanks,
> >>>>>>>>>-- Sam
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>thanks,
> >>>>>>>>>>-- vipin
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>__________________________________________________
> >>>>>Do You Yahoo!?
> >>>>>Tired of spam?  Yahoo! Mail has the best spam protection around
> >>>>>http://mail.yahoo.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >>
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around 
> > http://mail.yahoo.com 
> > 
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext