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

David Allan I <david.i.allan@ericsson.com> Wed, 09 June 2021 17:41 UTC

Return-Path: <david.i.allan@ericsson.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 EA8543A1FD3; Wed, 9 Jun 2021 10:41:00 -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, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=ericsson.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 sIOkWsK6-Fbg; Wed, 9 Jun 2021 10:40:55 -0700 (PDT)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2078.outbound.protection.outlook.com [40.107.92.78]) (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 8E06E3A1FCE; Wed, 9 Jun 2021 10:40:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NUX1zRYc5TBdPcBCDAwlhLeN+g+wWKmErf8229mqVlHiztS3RS+4e32HJVXoyvjp4xM696NWv+YYj+llB5XfsMF+ZAe69Zk9hMl+urrbQ86RmzmMe/dyxOV7fCEArcmgeXQiSrk5BHasS1vaeSxcneTPjXV/Qjmrp7s82wUGWncvykW1Q1a8iweibXXssIQekPqBGzR0r9AO3dmsFj7CFylgTe2dmCGqhVJO4aLMpx2f63fXZe7qjiq7WB7kFKof6c55uffNIijolAtb7BY6AoeMguvJtGXPApoNKZkgVKkoClfOZgZiWA9ueO4Dbnk2/7wH6kQ82OgUQovgRsVG4g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E6h6GyGUgIJpC3gFdNcBkllNvZsGHM9ydHc2CjUpvA0=; b=dWFYcsth4rmy5+SOyiT346u9YmBAGaapeTNuR4Znj7Wtg9uFjA7jvsQub0ecYTdb+wQWjTU2a5uc/reSBK4KDSUkmJERh/IWROoSsPe7iKeCsepd5j+mcy3tXPvB8ovC7+J70ojZcmRfPrTGCGNjM7/L3dm92kJhVMCUfBx+JHqLLYZh6UVrbq7cNjwkfQZCfKcNb5vqWEGBXNjE4fGLZDbawBxkwgTKnm0VCPiQwcZ2k2wnp7kd+DlttjhZsG8yr9F/4DglWT7oirWBwIYWRY/7psfHQycS9IS952GxM0NCCxVQ+R6FLPLMsqKXwqDPqoh3tkmAwhG4DweHUuyByQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E6h6GyGUgIJpC3gFdNcBkllNvZsGHM9ydHc2CjUpvA0=; b=aE+xoh2YpDOWW7s5vOaIlbYXfwoxzQVHNhDx8FjIJuXulI9sUWmS3wjzpmuDxwgNezd2Mk5kXWYmunzASRTFdyAOcxmV10lM493/t2xSY1SPezuojQA/kcj0xU9ScUWaurCu7nsJW7NvWdp2OH7FppucJuDmZibhf+PWcUQzgmM=
Received: from MW4PR15MB4474.namprd15.prod.outlook.com (2603:10b6:303:103::8) by MWHPR15MB1630.namprd15.prod.outlook.com (2603:10b6:300:11b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21; Wed, 9 Jun 2021 17:40:53 +0000
Received: from MW4PR15MB4474.namprd15.prod.outlook.com ([fe80::f12b:6996:419b:e084]) by MW4PR15MB4474.namprd15.prod.outlook.com ([fe80::f12b:6996:419b:e084%6]) with mapi id 15.20.4195.030; Wed, 9 Jun 2021 17:40:53 +0000
From: David Allan I <david.i.allan@ericsson.com>
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>, Stewart Bryant <stewart.bryant@gmail.com>, Joel Halpern <jmh@joelhalpern.com>
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" <pals@ietf.org>
Thread-Topic: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always?
Thread-Index: AQHXWUvVJNiI14BCqEOLTkUDM21D+qsFdbUAgAU1u4CAANTQAIAAFkwAgAACBoCAABZgAIAASXng
Date: Wed, 9 Jun 2021 17:40:52 +0000
Message-ID: <MW4PR15MB4474859FBAA3265BD73A5CB5D0369@MW4PR15MB4474.namprd15.prod.outlook.com>
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> <aea7a88e-cca8-b3d5-ecf4-d162471e971d@joelhalpern.com> <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com>
In-Reply-To: <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [76.28.201.119]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aa24762a-c028-464a-57ab-08d92b6dba82
x-ms-traffictypediagnostic: MWHPR15MB1630:
x-microsoft-antispam-prvs: <MWHPR15MB16300A819A16DBAB5E9817C2D0369@MWHPR15MB1630.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: j1oZsUuv7yCmEEH+E5E+hIjiPaO2vkV6ITFuJflbb/jUuwqvjiCh1Vm05kBQgGyO6Q0Oqu1yKCqt354TPrDw8CaE8DPyyrae9H+TGp7kuMnfTUbdhLkkjjqt5QGnK8Z//3m8z10vQhCaulJK7q0YM0GJQUmK/MBymZcd6R6XZD5B2L3VSoIq7a4MnxePGzS6IHLuwABhARhfIa3zWz8b7Z5wtZMWxuYELT25mKU0W6clnDqU4eVehi+V1/sRaIc+J0W5VyGZwzRpINtIB3fZLe3nEwmYo9QFbYsPALQYy697+94lsFGdxGffNRck7sPOUbSuk8AOOSkWfGBnBRXxCFLCWsf4I25hZ3fCEQms64FwiO5DPzyDCb6lzMH6myf8MRwCS79PoGxyRnIxdkr4pqCijyvthwYFrCKr8bp6jmWc1nkwqQ6yQHQn5kTGrAlGFQh+rPTqEshjjSYtHMN1kXvczGXe8qvZcC05iKtJm4C/rLT9hanueSOlLNRiDZVUNA7q0dGr2LeCBzyI5YXkXKzXbxyNEWCiP1HedZB9UbgdMqhiPiv9JL8rQ4jOXpEZLZ3JgJwm0IZM7zlLShUQLc6Y5dSBOvHarW/OzzvJ4/i7R/w3dFo/lGuHK3p3YUi2Lqwd/AFnhUaSA4xymACXQlRE/y7CJf/va2+/aA3r94KdaQIZeE4E8L+HZKTGZIPJjOJniyqy7Idg/oyyHjZ1hBucQi83S+vmklhvxnF+5c8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW4PR15MB4474.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(39860400002)(396003)(366004)(136003)(4326008)(8676002)(83380400001)(316002)(478600001)(110136005)(86362001)(966005)(71200400001)(55016002)(2906002)(53546011)(7696005)(6506007)(33656002)(9686003)(8936002)(26005)(38100700002)(66946007)(122000001)(64756008)(66556008)(66446008)(66476007)(52536014)(5660300002)(54906003)(76116006)(186003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?0c0ML5pc9CpwvGJoeTy1hIp/9KIs+MANtceD4UFUglZksGVezf5jpMSGF2ta?= =?us-ascii?Q?u8LmGwpF+MYQhzHjo3YGA2yPts0ju7p9Ja70NUpHaBAtwIVeD1/Lu5fRvVX8?= =?us-ascii?Q?LbckY9hM9n7ic34V9w6ynIuaM/AX/d4FaymvuP1fRuq4rx0yEkNiCLtBCNBF?= =?us-ascii?Q?Yfl7uiA0t5O++OsQNvHMZWP2U6RYcJSqn5UoDrQ7GZqRJkNmHN9Mb+G5z1Uw?= =?us-ascii?Q?LErP1Tribq3uZfNfhm6jBn0s7MG9jXefiSbHyO+gWvUZFffsILdm6nA16Knf?= =?us-ascii?Q?XGJrraoQXl0f0GAdy2WmEsvBnAu1tQrY9MJxYIXq1BW3w9pRuUUDNizVHJyr?= =?us-ascii?Q?InI0Td7p6Yy9KZ/1FA2qZwP1y8KQPmcj7pIDfOYFxaxDQf+5Mhax9rlstnU9?= =?us-ascii?Q?73PrwIeK6S/lPdH1EhxrkPNjVaNOCUtqSkGim24WZ7zebW/EyCqieVXjBgvr?= =?us-ascii?Q?bKODu91sIf9DGcMUzIp2A0g8j4L9DFRfhc6RzF5WIxPlbMfaQYOkKD8Qx6XU?= =?us-ascii?Q?eakXy1qUxhDBsxgHSjwtm9/xylh/B1yDBL8WJGxxiP3uyjBi1e3RqtXEcd04?= =?us-ascii?Q?s8MTVcohMexI4dkHXZZd2Gy/p/Dq/qaZOzhZTft/LDYnz6bPJqPhgMpEwKax?= =?us-ascii?Q?eIKvfHJBsSHmwc+LZ6eOjYRMbMutlSOmttCFaXYTVxpjvU0Zjnv7KKfaqr3X?= =?us-ascii?Q?FJfBfg0nvc94cXqdzZC6gdeBPAms0ceoaTZKA0cXnBpuK8Kz0+hctBAENWP6?= =?us-ascii?Q?ViLdc1azjZOXYePkRpmiC21mVoZ0cEFmfKrsW51XdmLLstFtUK+l3mH1/nEm?= =?us-ascii?Q?DFX8Sjr4Wys/n8RWjujrdzEsIkTP5ah0oTSfpaotyeF7voIjDv7nCfdsSBIV?= =?us-ascii?Q?xV7iFKKwKD8lrMd+Ru0yEphhufg6of358ReTT/CfcSucRPnUjki787s8/Wda?= =?us-ascii?Q?zV0xrIm0BZZQBcD6YtzmT4U7SJbiCEEeDbTAWezSgLDGpVARlHSDPJHEZ4tC?= =?us-ascii?Q?l9rj316a2hYRoHFZBwMBpSy19MBIeDMB4hPODMRH3N0cTiFzzMvS+UgdEF60?= =?us-ascii?Q?RAOgy2stnS396KeDBH1pPaFHx5rMvzf2o3QDYPn9fJRDg0DF9BTjFiHbldBb?= =?us-ascii?Q?iRwCnai7z8HuJw0+XbVWAY0rqRB+mfpMB0q9xnsXjN/5XivSzWRRI/NrEHPr?= =?us-ascii?Q?j4VG1XbMDwb8gnBrAEtz0UewttIDvaAzGuCXCiFILQyyUXkNMHiigB+r4TCq?= =?us-ascii?Q?WNXdaotmp3sGGfTL5xyP/jWlmJ7hTv8Tv+ijxjtG3jPxQuSIvPGouiSQ8Phm?= =?us-ascii?Q?JAwpPdmL0z9MFuzSdhXdCi3H?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW4PR15MB4474.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aa24762a-c028-464a-57ab-08d92b6dba82
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2021 17:40:52.9044 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bjNTlUDWJcyesRPmzrQK9i+gNRJkj0eaSQ/Z/n9/8fezwO+njGvQkGIZmRP171enAQXMmMnpXlMqYZW1JJKIPNDNF3OI5l/ytMPsjgmSdgk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1630
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/onPngRty2uWYq5gJRDOGdwN5EI4>
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 17:41:01 -0000

These is a significant number of operators that use PPPoE, and L2TP. Either simply for backhaul (where old ATM based DSL is still deployed and elsewhere) and/ or wholesale.  I checked BBF TR-92 which would be the like source of any recommendations on using sequencing but it is silent on the subject.

Dave

-----Original Message-----
From: Int-area <int-area-bounces@ietf.org> On Behalf Of Joel Halpern Direct
Sent: Wednesday, June 9, 2021 6:10 AM
To: Stewart Bryant <stewart.bryant@gmail.com>om>; Joel Halpern <jmh@joelhalpern.com>
Cc: Carlos Pignataro (cpignata) <cpignata@cisco.com>om>; Ignacio Goyret <ignacio.goyret@nokia.com>om>; intarea IETF list <int-area@ietf.org>rg>; Derek Fawcus <dfawcus+lists-int-area@employees.org>rg>; pals@ietf.org
Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always?

BNGs are still a big busienss.  And BNG resale /emote control uses L2TP in many cases.  The BBF has been working on (and published a first version of) protocol for control of split BNG.  L2TP is commonly used for these use cases.

Yours,
Joel

On 6/9/2021 7:50 AM, Stewart Bryant wrote:
> Which applications still use it Joel?
> 
> Stewart
> 
>> On 9 Jun 2021, at 12:42, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>
>> 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
> 

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area