Subject: Re: Few questions on L2TP..

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 07 Mar 2001 11:07:13 -0500

Keyur Parikh wrote:
> 
> >Repeat after me: "Data messages do not need synchronizing", "Data
> >messages do not need synchronizing", "Data messages do not need
> >synchronizing"...
> 
> OK, then how do you explain the following from RFC2661 (section 5.4)
> 
> "
> Unlike the L2TP control channel, the L2TP data channel does not use
>    sequence numbers to retransmit lost data messages. Rather, data
>    messages may use sequence numbers to detect lost packets and/or
>    restore the original sequence of packets that may have been reordered
>    during transport.  The LAC may request that sequence numbers be
>    present in data messages via the Sequencing Required AVP (see Section
>    4.4.6). If this AVP is present during session setup, sequence numbers
>    MUST be present at all times. If this AVP is not present, sequencing
>    presence is under control of the LNS. The LNS controls enabling and
>    disabling of sequence numbers by sending a data message with or
>    without sequence numbers present at any time during the life of a
>    session. Thus, if the LAC receives a data message without sequence
>    numbers present, it MUST stop sending sequence numbers in future data
>    messages. If the LAC receives a data message with sequence numbers
>    present, it MUST begin sending sequence numbers in future outgoing
>    data messages. If the LNS enables sequencing after disabling it
>    earlier in the session, the sequence number state picks up where it
>    left off before.
> 
>    The LNS may initiate disabling of sequencing at any time during the
>    session (including the first data message sent). It is recommended
>    that for connections where reordering or packet loss may occur,
>    sequence numbers always be enabled during the initial negotiation
>    stages of PPP and disabled only when and if the risk is considered
>    acceptable. For example, if the PPP session being tunneled is not
>    utilizing any stateful compression or encryption protocols and is
>    only carrying IP (as determined by the PPP NCPs that are
>    established), then the LNS might decide to disable sequencing as IP
>    is tolerant to datagram loss and reordering.
> "
> The above clearly indicates that the Ns value for each end is present at the
> other end to re-order and detect lost packets. Also, if the LNS disables it
> and then re-enables it, the sequence number MUST start from where it left

There is no "MUST" in this sentence:

"If the LNS enables sequencing after disabling it earlier in the
session, the sequence number state picks up where it left off before."

But, having seen this text again here, I certainly agree that it would
not hurt for it to be clarified a bit overall. I will put this on my
list of things to do for l2tpbis. Thanks.

- Mark

> off.  THIS IS ALL STATEFUL INFORMATION THAT NEEDS TO BE RESET (I used the
> word resynch to really mean reset). I am fully aware of the difference in
> the use of the sequence numbers for control and data channel.
> 
> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 8:22 PM
> To: Keyur Parikh
> Cc: Andy Koscinski; [email-masked]
> Subject: Re: Few questions on L2TP..
> 
> > Just a thought: How about ensuring that your hot standby router has full
> > state before even acknowledging the control message from your primary?
> > This doesn't require any changes to the protocol.
> >
> > KRP - This is not a very scalable solution.  Specially for the session
> data
> 
> Repeat after me: "Data messages do not need synchronizing", "Data
> messages do not need synchronizing", "Data messages do not need
> synchronizing"...
> 
> > messages. IMO, the RFC2661 should state what the LNS MUST do when it
> > receives session data messages without Ns when it was enabled by the LNS.
> I
> 
> Sequencing on data packets within any tunneling protocol is a tricky
> subject.
> 
> IMHO, the LNS SHOULD accept them. One could argue that the LNS should
> have this wiggle room if it "knows" that sequencing is vital for the
> particular state of the protocol being carried or not. I suppose it
> would not hurt to make this more clear in the spec, though there are no
> easy answers here.
> 
> > agree with andy that some mechanism should be recommended for resetting
> the
> > stateful information between LAC and LNS.  How about assigning a bit in
> the
> > common header for this purpose. Anytime either end want to reset the
> > applicable sequence numbers they can set this bit in the control message.
> 
> And then you have to check this bit for every single data packet just to
> enable the failover feature? Probably not a good choice. Error recovery
> should not slow down your data packet performance.
> 
> > This should trigger the other end reset its internal variables for the
> > control and all the data session of the tunnel.  Again this is just an
> > initial thought.
> 
> If we have the freedom to modify the protocol, this can probably all be
> done with explicit signalling. Also, you could decouple the tunnel
> control connection and sessions within if you wish. Bottom line, we
> didn't consider this when designing the protocol at the beginning. If we
> are going to modify the protocol to handle semi-full state failover,
> then we should step back and approach it from a fresh perspective.
> 
> - Mark

---

From: Keyur Parikh <[email-masked]>
Date: Wed, 7 Mar 2001 10:25:44 -0500

"

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

data

I

the
the

- Mark