Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always?

There is plenty of L2TP still in use.
Yours,
Joel

On 6/9/2021 6:23 AM, Stewart Bryant wrote:
> Sequence number checking in the forwarder is always a problem because it 
> is stateful so I doubt that many high-scale or high-speed forwarders 
> ever did this.
> 
> I think there is an undisclosed assumption that go up enough levels and 
> its IP so sequence number checking in the transport network (as opposed 
> to the transport layer) is not really needed.
> 
> I doubt that there is much L2TP still out there. It was in its prime 
> with dialup modems. L2TPv3 which was intended to replace it became niche 
> with, as Andy says, operators who did not want MPLS. Much of what L2TPv3 
> was intended for was actually done with PW over MPLS with some 
> replacement with by Mac in Mac for cost reasons.
> 
> If Carlos does not know the answer, Mark T would be my next port of call.
> 
> Stewart
> 
> 
> 
>> On 8 Jun 2021, at 22:41, Andrew G. Malis <[email protected] 
>> <mailto:[email protected]>> wrote:
>>
>> Bob,
>>
>> In addition to the cases listed by Derek, L2TPv3 can also carry non-IP 
>> pseudowire data, such as Ethernet frames (see RFC 4719 for example). 
>> Even though 4719 says that sequencing is optional, I would certainly 
>> recommend it :-).
>>
>> But I guess that's really not what you were asking about, since you 
>> specifically mentioned IP data. But it is a case where you would 
>> probably see sequencing in use.
>>
>> Back in the day, Sprint made good use of Ethernet over L2TPv3, as they 
>> were in the anti-MPLS camp at the time. But that's water over the 
>> bridge, and I really don't know if this solution continues to be in 
>> active use. Mark Townsley might know.
>>
>> Cheers,
>> Andy
>>
>>
>> On Sat, Jun 5, 2021 at 10:07 AM Derek Fawcus 
>> <[email protected] 
>> <mailto:dfawcus%[email protected]>> wrote:
>>
>>     On Fri, Jun 04, 2021 at 03:13:15PM +0100, Bob Briscoe wrote:
>>     > The L2TP RFC says sequencing /can/ be disabled for IP data, but it
>>     > doesn't say SHOULD or MUST. Is it possible that some operators
>>     enable
>>     > L2TP sequencing for IP data? And if so, do you know why they would?
>>     > Also, are you aware of any other types of tunnel that might try
>>     to keep
>>     > IP data packets in sequence?
>>
>>     How many intermediate headers are you considering between L2TP and
>>     where
>>     a carried IP header may exist?
>>
>>     Maybe I'm getting the wrong end of the stick, but surely this engages
>>     the text from section 5.4 of RFC 2661:
>>
>>       "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."
>>
>>     This would then suggest if L2TP is carrying PPP, the PPP session
>>     is not
>>     multi-link, and is making use of compression (including one of the
>>     versions of IP header compression) in some form for IP packets, then
>>     reordering will impact the ability to decompress.
>>
>>     So such an L2TP data session may well make use of sequence numbers to
>>     prevent reordering.
>>
>>     I guess similarly in L2TPv3 when the PW is for PPP, and possibly also
>>     the fragmentation scheme in RFC 4623 which requires sequence numbers;
>>     and such PWE3 links could ultimately be carrying IP packets.
>>
>>
>>     DF
>>
>>     (not an operator)
>>
>>     _______________________________________________
>>     Int-area mailing list
>>     [email protected] <mailto:[email protected]>
>>     https://www.ietf.org/mailman/listinfo/int-area
>>     <https://www.ietf.org/mailman/listinfo/int-area>
>>
>> _______________________________________________
>> Int-area mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> 
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area
>