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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 09 June 2021 11:42 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6813A1080; Wed, 9 Jun 2021 04:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 892AqTmR7fHX; Wed, 9 Jun 2021 04:42:52 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82773A107E; Wed, 9 Jun 2021 04:42:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4G0QG43Jzwz6GB7J; Wed, 9 Jun 2021 04:42:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1623238972; bh=VftsKc3ItP1EwHOgjyaDqP9zjvmgecQUu7w6j6Q6csQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=d8gVDWZnyXdD03G4TvZkM5zc2YV9rUcpbUl6Mqn3b/724pGNei8xkD7yokByLceH/ XBzgAFUGSAGe5wcKQ4sL3IJZWpkJDQ/I4KJcwwDH1Chy7V7EZnUJW0SQi1wF0q3fS5 5LbUyX1iEpxw/0wYOAfuVZrB9xPwDz7fD8SpJB0M=
X-Quarantine-ID: <xpk4paZ5DcjS>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.23.64] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4G0QG26wD3z6GBf4; Wed, 9 Jun 2021 04:42:50 -0700 (PDT)
To: Stewart Bryant <stewart.bryant@gmail.com>, "Andrew G. Malis" <agmalis@gmail.com>, mark@townsley.net
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Ignacio Goyret <ignacio.goyret@nokia.com>, intarea IETF list <int-area@ietf.org>, Derek Fawcus <dfawcus+lists-int-area@employees.org>, pals@ietf.org
References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <YLuFLq7k9akVVHWS@clarinet.employees.org> <CAA=duU2o9YKF5Sfu6VTr5+bUr1JVgaGZh=X4+BQRbMu63FqVsg@mail.gmail.com> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <aea7a88e-cca8-b3d5-ecf4-d162471e971d@joelhalpern.com>
Date: Wed, 9 Jun 2021 07:42:48 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/hdMuL4RpP_1fFuii22pD7QGU3tE>
Subject: Re: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always?
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jun 2021 11:42:58 -0000

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 <agmalis@gmail.com 
>> <mailto:agmalis@gmail.com>> 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 
>> <dfawcus+lists-int-area@employees.org 
>> <mailto:dfawcus%2Blists-int-area@employees.org>> 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
>>     Int-area@ietf.org <mailto:Int-area@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/int-area
>>     <https://www.ietf.org/mailman/listinfo/int-area>
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org <mailto:Int-area@ietf.org>
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>