Subject: RE: Few questions on L2TP..

From: Keyur Parikh <[email-masked]>
Date: Tue, 6 Mar 2001 15:51:17 -0500

Therefore, it seems that there is no reliable way of recovering a tunnel or
calls after a switchover. In real deployment scenario, re-establishing 1000s
of tunnels and calls after a switchover is not an effective solution for the
carriers.

thanks for your input
-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Tuesday, March 06, 2001 12:55 PM
To: Keyur Parikh
Cc: Andy Koscinski; [email-masked]
Subject: Re: Few questions on L2TP..

Comments inline.

- Mark

Keyur Parikh wrote:
> 
> My comments starting with >KRP
> 
> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 2:17 AM
> To: Andy Koscinski
> Cc: Keyur Parikh; [email-masked]
> Subject: Re: Few questions on L2TP..
> 
> Apologies for the nasty formatting in converting all this HTML mess to
> ASCII. Please see WMT for comments inline.
> 
> Thanks,
> 
> - Mark
> 
> 1) Since there is no protocol support to re-synchronize the tunnel and
> data message sequence number -
>    how does the LAC go about recovering a tunnel and call session after
> a switchover?
> 
>    For tunnel control channel will the following work?
> 
>        andyk> in the standard rfc2661 it would not work, because the Ns
> and Nr
>        between the LAC and the LNS would not synchronize after the
> switch over
>        and the tunnel would go down.
> 
> 
>                LAC                            LNS
>                        Hello (Ns =0 ,Nr=0)
>                   ------------------------------>
>                        ZLB (Ns=x,Nr =y)
>                    <-----------------------------
>        The LAC can then determine its state variables based on the ZLB.
> 
>        andyk> yes, in the above msg exchange, the LAC and the LNS could
> synchronize
>        their msg sequence counters  (and Amber Networks L2TP
> implementation does,
>        which is an extension to the rfc2661).
> >KRP - andy, I agree in theory it should work.

This could be dangerous. 

It seems that you are "probing" with a Hello message that you think is
invalid, and expecting the peer to send a ZLB ack in response and obtain
information from this. In the nominal case, this could work, but you
have to consider the edge conditions as well. You don't want to design
something that works "most" of the time, particularly when a failure can
bring down an entire tunnel with thousands of sessions within it.

- The Ns sequence space is a wrapping 16-bit value. It begins with 0,
but after that there is no signifigance to 0 other than it occurs again
some time in the future... Probably beyond your testing procedures so it
"looks" like this works fine. Think of choosing, say, 100 for your Ns
Hello probe and think about whether your method will always work. 

- The only way to be sure you are sending an Ns that will be dropped and
acknowledged is to send Ns equal to the last acknowledged packet for the
tunnel. However, I *think* your intended application prohibits this as
it is coming up after a "switchover" and has no sequence number state. 

- The Nr of zero in your probe could inadverdantly acknowledge
outstanding packets on the tunnel (packets that you have not recevied,
but your peer will think you have received).

- A peer does not have to respond to a Hello message with a ZLB. 

- Even if the Hello message does trigger a ZLB, a "real" control message
could be received before the ZLB is (packets may be reordered in
transit).

- Think about what happens if/when both sides try to sync with one
another.

There are no requirements for "timeouts" of states in L2TP. The L2TP
state machine very much depends on the reliable control channel beneath
it to deliver ALL packets. I see the possibililty for packets to be
erroneously acknowledged here, which places additional requirements on
the L2TP state machine.

> WMT:
> 
> 1. The control messages and data messages have different sequence number
> spaces, there is no need to synchronize them.
> 
> >KRP May be you misunderstood the question.  The synchronization is
between
> the LAC and LNS for control channel and data session sequence number, not
> between the control channel and individual data channel.

You cannot rely on the data Nr to have anything valid in it. Anyway, all
you need to do to synchronize data packets after losing state is to pick
a number and start counting. The peer's window, timer, or whatever
sequence sanity checking it is performing will overflow and pickup with
the current sequence numbers.

> 
> 2. ZLBs are never used for data sequencing.
> >KRP But ZLB does contain the Ns and Nr which can be used by the LAC to
> derive its own sequence numbers.
> 
> 3. A Hello message can never have Ns of zero.
> 
> 4. On the data channel, Nr is always ignored.
> >
> 5. I assume by "switchover" you mean some sort of active failover
> technique. This is, in fact, outside the scope of RFC2661.
> 
> 
>        For sessions, what happens if the switched in component at the
> LAC does not set the sequence numbers, but the call was using sequence
> number
>        prior to failure. Will the LNS clear the call?
> 
> WMT: Clearing the call would be very drastic, don't you think? Again, if
> my "switched in" you mean active failover, this is still outside the
> scope of the RFC. However, the LNS should be lenient of an LAC that
> sends sequence numbers even when it should not. Think of sequence number
> presence as we do with PFC and ACFC in PPP - you always have to check on
> its presence even when you think you know what you should be getting.
> You have to do this not only for misbehaving implementations, but for
> race conditions as well.
> KRP>
> ok, now you are making assumptions on how the LNS implementation has
> interpreted the RFC.  

Just giving interoperabilty advice. A good implementation is liberal in
what it accepts and strict in what it sends. 

I would be interested to know where in the RFC it suggests that a call
should be torn down if a data packet is received with sequence numbers
present or not. I would hope that it does not give this impression.

> My point in all this is that why is there no support
> in the RFC2661 for re-synching the control and data session sequence
numbers
> after such a condition.  This will also help avoid proprietary
> implementation and make the protocol more robust.

There is a fundamental assumption that all control packets will be
delivered reliably. Period. At first glance, this "resyncing" seems to
break this under some conditions. 

Again, there is no need to "resync" data messages.

> 
>        andyk> the rfc 2661 requires LAC to continue including the
> sequence numbers, but
>        in my reading does not explicitly require the LNS to clear the
> call after the LAC misbehaved?
> 
>        I think it would be better if the LAC or LNS could ask during the
> L2TP session establishment
>        not to use payload msg sequencing (currently the LAC can only ask
> to use payload msg sequencing).
> 
> WMT: The LNS is under control of sequence numbers as, traditionally, it
> is the side that knows whether they are necessary or not (it is
> terminating the PPP session and knows whether a CP is being negotiated,
> compression or encryption is active, what protocols are being carried,
> etc.). Sequence number presense is not signalled on the control channel
> as you need to be able to turn sequence numbers on and off in-band, it
> may be "too late" if you have to wait on a control message.
> 
> This is clearly not the best design. It was hacked in as a comprimise to
> get RFC2661 ratified without much change to all of the running code that
> we had. C'est la vie.
> 
> If we still need to conquer sequencing at the L2TP level, what I
> *really* really should exist, is a small, wrapping sequence number that
> is present at all times on packets being sent. It can then be ignored or
> attended to on the receiving side as necessary. In hardware, stuffing in
> a simple value incremented for each packet is probably just as fast as
> checking a bit to see if you need to put a sequence number or a zero in
> place. Also, this eliminates all signalling on the subject.
> 
> This begs the question though, should we have a fixed header option that
> could be negotiated up front? That would certainly be more hardware
> friendly as well. Fixed headers are never easy for committees to decide
> upon, but we could certainly try.
> 
>        2)Is there a another method for synchronizing the negotiated LCP
> options at the LAC? is snooping the only alternative?
> 
> WMT: Why would you ever need to snoop? I hope you did not get this idea
> from RFC2661.
> 
> If you need to notify the LAC of negotiated options that occurred at the
> LNS, you can do this for important things such as ACCM via the SLI
> command in RFC2661. There is a draft
> (draft-ietf-l2tpext-linkinfo-0x.txt) that defines a generic way to send
> all LCP options within the SLI. Take a look, comments welcome. We'll
> probably go last call on this one soon.
> 
> >KRP thanks for the draft info, I was not aware of this. From the RFC2661,
> the only info returned from LNS in SLI message is ACCM, I could not find
> anywhere in the RFC where the negotiated FCS or MRU is indicated to the
LNS.
> 
> There are some potentially tricky race conditions here as well, which I
> tried to detail in the latest l2tpbis document. Check the archives for a
> fairly lengthy discussion on the subject (search on ACCM or SLI and you
> will probably find it).
> 
> >KRP thanks, I will.
> - Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 06 Mar 2001 16:29:43 -0500

> of tunnels and calls after a switchover is not an effective solution for the

Not so fast. I was just saying that the synchronization method you
posted here had flaws. 

There are other methods that could work, so keep thinking. At a minimum,
these certainly require state updates between the boxes (or separate
processors within a single box) operating as a failover group.

Also, re-establishing 1000s of tunnels and calls at once is something
many of us are ensuring is quite possible in our code. In this new
"always on" world, you just can't get around it sometimes. It's
"Mother's Day" every time a DSLAM goes down and back up again.

I am actually more concerned that there was someone professing that they
had already incorporated the resync method you posted as an "extension"
to RFC2661. At a minimum, I would suggest that such extensions be made
available for consideration to the group here if the proprietors expect
them to work with other implementations. For this particular case, I am
concerned about it working reliably at all (even amongst themselves). 

- Mark