From nobody Fri Jun 4 07:13:26 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8743A134D for ; Fri, 4 Jun 2021 07:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 37s2P6FyTY1c for ; Fri, 4 Jun 2021 07:13:20 -0700 (PDT) Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.85.90]) (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 BA8F93A1342 for ; Fri, 4 Jun 2021 07:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: To:Subject:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=y7QPL6OoVo/TCs2QmTULwdN/I1bmLqPYtwG4B1sKz3w=; b=mzGa1HS6NxyBpdrrZN75xl6HgY 0NmFwZA7J5IuLfKBQD+lWNYzCAivUUlbZmXclbSRgGGYHkGUEFTtciTKj/tj4lzDIlWML6CePx4Ky n5V9ZpyElSAHjcuSmA9p+PrUDK6bfV9S3vItFDWEWuuIZNIdD8o4rpTp8xySu0vArIi4T4JQ25PYG CtRVOJ4TekSxbspHqI1/OhEuIzrZtXNWHyNYlaGlx+Zdjifela0/eAekpEHispFDfH92NTMzNwd41 BeFcdQrY9l44ZUybwEHLg7ertn5ZwQnLvVHm0KYyMgdkJmbQofD0NRTNJM4flrIKjluvI9GLInY57 XdzNwadw==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:35650 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lpAZa-000183-D2; Fri, 04 Jun 2021 15:13:18 +0100 From: Bob Briscoe To: intarea IETF list Cc: "Carlos Pignataro (cpignata)" , Ignacio Goyret Message-ID: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> Date: Fri, 4 Jun 2021 15:13:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------95E77910ADC8F258004797EA" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 14:13:26 -0000 This is a multi-part message in MIME format. --------------95E77910ADC8F258004797EA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Int-area list, I'm looking for experience on common L2TP practice, most likely from operators. I tried sending this query to the L2tpext@ietf.org list, as advised by Carlos Pignataro, but apparently it no longer exists. So I think int-area is the "list of last resort" for this. 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? My reason for asking: We (in tsvwg) are working on active queue management technology. Certain AQM schemes (e.g. FQ-CoDel, L4S) give lower delay to a subset of traffic. If the bottleneck queue supports such an AQM and it is within an L2TP tunnel with sequencing enabled, the egress would hold back all the nice low delay packets until it can put them back into order with the higher delay traffic. We intend to advise that operators MUST disable L2TP sequencing if they wish to deploy these AQMs within an L2TP tunnel. So we need to know: 1. Whether this will create a dilemma for any operators who need L2TP sequencing of IP data for some reason; 2. Or whether we even need to bother giving the advice, because no operator would ever enable L2TP sequencing of IP data anyway. Obviously, some operators already use existing technologies like Diffserv to reduce delay for a subset of IP data traffic, so I assume they always disable L2TP sequencing anyway. Regards Bob Briscoe -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------95E77910ADC8F258004797EA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Int-area list,

I'm looking for experience on common L2TP practice, most likely from operators. I tried sending this query to the L2tpext@ietf.org list, as advised by Carlos Pignataro, but apparently it no longer exists. So I think int-area is the "list of last resort" for this.

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?

My reason for asking:
We (in tsvwg) are working on active queue management technology. Certain AQM schemes (e.g. FQ-CoDel, L4S) give lower delay to a subset of traffic. If the bottleneck queue supports such an AQM and it is within an L2TP tunnel with sequencing enabled, the egress would hold back all the nice low delay packets until it can put them back into order with the higher delay traffic.

We intend to advise that operators MUST disable L2TP sequencing if they wish to deploy these AQMs within an L2TP tunnel. So we need to know:
  1. Whether this will create a dilemma for any operators who need L2TP sequencing of IP data for some reason;
  2. Or whether we even need to bother giving the advice, because no operator would ever enable L2TP sequencing of IP data anyway.

Obviously, some operators already use existing technologies like Diffserv to reduce delay for a subset of IP data traffic, so I assume they always disable L2TP sequencing anyway.

Regards


Bob Briscoe


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------95E77910ADC8F258004797EA-- From nobody Fri Jun 4 08:07:23 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D4A3A157A; Fri, 4 Jun 2021 08:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YyWNNGGSxVhv; Fri, 4 Jun 2021 08:07:16 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3696B3A1579; Fri, 4 Jun 2021 08:07:16 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id f2so9619461wri.11; Fri, 04 Jun 2021 08:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eR1M8wGpbZpKZyV+qnR6HMeMBGidyBgEfexyYvnKt1Y=; b=ucWbiJpfIpOSGIznZC60KfrOSc2wEeTQ5JZuqcA5ueEee6lyoAffKRn8+fdAQN+tjS Zxa0bpE1LvLkK0AJXxd7k4GL6miL/bsHxS0T0PBtnNzetHKETRCbTugZ6gD1bpr61NtD H7TOwCb5ReO5wFTEKcR5qzQarxEO7UDKidBAyIxEHVoxj/I3Jr93IwaRvbW9RA8lGuwS TEnxOc+nQifhRf/ngXNthD5wU9qBwmfroLectmj7X6dO4D51bz7mffkxC5JruBlg/tSP Abe8t0nCFuwXDiEfeBMidWJywyEHUNElHSeyQS6W//D8LkFzYdJnxK9TWpJKFWiusdnf MC4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eR1M8wGpbZpKZyV+qnR6HMeMBGidyBgEfexyYvnKt1Y=; b=SjmCoCMwbewFiRNJa+7Lo2xafwSA1jVGBY/SlQ/23SlKNA1bRvdLHriqoHOjC9KijO IOixRAbClLHJfyEM4H01aDB0HK85/s8jaVxqfaiA1HTJmQaGDnr6qolHfhGxmXm0wDJY aYFXDYJMQ8IfPzcup8BdSQFSU2V1Qw4py1Z11Yw8KR0aiTqhYzgkFlYyf56gnlg+4LjO lhj3Qq+DshpFBXsGftVYNbaOAmhZPuFbhUZBRGbHRrp/pMJvOFAG5O0L26kdNaCqlek+ WGXC+GeqYBLzMyHzdVfzdXW6YxVCR+OHFjpH6D6lhNoQjm080wHfDayOPxOvF2C85lTJ MUJg== X-Gm-Message-State: AOAM531jAChUhlyuB+/TA4kcHsAk2ybel3qOZyKrjY1kdZkLxTPbwoVe rqJmi1wSHnqmCYeqeNAdhZE= X-Google-Smtp-Source: ABdhPJx0v3WadGpns2Gh1Q9GzNBHPD+D8OSICX1PBIFgaC58o0HwExZnNRuuCRRw4FDPb7FfZgv2WA== X-Received: by 2002:adf:fdcd:: with SMTP id i13mr4472832wrs.307.1622819232961; Fri, 04 Jun 2021 08:07:12 -0700 (PDT) Received: from ?IPv6:2a00:23c5:3395:c901:b469:536c:166a:181b? ([2a00:23c5:3395:c901:b469:536c:166a:181b]) by smtp.gmail.com with ESMTPSA id d3sm6681318wrs.41.2021.06.04.08.07.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jun 2021 08:07:12 -0700 (PDT) From: Stewart Bryant Message-Id: <6A5F175D-3907-476A-BF2C-5298C7343BA1@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C775A729-BCCC-45A1-9D9E-78C84EBD0ECA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Date: Fri, 4 Jun 2021 16:07:10 +0100 In-Reply-To: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> Cc: Stewart Bryant , intarea IETF list , "Carlos Pignataro (cpignata)" , Ignacio Goyret To: Bob Briscoe , pals@ietf.org References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 15:07:22 -0000 --Apple-Mail=_C775A729-BCCC-45A1-9D9E-78C84EBD0ECA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Adding PALS and someone there may know. Stewart > On 4 Jun 2021, at 15:13, Bob Briscoe wrote: >=20 > Int-area list, >=20 > I'm looking for experience on common L2TP practice, most likely from = operators. I tried sending this query to the L2tpext@ietf.org = list, as advised by Carlos Pignataro, but = apparently it no longer exists. So I think int-area is the "list of last = resort" for this. >=20 > 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? >=20 > My reason for asking:=20 > We (in tsvwg) are working on active queue management technology. = Certain AQM schemes (e.g. FQ-CoDel, L4S) give lower delay to a subset of = traffic. If the bottleneck queue supports such an AQM and it is within = an L2TP tunnel with sequencing enabled, the egress would hold back all = the nice low delay packets until it can put them back into order with = the higher delay traffic. >=20 > We intend to advise that operators MUST disable L2TP sequencing if = they wish to deploy these AQMs within an L2TP tunnel. So we need to = know: > Whether this will create a dilemma for any operators who need L2TP = sequencing of IP data for some reason; > Or whether we even need to bother giving the advice, because no = operator would ever enable L2TP sequencing of IP data anyway. >=20 > Obviously, some operators already use existing technologies like = Diffserv to reduce delay for a subset of IP data traffic, so I assume = they always disable L2TP sequencing anyway.=20 >=20 > Regards >=20 >=20 > Bob Briscoe >=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ = _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --Apple-Mail=_C775A729-BCCC-45A1-9D9E-78C84EBD0ECA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Adding PALS and someone there may know.

Stewart



On 4 Jun 2021, at 15:13, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Int-area list,

I'm looking for experience on common L2TP practice, most likely from operators. I tried sending this query to the L2tpext@ietf.org list, as advised by Carlos Pignataro, but apparently it no longer exists. So I think int-area is the "list of last resort" for this.

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?

My reason for asking:
We (in tsvwg) are working on active queue management technology. Certain AQM schemes (e.g. FQ-CoDel, L4S) give lower delay to a subset of traffic. If the bottleneck queue supports such an AQM and it is within an L2TP tunnel with sequencing enabled, the egress would hold back all the nice low delay packets until it can put them back into order with the higher delay traffic.

We intend to advise that operators MUST disable L2TP sequencing if they wish to deploy these AQMs within an L2TP tunnel. So we need to know:
  1. Whether this will create a dilemma for any operators who need L2TP sequencing of IP data for some reason;
  2. Or whether we even need to bother giving the advice, because no operator would ever enable L2TP sequencing of IP data anyway.

Obviously, some operators already use existing technologies like Diffserv to reduce delay for a subset of IP data traffic, so I assume they always disable L2TP sequencing anyway.

Regards


Bob Briscoe


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

--Apple-Mail=_C775A729-BCCC-45A1-9D9E-78C84EBD0ECA-- From nobody Sat Jun 5 07:07:47 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FF43A10A6 for ; Sat, 5 Jun 2021 07:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 tNJjjP9OoYD0 for ; Sat, 5 Jun 2021 07:07:43 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FAC3A10A0 for ; Sat, 5 Jun 2021 07:07:43 -0700 (PDT) Received: by clarinet.employees.org (Postfix, from userid 1736) id 68E934E11CE2; Sat, 5 Jun 2021 14:07:42 +0000 (UTC) Date: Sat, 5 Jun 2021 15:07:42 +0100 From: Derek Fawcus To: Bob Briscoe Cc: intarea IETF list , "Carlos Pignataro (cpignata)" , Ignacio Goyret Message-ID: References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> Archived-At: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2021 14:07:45 -0000 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) From nobody Tue Jun 8 09:29:42 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2D63A35C8; Tue, 8 Jun 2021 09:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 1cRFkla8i1E1; Tue, 8 Jun 2021 09:29:29 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324FD3A35C7; Tue, 8 Jun 2021 09:29:28 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1373E54804B; Tue, 8 Jun 2021 18:29:22 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 05C354E76DC; Tue, 8 Jun 2021 18:29:22 +0200 (CEST) Date: Tue, 8 Jun 2021 18:29:21 +0200 From: Toerless Eckert To: ohttp@ietf.org, tsv-area@ietf.org, int-area@ietf.org Message-ID: <20210608162921.GJ3909@faui48e.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Int-area] Comments on ohttp WG and technical proposal X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 16:29:34 -0000 a) WG: I think there should be first substantial discussion about the subject matter on the mailing list (ohttp) before proceeding on a WG request for this work. b) Draft: Neither the charter text, nor draft-thomson-http-oblivious provide a (to me) good persuasive high level explanation or justification for the use-case. Something as easy as "A client who does not want its source-address be traceable by a target-resource needs a mechanism to orchestrate the following:" client <-> proxy-resource <-protected-leg-> request-resource <-> target-resource and discussion of the questions arising from the model. Such as what expectations against the proxy-resource are necessary to make this useful at all. c) Concept: Except for the likely (absent better text i can only guess) business cases of the proponents of the WG, who from their perspective may not be interested in a broader solution but want to build something constrained to just http, i for once think it would be lot more useful for the IETF to work on such a solution with more generality. For example, i think we could have with comparable standardization effort such an orchestration resulting in a transparent transport (TCP) connection between client and target-resource, allowing the scheme to be used for any protocol across that connection, and not only for the exchange of http messages between client and target-resource. Such work might then of course be better suited for a TSV WG or maybe an INT WG han i guess an ART WG where ohttp might end up in if it get chartered. d) I am guessing that there is the assumption that a generic transport/TCP connection connection model will have specific downsides such as more round-trips for packet exchanges, but that comparison is really important to document, and i am no even sure if it holds true, because if the proposed solution can deliver at e.g.: 0 additional round-trips an HTTP get request from the client to the target resource, than so could that AFAIK simply be a TCP message. Cheers Toerless -- --- tte@cs.fau.de From nobody Tue Jun 8 14:41:42 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122383A05A6 for ; Tue, 8 Jun 2021 14:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GJfAApGJdlmj for ; Tue, 8 Jun 2021 14:41:36 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEED63A05F0 for ; Tue, 8 Jun 2021 14:41:36 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id c138so8904418qkg.5 for ; Tue, 08 Jun 2021 14:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W0+pn1fa8q9eBWhWxS89Qr2hNHds7IW9z58mQr5TZCM=; b=XG/dfkaypkECqLjAdlKzMUbDmxEYo6BGd5EgrkUwiQIs6aleQBUsRWOaZuxuktHzVv HznuByDSEssSpxi2PWQN/cl/lNRMLGVbW2Mt7MNw4KPc4v58eamiYNc5qy7AlEGwGDEH bo+1jpObnuvXb8iFwAEJQ+1II5ONNhFAxgA5JAHVOQ5kNnDZQ1gMA1tUxwMwAZNU/Hdo 1RoBcfJBDhsaQcefj/OOqMHYJ7+faXxEl4urfzEVn07s56NcKjcNq/btwLqlX2NWeLDo fpby6xrLdC/uExCkBoZ/jS1yu4klcfqo16FozMqB8qIuoXu3EkzFszAJeMjH2Kayd1kQ l/7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W0+pn1fa8q9eBWhWxS89Qr2hNHds7IW9z58mQr5TZCM=; b=kG6VxCaufRQVIbg6Lp7OuqxhmLjomL2CjSOYZQ9HW8nGEwkBg5Xo1V0wEGWkyep/pJ MvxS6NagIVsoznQVr1CUuSO1N6O60Cy+o0tlqIMTeWCNM0TGovP60P7tNfR9w/0Oi1qh sjkvajdt4Cluiwul7/DHzeb/WCEA0UN+u003mJNxY0a5PMhnmexp9rtdTXYEO4pnlwYP LXM1IsoS5JD1A53VX3lbFP6+ghJ2fajQ3t8a+EhRkfjL/FBmPso0m+/QqnwyZvowCgcF pyFb2/qTir506ULhMxdILxUCrlhER8bCUAZRFMVUFc8pCYm6ENdhltmZA1P37eDww3YP qzEQ== X-Gm-Message-State: AOAM532ICK0UvuME9rPv3Vf5tdA0OJXbNTLo307ob/+cYgNNSyrA3F1M Qk2QJpj4hMjV7wYPbp1hlTuonKp2v+aDC3itScg= X-Google-Smtp-Source: ABdhPJyzwpflZ6DyfoShU/ZAHKFPrLoeRZwJGccJPQPQaGVWNMAplsWUh6Vca/DrQBQMnNe5kCNkqlv5UNkcPwGqT6s= X-Received: by 2002:a37:a283:: with SMTP id l125mr16422591qke.476.1623188495036; Tue, 08 Jun 2021 14:41:35 -0700 (PDT) MIME-Version: 1.0 References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> In-Reply-To: From: "Andrew G. Malis" Date: Tue, 8 Jun 2021 17:41:19 -0400 Message-ID: To: Derek Fawcus Cc: Bob Briscoe , "Carlos Pignataro (cpignata)" , Ignacio Goyret , intarea IETF list , Mark Townsley Content-Type: multipart/alternative; boundary="000000000000a6744205c4480520" Archived-At: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 21:41:41 -0000 --000000000000a6744205c4480520 Content-Type: text/plain; charset="UTF-8" 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> 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 > https://www.ietf.org/mailman/listinfo/int-area > --000000000000a6744205c4480520 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bob,

In addition to the cases listed by= Derek, L2TPv3 can also carry non-IP pseudowire data, such as Ethernet fram= es (see RFC=C2=A04719 = for example). Even though 4719 says that sequencing is optional, I would ce= rtainly 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 yo= u would probably=C2=A0see sequencing=C2=A0in use.

Back in the day, Sprint made g= ood 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=C2=A0continues to be in active=C2=A0use. Mark=C2=A0Townsley=C2=A0might know.

Cheers,
Andy


On Sat, Jun 5, 2021 at 10:07 = AM Derek Fawcus <dfawcus+lists-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 ena= ble
> 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 kee= p
> 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:

=C2=A0 "For example, if the PPP session being tunneled is not
=C2=A0 =C2=A0utilizing any stateful compression or encryption protocols and= is
=C2=A0 =C2=A0only carrying IP (as determined by the PPP NCPs that are
=C2=A0 =C2=A0established), then the LNS might decide to disable sequencing = as IP
=C2=A0 =C2=A0is 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
https://www.ietf.org/mailman/listinfo/int-area
--000000000000a6744205c4480520-- From nobody Wed Jun 9 03:23:32 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904AE3A0743; Wed, 9 Jun 2021 03:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UIgAINyi41JM; Wed, 9 Jun 2021 03:23:04 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402E93A0766; Wed, 9 Jun 2021 03:23:04 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id r9so8162471wrz.10; Wed, 09 Jun 2021 03:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EeXRZySFhjmKJko/ZLCzT+5ohGL1YUOKA+TZ8eLLd+E=; b=dl1gVSkSTGPYFYt9mzwcihZDg+1P5foicwhsBsX2FK5ljCD8x65Nx1LLR8MWjnerTX 7hEExVz6pYvTrK7qVm9eqnpMLCsYQ4ZUmHgxV5pLp+nAQXNVTXuUuOJeNKai3r+T5V4B OL8dyviNCySSWlBhfaL0LNLGbYMw1duzhVbN4pYCW1Z5X29NICx4+r8oF98Tdd/X1ZRL WZxWoMJXRnIyLYlDO0V+6dawi8kaqnZ3KQtFOqrAK6+IqjngiyrRMEMmD659x7iEADCr koPi4hUk8qrX2fOQHF84qP6bRYL9wB9pi8EX2V2BHDikc1qNAH8PDOp+fv273O3xYsUy 6IAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EeXRZySFhjmKJko/ZLCzT+5ohGL1YUOKA+TZ8eLLd+E=; b=H7A0VdfWkZ/DzvGyg3LkdbC1WVQkNxul4qlMN0guD7REcPVpWD6tB2Y1NHT4fs/Xhz StUxV6JFNofRwemyG7nYRnirOzZWRqRL6Z3zxVZqhgZnDGn0Q5kUMhTry836kbowBb8m HzoqLXNttpFHHAFOP+EST6GZM0LoF78TEerlTd/pmn2hS58EUL4lYH4OiEvXwa79QC4I 5yjC67MkETiChKx+LCYZ9bLI40Hf9m75prfzLHEuP8BehxzlLMt0dwrh9fQ0f+QGn8jL T2yaM0Zm5aF+9QNHowpcnL8hiBjGZB2wUvHLa7+0cBUa2nMrb3w6ZU1e55nJYLbde7h6 LWTg== X-Gm-Message-State: AOAM531r235qGtP32GYJnaMZ3zVMHZR2Jq4m08iF8SKsCnR93ZGVPfPp wMnT5dpCkeKPKz2mHHWYn2g= X-Google-Smtp-Source: ABdhPJxxO/ggE6Q7aE/hp7OMn8JEgDhblG3ZIPIqf7UdE5LgSC5wTK2VKm2e8NFLY/RSq6Dn1Uzpxw== X-Received: by 2002:a5d:4a4e:: with SMTP id v14mr27189013wrs.74.1623234182011; Wed, 09 Jun 2021 03:23:02 -0700 (PDT) Received: from [192.168.8.162] ([85.255.233.46]) by smtp.gmail.com with ESMTPSA id u15sm5327839wmq.1.2021.06.09.03.23.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Jun 2021 03:23:01 -0700 (PDT) From: Stewart Bryant Message-Id: <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E2F4FD6B-4B30-4BEB-97AC-530027EA19A6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) Date: Wed, 9 Jun 2021 11:23:00 +0100 In-Reply-To: Cc: Stewart Bryant , Derek Fawcus , "Carlos Pignataro (cpignata)" , Ignacio Goyret , intarea IETF list , pals@ietf.org To: "Andrew G. Malis" , mark@townsley.net References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 10:23:10 -0000 --Apple-Mail=_E2F4FD6B-4B30-4BEB-97AC-530027EA19A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 wrote: >=20 > Bob, >=20 > 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 :-). >=20 > 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. >=20 > 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. >=20 > Cheers, > Andy >=20 >=20 > On Sat, Jun 5, 2021 at 10:07 AM Derek Fawcus = > 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=20= > > doesn't say SHOULD or MUST. Is it possible that some operators = enable=20 > > L2TP sequencing for IP data? And if so, do you know why they would?=20= > > Also, are you aware of any other types of tunnel that might try to = keep=20 > > IP data packets in sequence? >=20 > How many intermediate headers are you considering between L2TP and = where > a carried IP header may exist? >=20 > Maybe I'm getting the wrong end of the stick, but surely this engages > the text from section 5.4 of RFC 2661: >=20 > "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." >=20 > 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. >=20 > So such an L2TP data session may well make use of sequence numbers to > prevent reordering. >=20 > 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. >=20 >=20 > DF >=20 > (not an operator) >=20 > _______________________________________________ > 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 --Apple-Mail=_E2F4FD6B-4B30-4BEB-97AC-530027EA19A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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> 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> 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
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area = mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

= --Apple-Mail=_E2F4FD6B-4B30-4BEB-97AC-530027EA19A6-- From nobody Wed Jun 9 04:19:57 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891883A0E55; Wed, 9 Jun 2021 04:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Yh9gC3-Fj6MM; Wed, 9 Jun 2021 04:19:53 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B84C3A0E4B; Wed, 9 Jun 2021 04:19:52 -0700 (PDT) Received: by clarinet.employees.org (Postfix, from userid 1736) id 69E1E4E11D1E; Wed, 9 Jun 2021 11:19:52 +0000 (UTC) Date: Wed, 9 Jun 2021 12:19:52 +0100 From: Derek Fawcus To: Stewart Bryant Cc: "Andrew G. Malis" , mark@townsley.net, "Carlos Pignataro (cpignata)" , Ignacio Goyret , intarea IETF list , pals@ietf.org Message-ID: References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> Archived-At: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 11:19:56 -0000 On Wed, Jun 09, 2021 at 11:23:00AM +0100, Stewart Bryant wrote: > > I doubt that there is much L2TP still out there. It was in its prime with dialup modems. Stewart, Isn't the BT wholesale ADSL product still using it? Someone recently pointed to their SIN 472, which reference RFC 2661 not 3931. I don't know what other countries are doing for ADSL service, and in how many ADSL is a live vs legacy product. Certainly my ISP describes how one can connect to them using L2TP mainly because they have the backend available for supporting the various 'broadband' access facilities. They also offer ADSL access via another provider, so maybe they're also using L2TP? So maybe the UK deployment doesn't count a 'much'. DF From nobody Wed Jun 9 04:43:22 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: 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 , "Andrew G. Malis" , mark@townsley.net Cc: "Carlos Pignataro (cpignata)" , Ignacio Goyret , intarea IETF list , Derek Fawcus , pals@ietf.org References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> From: "Joel M. Halpern" Message-ID: 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: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > 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 >> probablysee sequencingin 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 solutioncontinues to be in >> activeuse. Mark Townsleymight know. >> >> Cheers, >> Andy >> >> >> On Sat, Jun 5, 2021 at 10:07 AM Derek Fawcus >> > > 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 >> 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 > From nobody Wed Jun 9 04:48:34 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD303A110B; Wed, 9 Jun 2021 04:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 evuNuQirg61l; Wed, 9 Jun 2021 04:48:27 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7773A1107; Wed, 9 Jun 2021 04:48:27 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id r9so8438312wrz.10; Wed, 09 Jun 2021 04:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=221UgPhfV+ulso1hzm3N4e/JkZMFoDsba2qLoOY6FZM=; b=lHMmZCmZN45vLhT8zHvXYjQsxOyFt7AbawDVQt/krIX1Xm7smLrU/hGWUso9WgNXjk 5sKIG3k3fDYn+i24OPOnF/1L1o0QhZO35QlfLe5EWMlzWQ6SLMfgF5bz+nOpAXRZ4C2+ YOwM4rmhYsibwBlIQULvmuhHYXiLIcj3w61wziWdEHAANT1/Vhxj/oFlLmra8u8A+zMe iawFEoVjqNE74H/0XSTUDN3Hrz9JyeqtUww0JFUv0kCl5XkyByut6yA35WjPaeFlf9CH Ga6nPsE4swZMco1LHALYKqF1+FSVE0YMpGnZ6f5BVLr+6fqfXFivQBI4SE5LtLzWTc5K ccxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=221UgPhfV+ulso1hzm3N4e/JkZMFoDsba2qLoOY6FZM=; b=INvrAF1tkQ5zoKogLyKXutop/H0hp2kl7eZhyg4VgYIPNVqeov2DP2KxjOB9zI8ZQV IavqFi0MdMxpeOioLaMXCk9VJn2khvO1lYx/tKxJQH2xdu2RVb8FOTNJWtEO538vyhwe QfQqrhBuRfLCbuTawWUUt5QBqDmt57zFTN3tov5up9NikC9UwOhfT7YovoyX3berMUWE WaP954tOEUvOjpNIMSH2OCrcJP6IV/QGerbe6gnHx/0tec3kJT4kXXf/tD70p+HYPPpC UgAObAaf+k8FC5UylrIGtpBIlRBA+TMX9qvtf4gkWKFmWx0DDdCYE81hOPhK1qWZ9EJ7 mOgQ== X-Gm-Message-State: AOAM530Lm1hs6eaumgnF/+Ce9jf4/16QX1H25vpniBm/NqYBv56J/HQ4 P735yrP4oP2M/EFfvYJfY5Q= X-Google-Smtp-Source: ABdhPJzYBxKHsHIgRVyobq7U+111lkU5IfLWODxqdd/6UevMTUoWgu0LMDfC65PprjCfsuzO4+mpBg== X-Received: by 2002:a5d:4ac5:: with SMTP id y5mr28255912wrs.18.1623239304413; Wed, 09 Jun 2021 04:48:24 -0700 (PDT) Received: from [192.168.8.171] ([85.255.233.46]) by smtp.gmail.com with ESMTPSA id c2sm6367471wmf.24.2021.06.09.04.48.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Jun 2021 04:48:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Stewart Bryant In-Reply-To: Date: Wed, 9 Jun 2021 12:48:22 +0100 Cc: Stewart Bryant , "Andrew G. Malis" , mark@townsley.net, "Carlos Pignataro (cpignata)" , Ignacio Goyret , intarea IETF list , pals@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> To: Derek Fawcus X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 11:48:32 -0000 > On 9 Jun 2021, at 12:19, Derek Fawcus = wrote: >=20 > On Wed, Jun 09, 2021 at 11:23:00AM +0100, Stewart Bryant wrote: >>=20 >> I doubt that there is much L2TP still out there. It was in its prime = with dialup modems. >=20 > Stewart, >=20 > Isn't the BT wholesale ADSL product still using it? >=20 > Someone recently pointed to their SIN 472, which reference RFC 2661 = not 3931. > I don't know what other countries are doing for ADSL service, > and in how many ADSL is a live vs legacy product. >=20 > Certainly my ISP describes how one can connect to them using L2TP = mainly because > they have the backend available for supporting the various 'broadband' = access > facilities. They also offer ADSL access via another provider, so = maybe they're > also using L2TP? >=20 > So maybe the UK deployment doesn't count a 'much=E2=80=99. >=20 > DF I suppose the ADSL product may be using it. I thought that it was all = MPLS-PW. We need someone from Openreach to tell us what they are doing. In any case hopefully the last of the xDSL will soon be confined to the = scrap bin it should have been in years ago as part of the plan to = replace copper with FTTP/5G/LEO. - Stewart From nobody Wed Jun 9 04:50:15 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4AF3A111C; Wed, 9 Jun 2021 04:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pJQEE2S82rFu; Wed, 9 Jun 2021 04:50:06 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C173A110B; Wed, 9 Jun 2021 04:50:06 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id 3-20020a05600c0243b029019f2f9b2b8aso4008222wmj.2; Wed, 09 Jun 2021 04:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D5dw13OrhRSzE3FxPT/TcNLSrVzzA73VWO5Cjq6Ef24=; b=qCIO9qGJgMlDvtKfgRW8WOUmE0ygB4JpvUKhEZg0YI27mDcl/ylWqNsVRJOEwJOJCk mzSyGuaLeSy/oxuH3lXbXRHw3KJs+blo4b2LC2gsOVi0D7Og+qMQUk4MdAJu3pe4gEvf 4Kj4xooS2LgTJ+WF2qfKmdFO+zj87Ifjk9T8BvwcGSURXkao3Sh2fbqyBGG5xTM3fqSb gri9WXphNeE+i/CKGFf9IsWnIux20P7+a+KuWRaYuVZVwIjIP5hs+Q/NURADtKrKO7iV uAEgEmGrrvZHxRCyRsA1rFfxnx4/XQ6Y0qbPSTrjB4M97/6rVa6suOZ1K6O/fYoq8jYo NDsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=D5dw13OrhRSzE3FxPT/TcNLSrVzzA73VWO5Cjq6Ef24=; b=E/GWD149Uy4IyjA/H3JCpvzSprQ5gD+pkR7BWlxjTCjTqQwYs51aOrlqPHSCq8Guuz LL+O8JdGjoCInnfrg2s7DIrwbgu1Mog8cbLP58I8TL+2zoSArViT1anVoAPWNNzStfbs lS75ItaDU2vqk9ibiihZ5bJkSGO1EiajtUee21ogVTp5/hacLMM8BY8tA1MOJ0YbWkRn JomLmfmrNdV/Iun1T5+4q6u7gQ6GPLQOMo33jQ6z7g6VNed+zmX3PirJcBVMHm3XNXbo DonZxB8g3WKFx2CcpMazeC5PNLCR5wwWzdif/RyGczedHb60b9awkdrPRr+PwxBMiBrs V5Jw== X-Gm-Message-State: AOAM533knpASwmO7xy3xERHX+Aqp7jeeA1Jb+q/J7F50fpb5+LdqcWPY VSk/qhYRn9nOUX3fZeBK/mQ= X-Google-Smtp-Source: ABdhPJw/j1eATZIJwsHfeVRMlyhvJOF8HcaGR0a/hxAGlg7f6HgsBa8lL56twU2dSumQ8f97SI6ecQ== X-Received: by 2002:a1c:c3d7:: with SMTP id t206mr9351480wmf.23.1623239404518; Wed, 09 Jun 2021 04:50:04 -0700 (PDT) Received: from [192.168.8.171] ([85.255.233.46]) by smtp.gmail.com with ESMTPSA id o5sm13521503wrw.65.2021.06.09.04.50.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Jun 2021 04:50:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.6\)) From: Stewart Bryant In-Reply-To: Date: Wed, 9 Jun 2021 12:50:03 +0100 Cc: Stewart Bryant , "Andrew G. Malis" , mark@townsley.net, "Carlos Pignataro (cpignata)" , Ignacio Goyret , intarea IETF list , Derek Fawcus , pals@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> To: Joel Halpern X-Mailer: Apple Mail (2.3608.120.23.2.6) Archived-At: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 11:50:11 -0000 Which applications still use it Joel? Stewart > On 9 Jun 2021, at 12:42, Joel M. Halpern wrote: >=20 > There is plenty of L2TP still in use. > Yours, > Joel >=20 > 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 > wrote: >>>=20 >>> Bob, >>>=20 >>> 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 :-). >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Cheers, >>> Andy >>>=20 >>>=20 >>> On Sat, Jun 5, 2021 at 10:07 AM Derek Fawcus = > wrote: >>>=20 >>> 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? >>>=20 >>> How many intermediate headers are you considering between L2TP = and >>> where >>> a carried IP header may exist? >>>=20 >>> Maybe I'm getting the wrong end of the stick, but surely this = engages >>> the text from section 5.4 of RFC 2661: >>>=20 >>> "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." >>>=20 >>> 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. >>>=20 >>> So such an L2TP data session may well make use of sequence = numbers to >>> prevent reordering. >>>=20 >>> 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. >>>=20 >>>=20 >>> DF >>>=20 >>> (not an operator) >>>=20 >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>> >>>=20 >>> _______________________________________________ >>> 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 From nobody Wed Jun 9 04:53:52 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F2E3A12B2; Wed, 9 Jun 2021 04:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SSOeFxT5vRs5; Wed, 9 Jun 2021 04:53:37 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F11C3A1281; Wed, 9 Jun 2021 04:53:32 -0700 (PDT) Received: by clarinet.employees.org (Postfix, from userid 1736) id 0B5464E11AF9; Wed, 9 Jun 2021 11:53:30 +0000 (UTC) Date: Wed, 9 Jun 2021 12:53:29 +0100 From: Derek Fawcus To: Bob Briscoe Cc: Stewart Bryant , Alexander Vainshtein , "Andrew G. Malis" , mark@townsley.net, Carlos Pignataro , Ignacio Goyret , intarea IETF list , pals@ietf.org Message-ID: References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Int-area] [EXTERNAL] Re: [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 11:53:47 -0000 On Wed, Jun 09, 2021 at 11:04:04AM +0000, Alexander Vainshtein wrote: > I mainly concur with Stewart's comments about sequence number checking. There is also another potentially extensive 'deployment' of L2TP, especially over the last year, and that is as one of the options in the Microsoft Windows RAS VPN feature. If so, then that would be by relatively unsophisticated users, so they'd not really be able to tune it for issues. This is PPP/L2TP/ESP(transport-mode) occasionally using NAT-T, and negotiated by IKEv1. I don't know if the L2TP layer makes use of sequencing. I'd not be surprised if the ESP layer is using an anti-replay window, in which case the points already rehearsed wrt L4S would apply, but this time with people who won't know how to 'fix' it. We supported use of this in our protocol stack in our product for remote access until quiterecently, and I see there are other vendors who still offer the same mechanism. Specifically I'd imagine to easily interoperate with the RAS feature. DF From nobody Wed Jun 9 05:05:20 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308813A12B1; Wed, 9 Jun 2021 05:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DLFLMpea6ixz; Wed, 9 Jun 2021 05:05:13 -0700 (PDT) Received: from layerfree.net (heronab2.miniserver.com [89.200.138.104]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DDC3A12B0; Wed, 9 Jun 2021 05:05:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)); envelope-from=173.38.220.37; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Giles Heron In-Reply-To: Date: Wed, 9 Jun 2021 13:05:03 +0100 Cc: Derek Fawcus , "Carlos Pignataro (cpignata)" , Ignacio Goyret , intarea IETF list , "Andrew G. Malis" , mark@townsley.net, pals@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-IP-stats: Incoming Last 0, First 5, in=9, out=0, spam=0 ip=HiddenIP Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 12:05:18 -0000 Hi Stewart, IIRC (and it *was* a long time ago), ADSL is BT Wholesale rather than = OpenReach. But at any rate yes, L2TP (v2 rather than v3) does tend to get used for = wholesale ADSL provision (where that still exists). There has been = some move generally to PTA (PPP Termination and Aggregation) into VRFs = but that depends on the wholesale provider=E2=80=99s offering. Re BT specifically (and again my info is outdated and may be = mis-remembered) the 20C network used L2TP, and I think it=E2=80=99s an = option on 21C for handoff to smaller ISPs. Should all be in the SINs = somewhere? Giles > On 9 Jun 2021, at 12:48, Stewart Bryant = wrote: >=20 >=20 >=20 >> On 9 Jun 2021, at 12:19, Derek Fawcus = wrote: >>=20 >> On Wed, Jun 09, 2021 at 11:23:00AM +0100, Stewart Bryant wrote: >>>=20 >>> I doubt that there is much L2TP still out there. It was in its prime = with dialup modems. >>=20 >> Stewart, >>=20 >> Isn't the BT wholesale ADSL product still using it? >>=20 >> Someone recently pointed to their SIN 472, which reference RFC 2661 = not 3931. >> I don't know what other countries are doing for ADSL service, >> and in how many ADSL is a live vs legacy product. >>=20 >> Certainly my ISP describes how one can connect to them using L2TP = mainly because >> they have the backend available for supporting the various = 'broadband' access >> facilities. They also offer ADSL access via another provider, so = maybe they're >> also using L2TP? >>=20 >> So maybe the UK deployment doesn't count a 'much=E2=80=99. >>=20 >> DF >=20 > I suppose the ADSL product may be using it. I thought that it was all = MPLS-PW. >=20 > We need someone from Openreach to tell us what they are doing. >=20 > In any case hopefully the last of the xDSL will soon be confined to = the scrap bin it should have been in years ago as part of the plan to = replace copper with FTTP/5G/LEO. >=20 > - Stewart >=20 >=20 >=20 > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals From nobody Wed Jun 9 06:08:27 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3956B3A15B4; Wed, 9 Jun 2021 06:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FV9T0krGe4id; Wed, 9 Jun 2021 06:08:10 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB4B3A158C; Wed, 9 Jun 2021 06:08:09 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id p7so3856870lfg.4; Wed, 09 Jun 2021 06:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=Uq6FX530+uGOGOostrEosibGpF+PqdnXWeAnSPg1EcY=; b=da5NtT7HLJSc+BgmS+zVA89Gb/I95bVkQxPO+HuzBUSGvKL2h8GH2CzNxLkhejvAXw kNSXIXS+Jihr7gKxOb79hqFWJJO8gnAy5F0b7+BDsSPAAdJnzjiSrx5m7pwi0pkPH8s0 +ovCtfbkvAlPzXOxvn0Esl7L4KK9MxbGWMriB1qBbkb/kijwevbDt7UkEY46ovlMxBfy ZMsPuM408iJwbZi6bK0uPSB0SnHWe9GsRNfyXVpq1hpI9FSQacOUBwtdqO/o5pPc8Uum pLHa6T7hl+SOszQy9cOiEi//KF5vK9t9NRc50WnPNymijMAhh0b84SPt1kOvryVSkgCp 8Dig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=Uq6FX530+uGOGOostrEosibGpF+PqdnXWeAnSPg1EcY=; b=mCZNcsII28JhuiPdmFqJj+0yRy51bqFnQ1I/BZeKjhaxXjxZQaeNS5s8YamlJ3sz27 oV7igH+DAj+4ZevoWjy81Jwujv1Kb/oLu0Bg9Ac/QW5vhYJfdMVVnwPqwe2ht9B9KsKj Lwj425BjZ6w5dqasoSTSEpVV/X/4Oy/BgKf5+q16mlo5kaF/mPur6WdGVX59c8udPLlh 2GPi/HJLnnd7/FiP1vWlErR2DKBVmun5Q4rPIB7AlELtStcgjY91rU3UbKpdo88TTC+6 yCTXbVaH8catL0j4hNEwbOuLe6NdcCGYp0CTX2pV/V3YQ12CyW9euR6TKEDwU0DCPW9l D69Q== X-Gm-Message-State: AOAM531oa8+BrOSTmpNyDuetggyitDSqUyswFFGkWu2ETF/GaGiQQBY+ SCDOgzmbJFDCj9KbWDoSKvyePnxQoDgpVYOLjOjIkxXBVXu1Q0fF X-Google-Smtp-Source: ABdhPJzR/FokOu3qh3aCSCbJ957x9DYWVmMzYzk7OZ+Jw/L2hJEM2E3/pMSmvfRs2vvhxAYHx1iyi+hJcegYm8msOVc= X-Received: by 2002:a05:6512:218e:: with SMTP id b14mr5905356lft.658.1623244087286; Wed, 09 Jun 2021 06:08:07 -0700 (PDT) MIME-Version: 1.0 References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> In-Reply-To: <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> From: James Bensley Date: Wed, 9 Jun 2021 15:07:41 +0200 Message-ID: To: pals@ietf.org, intarea IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 13:08:25 -0000 On Wed, 9 Jun 2021 at 14:05, Giles Heron wrote: > Re BT specifically (and again my info is outdated and may be mis-remember= ed) the 20C network used L2TP, and I think it=E2=80=99s an option on 21C fo= r handoff to smaller ISPs. Should all be in the SINs somewhere? I work in the UK ISP sector. I can confirm that L2TP is in wide spread use for wholesale services by all major ISPs (except Liberty). I think the real question here (unless I've misunderstood) is not "is L2TP being used" but "is L2TP being used AND sequencing is being used and/or enforced?" - is that understanding correct? Chers, James. From nobody Wed Jun 9 06:10:18 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846153A15B5; Wed, 9 Jun 2021 06:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_BLOCKED=0.001, 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 XSLMOuGp45JY; Wed, 9 Jun 2021 06:10:11 -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 847F43A1597; Wed, 9 Jun 2021 06:10:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4G0SBq0zC5z6GBNh; Wed, 9 Jun 2021 06:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1623244211; bh=WoA36yMskWLVsk4yvz8MOGk+0bi4rj5A9V6tC2zPPGg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XQPqosICiFoY1RVGcBM554oeBFzqc1QxGaYQHZhx/8DQggQpvovcFpSl2hf+cLiOm Jxit1Velr8bTGZQ+FrhblF2evv73a7KhwmauVtxqNRzeUoTOlmP13pKZt0aqojK5aO irYx7voMng/wL+BccT8SMSTIZ+7geVkKmfr6B268= X-Quarantine-ID: 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 4G0SBn4thhz6GBBZ; Wed, 9 Jun 2021 06:10:09 -0700 (PDT) To: Stewart Bryant , Joel Halpern Cc: "Andrew G. Malis" , mark@townsley.net, "Carlos Pignataro (cpignata)" , Ignacio Goyret , intarea IETF list , Derek Fawcus , pals@ietf.org References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> From: Joel Halpern Direct Message-ID: <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com> Date: Wed, 9 Jun 2021 09:10:08 -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: <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 13:10:17 -0000 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 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 > 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 > 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 >>>> 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 > From nobody Wed Jun 9 06:57:14 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0419B3A17EB; Wed, 9 Jun 2021 06:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 onQ5Y2W3ylAo; Wed, 9 Jun 2021 06:57:03 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4423A17E7; Wed, 9 Jun 2021 06:57:03 -0700 (PDT) Received: by clarinet.employees.org (Postfix, from userid 1736) id 476F64E11B67; Wed, 9 Jun 2021 13:57:02 +0000 (UTC) Date: Wed, 9 Jun 2021 14:57:02 +0100 From: Derek Fawcus To: James Bensley Cc: pals@ietf.org, intarea IETF list Message-ID: References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 13:57:08 -0000 On Wed, Jun 09, 2021 at 03:07:41PM +0200, James Bensley wrote: > On Wed, 9 Jun 2021 at 14:05, Giles Heron wrote: > > Re BT specifically (and again my info is outdated and may be mis-remembered) the 20C network used L2TP, and I think it’s an option on 21C for handoff to smaller ISPs. Should all be in the SINs somewhere? > > I work in the UK ISP sector. I can confirm that L2TP is in wide spread > use for wholesale services by all major ISPs (except Liberty). I think > the real question here (unless I've misunderstood) is not "is L2TP > being used" but "is L2TP being used AND sequencing is being used > and/or enforced?" - is that understanding correct? Yes. DF From nobody Wed Jun 9 10:41:02 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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 To: Joel Halpern Direct , Stewart Bryant , Joel Halpern CC: "Carlos Pignataro (cpignata)" , Ignacio Goyret , intarea IETF list , Derek Fawcus , "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: References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.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: 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: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 elsewhe= re) 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 On Behalf Of Joel Halpern Direct Sent: Wednesday, June 9, 2021 6:10 AM To: Stewart Bryant ; Joel Halpern Cc: Carlos Pignataro (cpignata) ; Ignacio Goyret ; intarea IETF list ; Derek Fawcus <= dfawcus+lists-int-area@employees.org>; 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 ca= ses. Yours, Joel On 6/9/2021 7:50 AM, Stewart Bryant wrote: > Which applications still use it Joel? >=20 > Stewart >=20 >> On 9 Jun 2021, at 12:42, Joel M. Halpern 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 i= t 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 wi= th 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 in= tended for was actually done with PW over MPLS with some replacement with b= y Mac in Mac for cost reasons. >>> If Carlos does not know the answer, Mark T would be my next port of cal= l. >>> Stewart >>>> On 8 Jun 2021, at 22:41, Andrew G. Malis > 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 i= t :-). >>>> >>>> But I guess that's really not what you were asking about, since you sp= ecifically 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. Mar= k Townsley might know. >>>> >>>> Cheers, >>>> Andy >>>> >>>> >>>> On Sat, Jun 5, 2021 at 10:07 AM Derek Fawcus > 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 wou= ld? >>>> > 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 enga= ges >>>> 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 a= s 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, th= en >>>> 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 a= lso >>>> the fragmentation scheme in RFC 4623 which requires sequence numbe= rs; >>>> and such PWE3 links could ultimately be carrying IP packets. >>>> >>>> >>>> DF >>>> >>>> (not an operator) >>>> >>>> _______________________________________________ >>>> Int-area mailing list >>>> Int-area@ietf.org >>>> https://www.ietf.org/mailman/listinfo/int-area >>>> >>>> >>>> _______________________________________________ >>>> Int-area mailing list >>>> Int-area@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/int-area >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >=20 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Jun 9 15:32:37 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2C33A28DC for ; Wed, 9 Jun 2021 15:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=townsley-net.20150623.gappssmtp.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 PP7jzy2O79fY for ; Wed, 9 Jun 2021 15:32:29 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808563A28D7 for ; Wed, 9 Jun 2021 15:32:29 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id o17-20020a17090a9f91b029015cef5b3c50so2522403pjp.4 for ; Wed, 09 Jun 2021 15:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=townsley-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f9IwzjyLmtOPsl/IiemavzJf3a/DfsNkBUCPb4ggEak=; b=R2Ctwr9DH9+cIT0l59VeDzGf0H/+7PKILUVJj6q/4n9xRP2c7wDovpEnR1X8gO8eJK /DoissM9yLvdobDCNcC+Kdajq5ifn/EjFLfr3696ZlW7BD74epkJrXNeEV+CVohhg58Z sMboc9LxW+yfEaXVqXUsw5aF+qD8cH1z5t/JV2NhHa1l/wICVm8jLHp7RGimfTpTmDpJ bsAGjYjNKZVjzjZXkb1FZVAcIo6G/fL5cw0qa/yZ2wiSglqmEPKLlsirbzZ/Ei2dWlNS GN8N7Rjz8/AV9SBhDbJfbXOtbTlPw3vunBqF/3aIY3biB/p27ur7eykzmOjmW55JCkJf br4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f9IwzjyLmtOPsl/IiemavzJf3a/DfsNkBUCPb4ggEak=; b=eGGJkvn0k/YtCnFHRpzOjekSyPFIGCp5jxIeB1E3Xz1XhRyQ+SI7CbPSYsB/AIyZnd gnBvE2lU87G2AgAzpsKd+AYFXrDUM50Qx6pXsu8UFw5csTYQ+vQqtaLveruN5ZHaQV/P 93WETayVT7as/TdJmM57Mojc+QntUIWAgNcag0ubb+5x0R05qNE3/iNce2/O7DWFsxfY 2pha8H93hmhU4hVD47HLlwZAN20iZ+K0H3EidyE2N4JueOkRxU/ruyta/qHus/kniz7H jHrqL6hUKrzswX+IL3xGHEZJojHR32xH6ZRVQYyJcxL5CC2K0zMxh01odoAUM/Qam2Ft OCig== X-Gm-Message-State: AOAM532Nj+pO2G44DN+TF1iXwtINrFbGZi0E66h/5N/uLhvTW9czCLxK h24cxIcduzv5g1yWWZp/Od0lrg== X-Google-Smtp-Source: ABdhPJzRp6A7xhj5HKU5mtMHB6rB5G/VrxbcZyt0p1y01Dv7ouJYdKWl6rnB0PsA/85I9bk8OxAjOA== X-Received: by 2002:a17:902:ff11:b029:114:37a7:21ad with SMTP id f17-20020a170902ff11b029011437a721admr1690386plj.68.1623277948034; Wed, 09 Jun 2021 15:32:28 -0700 (PDT) Received: from [10.239.163.195] (69-12-170-4.dedicated.static.sonic.net. [69.12.170.4]) by smtp.gmail.com with ESMTPSA id ei23sm5958256pjb.57.2021.06.09.15.32.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Jun 2021 15:32:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Mark Townsley In-Reply-To: <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com> Date: Wed, 9 Jun 2021 15:32:24 -0700 Cc: Joel Halpern , "Andrew G. Malis" , Carlos Pignataro , Ignacio Goyret , intarea IETF list , Derek Fawcus , pals@ietf.org, Joel Halpern Direct Content-Transfer-Encoding: quoted-printable Message-Id: <50ADB293-A7EC-4574-9430-43E68073A6D1@townsley.net> References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 22:32:35 -0000 Hi folks, In addition to the DSL arena, L2TP is still in use with host-based VPN = clients as it is embedded in Apple, Android, and Windows based operating = systems (new and old). Despite most VPN solutions preferring their own = client software that must be installed on hosts to operate, there are = still admins that appreciate not having to ask their employees to = download an app for the VPN to work - in which case PPTP and L2TP with = transport-mode IPsec are your most widely available options.=20 Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. L2TPv3 = generalized L2TP to support other L2 (including MPLS, but I don=E2=80=99t = want to argue what layer MPLS operates within here). There was never a = strong push to replace L2TPv2 used in DSL, Dialup and host VPN software = with L2TPv3 (there was one use case for an important L2TP operator that = wanted to carry PPPoE over L2TPv3 in DSL, but that was overcome by = RFC3817 which achieved the same goal without altering the dataplane). = Ironically, I would expect to see very little PPP over L2TPv3 in the = wild, though obviously it is possible. In the cable broadband world, the DOCSIS DEPI =E2=80=9CRemote PHY=E2=80=9D= specification (similar I suppose to the split BNG spec Joel is = referring to) standardized on L2TPv3 and is in active use. I also know of at least one vendor that uses Ethernet over L2TPv3 for = some wifi backhaul use cases.=20 There could be more, this is just what I am personally aware of off the = top of my head. Even I am surprised to see how much L2TP is still out = there once you start really looking around ;-) Best Regards, - Mark > On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct = wrote: >=20 > 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. >=20 > Yours, > Joel >=20 > 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 = wrote: >>>=20 >>> There is plenty of L2TP still in use. >>> Yours, >>> Joel >>>=20 >>> 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 > wrote: >>>>>=20 >>>>> Bob, >>>>>=20 >>>>> 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 :-). >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Cheers, >>>>> Andy >>>>>=20 >>>>>=20 >>>>> On Sat, Jun 5, 2021 at 10:07 AM Derek Fawcus = > wrote: >>>>>=20 >>>>> 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? >>>>>=20 >>>>> How many intermediate headers are you considering between L2TP = and >>>>> where >>>>> a carried IP header may exist? >>>>>=20 >>>>> Maybe I'm getting the wrong end of the stick, but surely this = engages >>>>> the text from section 5.4 of RFC 2661: >>>>>=20 >>>>> "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." >>>>>=20 >>>>> 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. >>>>>=20 >>>>> So such an L2TP data session may well make use of sequence = numbers to >>>>> prevent reordering. >>>>>=20 >>>>> 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. >>>>>=20 >>>>>=20 >>>>> DF >>>>>=20 >>>>> (not an operator) >>>>>=20 >>>>> _______________________________________________ >>>>> Int-area mailing list >>>>> Int-area@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/int-area >>>>> >>>>>=20 >>>>> _______________________________________________ >>>>> 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 From nobody Thu Jun 10 04:49:49 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814A43A3F50; Thu, 10 Jun 2021 04:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4on8wT7D56Wy; Thu, 10 Jun 2021 04:49:39 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E8F3A3F4D; Thu, 10 Jun 2021 04:49:38 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id u13so14501449qvt.7; Thu, 10 Jun 2021 04:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xNXfcWPqr4Ai1wHPNe7TqF+hAz+XQW3dq16UhXIvnFI=; b=XydSEbOQH3Q5s88AHXrV0S+xsXfsQuE7q/1rgKydTYTNmnOUioXN/iUv4GYBnc6epI hraBlGpXqjcBCMbvedKvjZ1fDdq5wnUYgoGsUjY5+E1GiL3wJRKUpAg7/ldm3UbIFRYh yT/uvcWeGjBh6qQXPIdnrPkMKkB5ezMGGDGvFASEbReBxf8b3wSj15XrVCsZcYkV+G+t YElwIZxyPcT4ZFWWv7m0+KPOCQBX/kQRbCP/lGLJHIYB6Ju9dot28CVq4KLVG+szx2EZ 27wi+7nmjPdkUDP0VD7hr/tiGXBLXdn4oDzen+tfOBorPrwbrd9N5oCK14OzOov+mIQX LUIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xNXfcWPqr4Ai1wHPNe7TqF+hAz+XQW3dq16UhXIvnFI=; b=qeA6UzVWcvBEo6njovjXvg7NCsiSY9BjZgXRwPi54hlDNRZ/iBV815DKnZVkQDljVq DCSknQxyoaonZDYAGHoLMy+RR0aAa++H56SYO7uHJhzgt7sRliX7DjO8OmzmqrvekBeJ v0wyEmeWUfk1N/jR5VvEnWero/wZvizLlXCeZqU7sDLKmP7e90uiGXRaJt525UGkV9FT X5lQoZbNwJTn87wq5pXKSLlHkg4u7razUoGzITm6RvsL84tp07gbq0OaGw6gvll74S4/ IidsHZhVrtha9MTM9G1uQYvfhu1e3FCjIsmz3lBAqvF0cwcv+mge4onpTfLhRsqj90bT mo/A== X-Gm-Message-State: AOAM53394MO7qlfnLfbmKxg3ebflUhhQCUU4f5D2MzH9kVL3DOU9lKfI s/mNhIFKLyEXzQJpOeMrNaZ1sgR6E2dCf/Mf1C07wRSjYr8= X-Google-Smtp-Source: ABdhPJwAf7LcYV2jDubHdsY1Yq+2iMrpDQvW1+j65gaVld765ZcvE7ngDu9JRbJO0p9DJ9KFlE0+3ZX0rKLsMBv6+9c= X-Received: by 2002:a05:6214:80a:: with SMTP id df10mr4632946qvb.8.1623325777156; Thu, 10 Jun 2021 04:49:37 -0700 (PDT) MIME-Version: 1.0 References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com> <50ADB293-A7EC-4574-9430-43E68073A6D1@townsley.net> In-Reply-To: <50ADB293-A7EC-4574-9430-43E68073A6D1@townsley.net> From: "Andrew G. Malis" Date: Thu, 10 Jun 2021 07:49:21 -0400 Message-ID: To: Mark Townsley Cc: Carlos Pignataro , intarea IETF list , pals@ietf.org, Bob Briscoe Content-Type: multipart/alternative; boundary="0000000000004d5e0805c467fcf2" Archived-At: Subject: Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 11:49:44 -0000 --0000000000004d5e0805c467fcf2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (resending with cc: list trimmed to pass the too many recipients filter) Mark, The original question was, how many (if any) of these L2TPv2 and v3 use cases use sequencing, especially when carrying IP? Cheers, Andy On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley wrote: > Hi folks, > > In addition to the DSL arena, L2TP is still in use with host-based VPN > clients as it is embedded in Apple, Android, and Windows based operating > systems (new and old). Despite most VPN solutions preferring their own > client software that must be installed on hosts to operate, there are sti= ll > admins that appreciate not having to ask their employees to download an a= pp > for the VPN to work - in which case PPTP and L2TP with transport-mode IPs= ec > are your most widely available options. > > Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. L2TPv3 > generalized L2TP to support other L2 (including MPLS, but I don=E2=80=99t= want to > argue what layer MPLS operates within here). There was never a strong pus= h > to replace L2TPv2 used in DSL, Dialup and host VPN software with L2TPv3 > (there was one use case for an important L2TP operator that wanted to car= ry > PPPoE over L2TPv3 in DSL, but that was overcome by RFC3817 which achieved > the same goal without altering the dataplane). Ironically, I would expect > to see very little PPP over L2TPv3 in the wild, though obviously it is > possible. > > In the cable broadband world, the DOCSIS DEPI =E2=80=9CRemote PHY=E2=80= =9D specification > (similar I suppose to the split BNG spec Joel is referring to) standardiz= ed > on L2TPv3 and is in active use. > > I also know of at least one vendor that uses Ethernet over L2TPv3 for som= e > wifi backhaul use cases. > > There could be more, this is just what I am personally aware of off the > top of my head. Even I am surprised to see how much L2TP is still out the= re > once you start really looking around ;-) > > Best Regards, > > - Mark > > > > > > On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct < > jmh.direct@joelhalpern.com> wrote: > > > > 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 versio= n > of) protocol for control of split BNG. L2TP is commonly used for these u= se > 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 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 becaus= e > 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 oppos= ed > 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 replacemen= t > 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>> 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 activ= e > use. Mark Townsley might know. > >>>>> > >>>>> Cheers, > >>>>> Andy > >>>>> > >>>>> > >>>>> On Sat, Jun 5, 2021 at 10:07 AM Derek Fawcus < > dfawcus+lists-int-area@employees.org 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, bu= t > 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 tr= y > >>>>> to keep > >>>>> > IP data packets in sequence? > >>>>> > >>>>> How many intermediate headers are you considering between L2TP a= nd > >>>>> 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 an= d > 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 t= he > >>>>> 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 > >>>>> 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 > > --0000000000004d5e0805c467fcf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(resending with cc: list trimmed to pass the too many reci= pients filter)
Mark,
The original question was, how many (if any) of these L2T= Pv2 and v3 use cases use sequencing, especially when carrying IP?

Cheers,
Andy
<= /div>

On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley <mark@townsley.net> wrote:
Hi folks,

In addition to the DSL arena, L2TP is still in use with host-based VPN clie= nts as it is embedded in Apple, Android, and Windows based operating system= s (new and old). Despite most VPN solutions preferring their own client sof= tware that must be installed on hosts to operate, there are still admins th= at appreciate not having to ask their employees to download an app for the = VPN to work - in which case PPTP and L2TP with transport-mode IPsec are you= r most widely available options.

Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. L2TPv3 gen= eralized L2TP to support other L2 (including MPLS, but I don=E2=80=99t want= to argue what layer MPLS operates within here). There was never a strong p= ush to replace L2TPv2 used in DSL, Dialup and host VPN software with L2TPv3= (there was one use case for an important L2TP operator that wanted to carr= y PPPoE over L2TPv3 in DSL, but that was overcome by RFC3817 which achieved= the same goal without altering the dataplane). Ironically, I would expect = to see very little PPP over L2TPv3 in the wild, though obviously it is poss= ible.

In the cable broadband world, the DOCSIS DEPI =E2=80=9CRemote PHY=E2=80=9D = specification (similar I suppose to the split BNG spec Joel is referring to= ) standardized on L2TPv3 and is in active use.

I also know of at least one vendor that uses Ethernet over L2TPv3 for some = wifi backhaul use cases.

There could be more, this is just what I am personally aware of off the top= of my head. Even I am surprised to see how much L2TP is still out there on= ce you start really looking around ;-)

Best Regards,

- Mark




> On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct <jmh.direct@joelhalpern.com> wrote:
>
> BNGs are still a big busienss.=C2=A0 And BNG resale /emote control use= s L2TP in many cases.=C2=A0 The BBF has been working on (and published a fi= rst version of) protocol for control of split BNG.=C2=A0 L2TP is commonly u= sed 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:<= br> >>>
>>> 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 prob= lem because it is stateful so I doubt that many high-scale or high-speed fo= rwarders ever did this.
>>>> I think there is an undisclosed assumption that go up enou= gh 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 beca= me 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 repla= cement with by Mac in Mac for cost reasons.
>>>> If Carlos does not know the answer, Mark T would be my nex= t port of call.
>>>> Stewart
>>>>> On 8 Jun 2021, at 22:41, Andrew G. Malis <agmalis@gmail.com <m= ailto:agmalis@gmail.= com>> wrote:
>>>>>
>>>>> Bob,
>>>>>
>>>>> In addition to the cases listed by Derek, L2TPv3 can a= lso carry non-IP pseudowire data, such as Ethernet frames (see RFC 4719 for= example). Even though 4719 says that sequencing is optional, I would certa= inly 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 yo= u 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 wat= er 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 <dfaw= cus+lists-int-area@employees.org <mailto:dfawcus%2Blists-int-area= @employees.org>> wrote:
>>>>>
>>>>>=C2=A0 =C2=A0 On Fri, Jun 04, 2021 at 03:13:15PM +0100,= Bob Briscoe wrote:
>>>>>=C2=A0 =C2=A0 > The L2TP RFC says sequencing /can/ b= e disabled for IP data, but it
>>>>>=C2=A0 =C2=A0 > doesn't say SHOULD or MUST. Is i= t possible that some operators
>>>>>=C2=A0 =C2=A0 enable
>>>>>=C2=A0 =C2=A0 > L2TP sequencing for IP data? And if = so, do you know why they would?
>>>>>=C2=A0 =C2=A0 > Also, are you aware of any other typ= es of tunnel that might try
>>>>>=C2=A0 =C2=A0 to keep
>>>>>=C2=A0 =C2=A0 > IP data packets in sequence?
>>>>>
>>>>>=C2=A0 =C2=A0 How many intermediate headers are you con= sidering between L2TP and
>>>>>=C2=A0 =C2=A0 where
>>>>>=C2=A0 =C2=A0 a carried IP header may exist?
>>>>>
>>>>>=C2=A0 =C2=A0 Maybe I'm getting the wrong end of th= e stick, but surely this engages
>>>>>=C2=A0 =C2=A0 the text from section 5.4 of RFC 2661: >>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 "For example, if the PPP sess= ion being tunneled is not
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0utilizing any stateful compr= ession or encryption protocols and is
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0only carrying IP (as determi= ned by the PPP NCPs that are
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0established), then the LNS m= ight decide to disable sequencing as IP
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0is tolerant to datagram loss= and reordering."
>>>>>
>>>>>=C2=A0 =C2=A0 This would then suggest if L2TP is carryi= ng PPP, the PPP session
>>>>>=C2=A0 =C2=A0 is not
>>>>>=C2=A0 =C2=A0 multi-link, and is making use of compress= ion (including one of the
>>>>>=C2=A0 =C2=A0 versions of IP header compression) in som= e form for IP packets, then
>>>>>=C2=A0 =C2=A0 reordering will impact the ability to dec= ompress.
>>>>>
>>>>>=C2=A0 =C2=A0 So such an L2TP data session may well mak= e use of sequence numbers to
>>>>>=C2=A0 =C2=A0 prevent reordering.
>>>>>
>>>>>=C2=A0 =C2=A0 I guess similarly in L2TPv3 when the PW i= s for PPP, and possibly also
>>>>>=C2=A0 =C2=A0 the fragmentation scheme in RFC 4623 whic= h requires sequence numbers;
>>>>>=C2=A0 =C2=A0 and such PWE3 links could ultimately be c= arrying IP packets.
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 DF
>>>>>
>>>>>=C2=A0 =C2=A0 (not an operator)
>>>>>
>>>>>=C2=A0 =C2=A0 _________________________________________= ______
>>>>>=C2=A0 =C2=A0 Int-area mailing list
>>>>>=C2=A0 =C2=A0 Int-area@ietf.org <mailto:Int-area@ietf.org>
>>>>>=C2=A0 =C2=A0 https://www.ietf.org= /mailman/listinfo/int-area
>>>>>=C2=A0 =C2=A0 <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/list= info/int-area
>>>> _______________________________________________
>>>> Int-area mailing list
>>>> Int= -area@ietf.org
>>>> https://www.ietf.org/mailman/listinfo= /int-area

--0000000000004d5e0805c467fcf2-- From nobody Thu Jun 10 05:09:50 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0073A3FDA; Thu, 10 Jun 2021 05:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Zj-cX6pVosGW; Thu, 10 Jun 2021 05:09:39 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23DF3A3FD7; Thu, 10 Jun 2021 05:09:38 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id m21so2831933lfg.13; Thu, 10 Jun 2021 05:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=zFTDnPx6eOF3cgm9t0f8uClRFRA5RGvQbfxeNQr6Vsc=; b=l24/T0NTxgzRe1GUs7rVrVp57gXO6tG4W0D3CQ8N4F66/ZJRO2hKEmfVappJTfUPuA ifipv1GeU6sRC3AOvkLnwzyGwJs+xIhgopNgqjExfoZJ73Z18PR21kRYDqM/vcZZTX6Z aXqmd7FWvv17pQjEi/3EhvKmMSt6JRgGnC0yJv//MMHwvY7KLw2ar7xktHWpfghe9Rj5 fLE/+R+8t8uAAWXd9GGkudsTAmIuVTEAbGxN3bGEO0xqstSEQBA0dhuycHZzcNZLKjF3 08rR7nZGxD00FSpMuW3SZ/ZwqI1AwNYu8BkKo4iOv7UXQC7BgstnJbZPm62xjAYlrXnf j4Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=zFTDnPx6eOF3cgm9t0f8uClRFRA5RGvQbfxeNQr6Vsc=; b=TZZMsJ7PqQ/KTe9X47WA7q+wUTgZh7cl0MZeyDA6g0KaqzPZ2EAyVCo3OgX/nn35rX vsIp9vfnh+CWAd8zT+gomkL5+979oAitcd5qf7/On6x/59C9yU8OwaycsehYmJi15P6+ re02r2H/Ft4kqI3bjVugEJ3x3UonQv5vEbU2bjOU7BfNLRlMK12gt8+gx/JQujXIdbs6 IIFe9YFSwbQgl6KCXuaEE74FbCKonScRU3nHQZJZgObzvPv4dLMEUSFcolXM9s782OlN fuw3dJmCPDET5gAdHrpXGaNRdTb05AmYrmbbiq0gsZdq+9vB/Lvop/2P9XQzzVdI0fwY L/3A== X-Gm-Message-State: AOAM5317jfV/SCpW/EvcvMxwpJucqv7Mf05b5Ro0Of0/EACOesM1S5sj 7ZmWmKAL5APWaXzBBpAjd3Il2oCbywuX6+cN4ZKb+3Y9 X-Google-Smtp-Source: ABdhPJw3xCrYneBwSRlT0/xraCZCC/jK5J5xUy7sNWGsPRCqvUovCkwSKHs5PLeFRlV9BLPj2UC1jZSVPHG2TByv8FQ= X-Received: by 2002:a19:e00f:: with SMTP id x15mr1697691lfg.222.1623326976408; Thu, 10 Jun 2021 05:09:36 -0700 (PDT) MIME-Version: 1.0 References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> In-Reply-To: From: James Bensley Date: Thu, 10 Jun 2021 14:09:10 +0200 Message-ID: To: intarea IETF list , pals@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 12:09:45 -0000 On Wed, 9 Jun 2021 at 15:57, Derek Fawcus wrote: > > On Wed, Jun 09, 2021 at 03:07:41PM +0200, James Bensley wrote: > > On Wed, 9 Jun 2021 at 14:05, Giles Heron wrote: > > > Re BT specifically (and again my info is outdated and may be mis-reme= mbered) the 20C network used L2TP, and I think it=E2=80=99s an option on 21= C for handoff to smaller ISPs. Should all be in the SINs somewhere? > > > > I work in the UK ISP sector. I can confirm that L2TP is in wide spread > > use for wholesale services by all major ISPs (except Liberty). I think > > the real question here (unless I've misunderstood) is not "is L2TP > > being used" but "is L2TP being used AND sequencing is being used > > and/or enforced?" - is that understanding correct? > > Yes. In that case - sequencing isn't used for BT Wholesale services. Cheers, James. From nobody Thu Jun 10 05:23:07 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4171A3A109A; Thu, 10 Jun 2021 05:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 sDxHmHvWT0_J; Thu, 10 Jun 2021 05:23:00 -0700 (PDT) Received: from layerfree.net (heronab2.miniserver.com [89.200.138.104]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3201E3A08EA; Thu, 10 Jun 2021 05:22:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)); envelope-from=173.38.220.37; From: Giles Heron Message-Id: <4AC24C92-DD6C-4D5E-B113-0123DFD842A5@layerfree.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_06AB71E2-8E1E-4020-B18A-BB553B55D15E" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 10 Jun 2021 13:22:54 +0100 In-Reply-To: Cc: Mark Townsley , Carlos Pignataro , Bob Briscoe , intarea IETF list , pals@ietf.org To: "Andrew G. Malis" References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com> <50ADB293-A7EC-4574-9430-43E68073A6D1@townsley.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-IP-stats: Incoming Last 1, First 6, in=11, out=0, spam=0 ip=HiddenIP Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 12:23:05 -0000 --Apple-Mail=_06AB71E2-8E1E-4020-B18A-BB553B55D15E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So AFAIK SP networks don=E2=80=99t generally reorder packets in the = steady state, but of course reordering can occur under rerouting. As noted by Derek I=E2=80=99m guessing reordering is an issue for L2TPv2 = if stateful PPP compression schemes are in play (which I suspect is = unlikely to be the case given we usually have abundant bandwidth in the = aggregation network, and given that compression can occur at other = layers). Though given that BNGs inherently keep state per subscriber = maybe the NPU scaling issues that Stewart mentioned are less of an issue = in that use case than for MPLS PEs doing PWE? =46rom a quick look at the DOCSIS rPHY specs it seems they do require = support for L2TPv3 sequence numbers. Of course in that case the payload = is the DOCSIS MAC rather than IP (even though, of course, most DOCSIS = frames ultimately carry an IP payload). Giles > On 10 Jun 2021, at 12:49, Andrew G. Malis wrote: >=20 > (resending with cc: list trimmed to pass the too many recipients = filter) > Mark, >=20 > The original question was, how many (if any) of these L2TPv2 and v3 = use cases use sequencing, especially when carrying IP? >=20 > Cheers, > Andy >=20 > On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley > wrote: > Hi folks, >=20 > In addition to the DSL arena, L2TP is still in use with host-based VPN = clients as it is embedded in Apple, Android, and Windows based operating = systems (new and old). Despite most VPN solutions preferring their own = client software that must be installed on hosts to operate, there are = still admins that appreciate not having to ask their employees to = download an app for the VPN to work - in which case PPTP and L2TP with = transport-mode IPsec are your most widely available options.=20 >=20 > Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. = L2TPv3 generalized L2TP to support other L2 (including MPLS, but I = don=E2=80=99t want to argue what layer MPLS operates within here). There = was never a strong push to replace L2TPv2 used in DSL, Dialup and host = VPN software with L2TPv3 (there was one use case for an important L2TP = operator that wanted to carry PPPoE over L2TPv3 in DSL, but that was = overcome by RFC3817 which achieved the same goal without altering the = dataplane). Ironically, I would expect to see very little PPP over = L2TPv3 in the wild, though obviously it is possible. >=20 > In the cable broadband world, the DOCSIS DEPI =E2=80=9CRemote PHY=E2=80=9D= specification (similar I suppose to the split BNG spec Joel is = referring to) standardized on L2TPv3 and is in active use. >=20 > I also know of at least one vendor that uses Ethernet over L2TPv3 for = some wifi backhaul use cases.=20 >=20 > There could be more, this is just what I am personally aware of off = the top of my head. Even I am surprised to see how much L2TP is still = out there once you start really looking around ;-) >=20 > Best Regards, >=20 > - Mark >=20 >=20 >=20 >=20 > > On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct = > wrote: > >=20 > > 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. > >=20 > > Yours, > > Joel > >=20 > > 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 > wrote: > >>>=20 > >>> There is plenty of L2TP still in use. > >>> Yours, > >>> Joel > >>>=20 > >>> 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 >> wrote: > >>>>>=20 > >>>>> Bob, > >>>>>=20 > >>>>> 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 :-). > >>>>>=20 > >>>>> 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. > >>>>>=20 > >>>>> 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. > >>>>>=20 > >>>>> Cheers, > >>>>> Andy > >>>>>=20 > >>>>>=20 > >>>>> On Sat, Jun 5, 2021 at 10:07 AM Derek Fawcus = = >> wrote: > >>>>>=20 > >>>>> 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? > >>>>>=20 > >>>>> How many intermediate headers are you considering between = L2TP and > >>>>> where > >>>>> a carried IP header may exist? > >>>>>=20 > >>>>> Maybe I'm getting the wrong end of the stick, but surely this = engages > >>>>> the text from section 5.4 of RFC 2661: > >>>>>=20 > >>>>> "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." > >>>>>=20 > >>>>> 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. > >>>>>=20 > >>>>> So such an L2TP data session may well make use of sequence = numbers to > >>>>> prevent reordering. > >>>>>=20 > >>>>> 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. > >>>>>=20 > >>>>>=20 > >>>>> DF > >>>>>=20 > >>>>> (not an operator) > >>>>>=20 > >>>>> _______________________________________________ > >>>>> Int-area mailing list > >>>>> Int-area@ietf.org = > > >>>>> https://www.ietf.org/mailman/listinfo/int-area = > >>>>> > > >>>>>=20 > >>>>> _______________________________________________ > >>>>> 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 = >=20 > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals --Apple-Mail=_06AB71E2-8E1E-4020-B18A-BB553B55D15E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
So AFAIK SP networks don=E2=80=99t generally reorder packets = in the steady state, but of course reordering can occur under = rerouting.

As = noted by Derek I=E2=80=99m guessing reordering is an issue for L2TPv2 if = stateful PPP compression schemes are in play (which I suspect is = unlikely to be the case given we usually have abundant bandwidth in the = aggregation network, and given that compression can occur at other = layers).  Though given that BNGs inherently keep state per = subscriber maybe the NPU scaling issues that Stewart mentioned are less = of an issue in that use case than for MPLS PEs doing PWE?

=46rom a quick look at = the DOCSIS rPHY specs it seems they do require support for L2TPv3 = sequence numbers.  Of course in that case the payload is the DOCSIS = MAC rather than IP (even though, of course, most DOCSIS frames = ultimately carry an IP payload).

Giles

On 10 = Jun 2021, at 12:49, Andrew G. Malis <agmalis@gmail.com> = wrote:

(resending with cc: list trimmed to pass the too = many recipients filter)
Mark,

The original question = was, how many (if any) of these L2TPv2 and v3 use cases use sequencing, = especially when carrying IP?

Cheers,
Andy

On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley <mark@townsley.net> = wrote:
Hi folks,

In addition to the DSL arena, L2TP is still in use with host-based VPN = clients as it is embedded in Apple, Android, and Windows based operating = systems (new and old). Despite most VPN solutions preferring their own = client software that must be installed on hosts to operate, there are = still admins that appreciate not having to ask their employees to = download an app for the VPN to work - in which case PPTP and L2TP with = transport-mode IPsec are your most widely available options.

Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. L2TPv3 = generalized L2TP to support other L2 (including MPLS, but I don=E2=80=99t = want to argue what layer MPLS operates within here). There was never a = strong push to replace L2TPv2 used in DSL, Dialup and host VPN software = with L2TPv3 (there was one use case for an important L2TP operator that = wanted to carry PPPoE over L2TPv3 in DSL, but that was overcome by = RFC3817 which achieved the same goal without altering the dataplane). = Ironically, I would expect to see very little PPP over L2TPv3 in the = wild, though obviously it is possible.

In the cable broadband world, the DOCSIS DEPI =E2=80=9CRemote PHY=E2=80=9D= specification (similar I suppose to the split BNG spec Joel is = referring to) standardized on L2TPv3 and is in active use.

I also know of at least one vendor that uses Ethernet over L2TPv3 for = some wifi backhaul use cases.

There could be more, this is just what I am personally aware of off the = top of my head. Even I am surprised to see how much L2TP is still out = there once you start really looking around ;-)

Best Regards,

- Mark




> On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct <jmh.direct@joelhalpern.com> wrote:
>
> 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

_______________________________________________
Pals = mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals

= --Apple-Mail=_06AB71E2-8E1E-4020-B18A-BB553B55D15E-- From nobody Tue Jun 15 04:48:57 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D5D3A2C90 for ; Tue, 15 Jun 2021 04:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wF19C8XnEWm7 for ; Tue, 15 Jun 2021 04:48:51 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52693A2C99 for ; Tue, 15 Jun 2021 04:48:47 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id j15so9624814vsf.2 for ; Tue, 15 Jun 2021 04:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:to:from:subject:date:message-id; bh=Jy9CC1BQ0KQY/lfcX0qGpQYDSkfR/EzeL1fcflOSvP4=; b=gUFISZFY63PlxGBZqcmkaKzYsGm5Aq2+rQA8BTmZDQU2OA5ioLhrJczghIbCrbfN+e 6PI6oseyvUv04+KKMC6XwZuKfcDLJ1hvhAnBXtijIWcCHcTos7Y2bETSNuLSFYxVeGkr VX5qGdxnNPAwWFjKcnC+Mq5y5AWV6jZzZZmGTqwv+yhnKX5KVkN8h2IGkWVpAuHQj3WW 2ZHYDeJqYw4KHgtFERb5Tpz2/STh9gaNmtA3aYagkN22okh5fxhqBGZG3KYp3T51UbPE VjIUjl/7kjRTATdp9vqdzESik3pvMlHDcRcalW/2A64WjadhKm2luIgqiYcWZ94lm0vn NXhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:to:from:subject:date:message-id; bh=Jy9CC1BQ0KQY/lfcX0qGpQYDSkfR/EzeL1fcflOSvP4=; b=cVh/OYf6QKEul1Nwrsy2rOyDKT7ZvOc/WCCLBY4rTrPMRP+Ydc20KCvr8nbAnGikzc PoHCK+vKYPDnHOPbLEzJUAQO416Pv1kKFFZQHTpS6vMR4gVwa1lUQaCqgVESqkjk8wXA rsbSCtDo+afRc8mI3c2KKpvYbYVR91S08WA/7RxVIfbKrWLxMPGV1AeEA6x2QAIeGOhu wGFDlzn3Meg9bcOtK8+ZNDRMIhxRmw0AFiGxMEmr0Qc7P0QAVGUX4/lpQib9F2Jsjb/P ucdlJ5HChhuEw2WGOAzhl5Kx49N5Gbl0LHTpGwWc2KlD3xMGjxuPUHFWY9t9+r1niSkz /Vfw== X-Gm-Message-State: AOAM533Q7X/0fH0Uz187xY5fAPd8LnjL3J6BvT+sRgY+QgfrA1ng3FQo 2M716re+17mrQKB0WNPXNKB+EcbtQdgMYA== X-Google-Smtp-Source: ABdhPJwwgyRhWsGJtsdCjuwGlwX4UadxSGKyT2xzOc0tteLkmiNX2q64dmZDLAV8bhoLSAhkuw/RoA== X-Received: by 2002:a67:f745:: with SMTP id w5mr4102131vso.11.1623757724545; Tue, 15 Jun 2021 04:48:44 -0700 (PDT) Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with UTF8SMTPSA id f18sm2015133vkp.3.2021.06.15.04.48.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jun 2021 04:48:43 -0700 (PDT) Mime-Version: 1.0 To: Int-area@ietf.org X-Superhuman-Draft-ID: draft0054517c928a5d0f From: "Yiannis Yiakoumis" Date: Tue, 15 Jun 2021 11:48:41 +0000 Message-ID: X-Mailer: Superhuman Desktop (2021-06-11T23:26:37Z) X-Superhuman-ID: kpxzer60.04aee80a-1a75-4bad-bc3a-1df8a45000d7 X-Superhuman-Thread-ID: draft006e0d747eaadfc8 Content-Type: multipart/alternative; boundary=af8e54e3f82bd98580fc2b9a36038b145dead99e7bc2f168d1341654676e Archived-At: Subject: [Int-area] Comments on "per-app networking considerations" draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 11:48:56 -0000 --af8e54e3f82bd98580fc2b9a36038b145dead99e7bc2f168d1341654676e Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Late on the game, but wanted to share some thoughts on Tommy's and Lorenzo'= s draft on per-app networking ( https://datatracker.ietf.org/doc/html/draft= -per-app-networking-considerations ). First of all, having a dedicated document that discusses per-app network co= nsiderations and the implications with privacy and neutrality is great help= , as we can focus such discussion here and separate it from technical mecha= nisms that try to offer solutions in these areas. A category abstraction is definitely interesting and has its merits. With r= egards to privacy, it reduces the information revealed to the network (subj= ect to generic enough categories). With regards to neutrality, it addresses= - up to a certain extent - concerns around user choice and competition (i.= e., if all gaming apps experience similar network behavior, there is not mu= ch competitive advantage to be earned). With regards to implementation, if = we assume there is a centralized authority for categorization, there is pot= ential to simplify provisioning of such services across different administr= ative domains (especially for E2E services like latency SLAs which would be= nefit from a multi-domain enforcement). And with regards to incentives, it'= s necessary for services where a pay-per-use=C2=A0model doesn't work well (= e.g., zero-rating). The big challenge with category-based differentiation is definition and enf= orcement of categorization. There is significant experience from Europe's z= ero-rating implementation, where regulators approved category-based zero-ra= ting, and more than 30 network operators implemented it (based on DPI). In = my experience, a decentralized approach (where each operator defines catego= ries themselves, and enforces them through a heavyweight implementation pro= cess like DPI) doesn't work well, especially for smaller apps that don't ha= ve the resources to work with operators, and end-up being in a bigger disad= vantage when their large competitors participate in such programs.=C2=A0=C2= =A0As a reference point, we've seen 10% success rate and 8-months average i= ntegration time for an eligible music streaming company to participate in E= urope's music zero-rating programs, when the most popular apps were availab= le in most of them from the very beginning (more details on this here). A good step forward would be to define a metric around time/cost to partici= pate, and what advances would help reduce this.=C2=A0Tommy/Lorenzo --- what= are your thoughts on category definitions? Have you seen any other=C2=A0pa= radigm we could follow/re-use in terms of category definitions and eligibil= ity?=C2=A0Could Apple/Play stores playing a role in such an effort? I think the document would benefit from explicitly mentioning incentives of= different stakeholders, and what mitigation mechanisms exist to align ince= ntives with protections of privacy and neutrality. For example, a gaming ze= ro-rating category incentivizes operators to ensure that only "gaming traff= ic" would go through there, otherwise there is an incentive for users/apps = to mark their traffic as gaming to get a free ride. In contrast, in a low-l= atency category operators can use a pay-per-use pricing structure, and ther= efore not care much about what traffic goes over it. In that direction, another approach to mitigate neutrality and privacy cons= iderations (especially for pay-per-use types of services like QoS) is a use= r-based approach. The only thing that needs to be communicated is the desir= e of a user to forward a packet through a certain path. In that sense it ca= n be application-agnostic, and therefore address all concerns around both p= rivacy and net neutrality. I see that the document has expired. Is there interest to continue the effo= rt in follow-up meetings? Best, Yiannis Yiannis . --af8e54e3f82bd98580fc2b9a36038b145dead99e7bc2f168d1341654676e Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
Late on the game, but wa= nted to share some thoughts on Tommy's and Lorenzo's draft on per-a= pp networking (=C2=A0https://datatracker.ietf.org/doc/html/d= raft-per-app-networking-considerations=C2=A0).

First of all, having a dedicated document that= discusses per-app network considerations and the implications with privacy= and neutrality is great help, as we can focus such discussion here and sep= arate it from technical mechanisms that try to offer solutions in these are= as.=C2=A0

A category abstraction is definitely interesting and has its merits. = With regards to privacy, it reduces the information revealed to the network= (subject to generic enough categories). With regards to neutrality, it add= resses - up to a certain extent - concerns around user choice and competiti= on (i.e., if all gaming apps experience similar network behavior, there is = not much competitive advantage to be earned). With regards to implementatio= n, if we assume there is a centralized authority for categorization, there = is potential to simplify provisioning of such services across different adm= inistrative domains (especially for E2E services like latency SLAs which wo= uld benefit from a multi-domain enforcement). And with regards to incentive= s, it's necessary for services where a pay-per-use=C2=A0model doesn'= ;t work well (e.g., zero-rating).=C2=A0

The big challenge with category-based differentiation is = definition and enforcement of categorization. There is significant experien= ce from Europe's zero-rating implementation, where regulators approved = category-based zero-rating, and more than 30 network operators implemented = it (based on DPI). In my experience, a decentralized approach (where each o= perator defines categories themselves, and enforces them through a heavywei= ght implementation process like DPI) doesn't work well, especially for = smaller apps that don't have the resources to work with operators, and = end-up being in a bigger disadvantage when their large competitors particip= ate in such programs.=C2=A0=C2=A0As a reference point, we've seen 10% s= uccess rate and 8-months average integration time for an eligible music str= eaming company to participate in Europe's music zero-rating programs, w= hen the most popular apps were available in most of them from the very begi= nning (more details on this here).

A good step forward would be to define a metric around time/co= st to participate, and what advances would help reduce this.=C2=A0Tommy/Lor= enzo --- what are your thoughts on category definitions? Have you seen any = other=C2=A0paradigm we could follow/re-use in terms of category definitions= and eligibility?=C2=A0Could Apple/Play stores playing a role in such an ef= fort?=C2=A0

I th= ink the document would benefit from explicitly mentioning incentives of dif= ferent stakeholders, and what mitigation mechanisms exist to align incentiv= es with protections of privacy and neutrality. For example, a gaming zero-r= ating category incentivizes operators to ensure that only "gaming traff= ic" would go through there, otherwise there is an incentive for users/a= pps to mark their traffic as gaming to get a free ride. In contrast, in a l= ow-latency category operators can use a pay-per-use pricing structure, and = therefore not care much about what traffic goes over it.=C2=A0

In that direction,= another approach to mitigate neutrality and privacy considerations (especi= ally for pay-per-use types of services like QoS) is a user-based approach. = The only thing that needs to be communicated is the desire of a user to for= ward a packet through a certain path. In that sense it can be application-a= gnostic, and therefore address all concerns around both privacy and net neu= trality.=C2=A0

I see t= hat the document has expired. Is there interest to continue the effort in f= ollow-up meetings?

Bes= t,
Yiannis=C2=A0

=
3D"

Yiannis .

<= /div>
--af8e54e3f82bd98580fc2b9a36038b145dead99e7bc2f168d1341654676e-- From nobody Tue Jun 15 05:30:14 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD34A3A2DED for ; Tue, 15 Jun 2021 05:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9VeSsWQi-7_m for ; Tue, 15 Jun 2021 05:30:08 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C42B3A2DEC for ; Tue, 15 Jun 2021 05:30:08 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id b9so20231602ybg.10 for ; Tue, 15 Jun 2021 05:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FPhSyZZhGomWs3vLA+Lau3nGabI1ZvEdLil4rqRHwPM=; b=bOI9Otbhtdyn4/7KkuyLOX91wqd2iXm7I5Qlxrn2pLpyuj2Kg60xGWbAS/5O6qdI3i aoPe2PO79T6ei+rABzfO5hpuDJFwE88FTwr/WB2Vhb7GA45pQn/jj+ozKkF0hefeSzkp 0JYfensB6JR2gOkw5PBwrnbkwykOP5Sh4YUVLGFRdfwjfKBkd/PLm9FRxAd5dmSySpeS 1ubfQBVNeI4/6P2W+7+CUnr1Hat9nF5jY63CuydaAwTtSCVVIYV118xQOJoxu8P/Sv/S zBCDq9iUy5wzMHzek1v7ptVtkW+LDNPQshJQ80bl8rHYr8xOQrmjQfvi7ImaO4VUvLvA GWTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FPhSyZZhGomWs3vLA+Lau3nGabI1ZvEdLil4rqRHwPM=; b=UoDQADzqC1PqW6Ibg2o51otFwMtOLnaE8XI6nJZ9jQfPsxR8SyXnh1adlEimUf4Uw9 kZzC9VAyFP7Gp/EWUmfrzMCVoD2M0j43hmyzKUlZ7F5ZQkGRI7LqO54loH+wgSetl8gI s94gw5qgknnKpx1umPQnnB9wHmlY4ExHBDvOuK4lB877/2SHOdky85HYwoWU0dt91Sfb Q9b1DAoqRlbHL144Vkd8AM1bk/ZVW1zKMniYh0gr+IIKD2NRTJ5lDN1OfD0CSjs+N1a8 qImJkXMO/DICWruvwaRRH4nPc2kXXMq0HTfQ2OAz01s+gVCIB1A2Y2164K0bSHM1ffwr er6A== X-Gm-Message-State: AOAM533gU5dnZLeg551R3aBDcKibvhZI7ot0nNOvgBTj7odLFqiWNe0x SH75FGMX7l/pasAQ1RJopyLAcLdUUSiqZanEGRQSpd4pyegcLg== X-Google-Smtp-Source: ABdhPJxgCYcsidxtkqLBpuiIVdi9pu4oRbK2O8z9ZL8SylJi8Knn8M6bd8aAT8Lh8H8KWN2fhBEG/FrlpdWM4omtrqQ= X-Received: by 2002:a25:f446:: with SMTP id p6mr31915485ybe.288.1623760206709; Tue, 15 Jun 2021 05:30:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 15 Jun 2021 07:29:40 -0500 Message-ID: To: Yiannis Yiakoumis Cc: int-area Content-Type: multipart/alternative; boundary="0000000000005249f605c4cd2248" Archived-At: Subject: Re: [Int-area] Comments on "per-app networking considerations" draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 12:30:13 -0000 --0000000000005249f605c4cd2248 Content-Type: text/plain; charset="UTF-8" For what it's worth, On Tue, Jun 15, 2021 at 6:49 AM Yiannis Yiakoumis wrote: > Late on the game, but wanted to share some thoughts on Tommy's and > Lorenzo's draft on per-app networking ( > https://datatracker.ietf.org/doc/html/draft-per-app-networking-considerations > ). > > First of all, having a dedicated document that discusses per-app network > considerations and the implications with privacy and neutrality is great > help, as we can focus such discussion here and separate it from technical > mechanisms that try to offer solutions in these areas. > > A category abstraction is definitely interesting and has its merits. With > regards to privacy, it reduces the information revealed to the network > (subject to generic enough categories). With regards to neutrality, it > addresses - up to a certain extent - concerns around user choice and > competition (i.e., if all gaming apps experience similar network behavior, > there is not much competitive advantage to be earned). With regards to > implementation, if we assume there is a centralized authority for > categorization, there is potential to simplify provisioning of such > services across different administrative domains (especially for E2E > services like latency SLAs which would benefit from a multi-domain > enforcement). And with regards to incentives, it's necessary for services > where a pay-per-use model doesn't work well (e.g., zero-rating). > > The big challenge with category-based differentiation is definition and > enforcement of categorization. There is significant experience from > Europe's zero-rating implementation, where regulators approved > category-based zero-rating, and more than 30 network operators implemented > it (based on DPI). In my experience, a decentralized approach (where each > operator defines categories themselves, and enforces them through a > heavyweight implementation process like DPI) doesn't work well, especially > for smaller apps that don't have the resources to work with operators, and > end-up being in a bigger disadvantage when their large competitors > participate in such programs. As a reference point, we've seen 10% success > rate and 8-months average integration time for an eligible music streaming > company to participate in Europe's music zero-rating programs, when the > most popular apps were available in most of them from the very beginning > (more details on this here). > > A good step forward would be to define a metric around time/cost to > participate, and what advances would help reduce this. Tommy/Lorenzo --- > what are your thoughts on category definitions? Have you seen any > other paradigm we could follow/re-use in terms of category definitions and > eligibility? Could Apple/Play stores playing a role in such an effort? > > I think the document would benefit from explicitly mentioning incentives > of different stakeholders, and what mitigation mechanisms exist to align > incentives with protections of privacy and neutrality. For example, a > gaming zero-rating category incentivizes operators to ensure that only > "gaming traffic" would go through there, otherwise there is an incentive > for users/apps to mark their traffic as gaming to get a free ride. In > contrast, in a low-latency category operators can use a pay-per-use pricing > structure, and therefore not care much about what traffic goes over it. > > In that direction, another approach to mitigate neutrality and privacy > considerations (especially for pay-per-use types of services like QoS) is a > user-based approach. The only thing that needs to be communicated is the > desire of a user to forward a packet through a certain path. In that sense > it can be application-agnostic, and therefore address all concerns around > both privacy and net neutrality. > > I see that the document has expired. Is there interest to continue the > effort in follow-up meetings? > I hope so, very much. Tommy said, during the meeting, "Tommy: 3 different legs: one belongs to IAB for the overall architecture, one is still research in solution space, that's trust between those nodes; and here: what are we doing today? tools we have, ways we think are bad to use those tools". That was in response to a question I asked, so Tommy thought there are definitely topics from the presentation that are in scope for the IETF. I said (in Jabber, but it's in the minutes at https://datatracker.ietf.org/meeting/110/materials/minutes-110-intarea-01) that "this would make a smashing topic for an INTAREA interim meeting before IETF 111,* if the charter allows it.*", but I don't know if anyone ever said that the charter allowed it. Is INTAREA the place we should be talking about this? If not, where? Best, Spencer > Best, > Yiannis > > > Yiannis . > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > --0000000000005249f605c4cd2248 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For what it's worth,=C2=A0

<= div class=3D"gmail_quote">
On Tue, Jun= 15, 2021 at 6:49 AM Yiannis Yiakoumis <gyiakoumis@gmail.com> wrote:
Late on the game, but wante= d to share some thoughts on Tommy's and Lorenzo's draft on per-app = networking (=C2=A0https://datatracker.ietf= .org/doc/html/draft-per-app-networking-considerations=C2=A0).
=

First of all, having a dedicated document that discusse= s per-app network considerations and the implications with privacy and neut= rality is great help, as we can focus such discussion here and separate it = from technical mechanisms that try to offer solutions in these areas.=C2=A0=

A category abstraction is definitely int= eresting and has its merits. With regards to privacy, it reduces the inform= ation revealed to the network (subject to generic enough categories). With = regards to neutrality, it addresses - up to a certain extent - concerns aro= und user choice and competition (i.e., if all gaming apps experience simila= r network behavior, there is not much competitive advantage to be earned). = With regards to implementation, if we assume there is a centralized authori= ty for categorization, there is potential to simplify provisioning of such = services across different administrative domains (especially for E2E servic= es like latency SLAs which would benefit from a multi-domain enforcement). = And with regards to incentives, it's necessary for services where a pay= -per-use=C2=A0model doesn't work well (e.g., zero-rating).=C2=A0

The big challenge with category-based differentiatio= n is definition and enforcement of categorization. There is significant exp= erience from Europe's zero-rating implementation, where regulators appr= oved category-based zero-rating, and more than 30 network operators impleme= nted it (based on DPI). In my experience, a decentralized approach (where e= ach operator defines categories themselves, and enforces them through a hea= vyweight implementation process like DPI) doesn't work well, especially= for smaller apps that don't have the resources to work with operators,= and end-up being in a bigger disadvantage when their large competitors par= ticipate in such programs.=C2=A0=C2=A0As a reference point, we've seen = 10% success rate and 8-months average integration time for an eligible musi= c streaming company to participate in Europe's music zero-rating progra= ms, when the most popular apps were available in most of them from the very= beginning (more details on this here).

A good= step forward would be to define a metric around time/cost to participate, = and what advances would help reduce this.=C2=A0Tommy/Lorenzo --- what are y= our thoughts on category definitions? Have you seen any other=C2=A0paradigm= we could follow/re-use in terms of category definitions and eligibility?= =C2=A0Could Apple/Play stores playing a role in such an effort?=C2=A0

I think the document would benefit from expli= citly mentioning incentives of different stakeholders, and what mitigation = mechanisms exist to align incentives with protections of privacy and neutra= lity. For example, a gaming zero-rating category incentivizes operators to = ensure that only "gaming traffic" would go through there, otherwi= se there is an incentive for users/apps to mark their traffic as gaming to = get a free ride. In contrast, in a low-latency category operators can use a= pay-per-use pricing structure, and therefore not care much about what traf= fic goes over it.=C2=A0

In that direction= , another approach to mitigate neutrality and privacy considerations (espec= ially for pay-per-use types of services like QoS) is a user-based approach.= The only thing that needs to be communicated is the desire of a user to fo= rward a packet through a certain path. In that sense it can be application-= agnostic, and therefore address all concerns around both privacy and net ne= utrality.=C2=A0

I see that the document has ex= pired. Is there interest to continue the effort in follow-up meetings?
<= /div>

I hope so, ve= ry much.=C2=A0

Tommy said, during the meeting, &qu= ot;Tommy: 3 different= legs: one belongs to IAB for the overall architecture, one is still resear= ch in solution space, that's trust between those nodes; and here: what = are we doing today? tools we have, ways we think are bad to use those tools= ". That was in response to a question I asked, so Tommy thought there = are definitely topics from the presentation that are in scope for the IETF.=

I said (in Jabber, but it'= s in the minutes at=C2=A0https://datatracker.ietf.org/meeting/11= 0/materials/minutes-110-intarea-01) that "this would make a smashi= ng topic for an INTAREA interim meeting before IETF 111, if the charter = allows it.", but I don't know if anyone ever said that the cha= rter allowed it.=C2=A0

Is INTAREA the place we= should be talking about this? If not, where?

Best= ,

Spencer
=C2=A0
Best,<= br>
Yiannis=C2=A0

3D""

Yiannis .

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
--0000000000005249f605c4cd2248-- From nobody Tue Jun 15 07:46:50 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645723A32B2 for ; Tue, 15 Jun 2021 07:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 mhgZhC7P2Oj9 for ; Tue, 15 Jun 2021 07:46:46 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395673A32AC for ; Tue, 15 Jun 2021 07:46:46 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id l9so14299472wms.1 for ; Tue, 15 Jun 2021 07:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=czaEg0ehKiajRz0XSSYQJPJUMEIhTD2e1kZQepXj+K4=; b=SWsrJ9u5yIJ/QIOe3qexZO8FHmqX4Gp8ov6ZhL6BwkB1/ePJupVZAtX17lH1xyBIfL 9GyUT+Fs8mnWhY7uepiExSUlGQ6DNZZ67M7lgacOd+U0mvWwT8UbaZPqXyZQBrfmwx9x 304smZR4PFljEQwSN64Cl27QEeUUuG9G6fu7+OrIXpwHg+csT6fvIy60r8BHOOE1n+7A q9bx1hU1Dkj1DOHEoxgkDjQ7zHZWTkVTOh7Ej6RYsenLMjgddicChS/YrxpnaLx3Fx/P JMhsTZVzNLs/j/u4Sf/yBcqiinWN7jKgUOkGO/uq88NAGUEPKNN3uKYBzZ8mJnasvKz3 E0KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=czaEg0ehKiajRz0XSSYQJPJUMEIhTD2e1kZQepXj+K4=; b=QH+1A46fp8IAKTrvntmqBRAqlcsRyMJ/Wpv29Yd29EiwWLBc9tZv/Kps0VMB6DgOLz PNTDM5cFZLufseZxIVmzrGKeJi9yoDM5x4ABRcydRkQBcLRIEA+xC7OV4W1D1OHb0v9D k4RcMEqPHAH3zY/Sx/wQ3wNulps5AZKuzRH1YNE5eQWgZ2erc0BAPVoVO6GgBxVAyOYk 8PTzMSmDp6O7jX+xFcPNdKUB5e8ZW/aIAv8AH4sYxf+KizsPjJG/kYPBu0/o4kJC0USo 3jWTMVb557dSAI9uFi38tciYwahHof2m0tqpx6K+Tj7l7ljZDt1aG6osqIRxEh6Q/AHT 9VBw== X-Gm-Message-State: AOAM531wYLuAaVYXZ2axS16SWFXD7EgAITD8YNAqDIqTSMOYOKqidoJ1 t5mnhueWlOsA6kEs+LBVs5QMMe3J2DzUmuAKUtRvn8LP0Pazgquu X-Google-Smtp-Source: ABdhPJxUem60EJWjx0oElc0mIQ5FT1O3qOkDR2pRJ+Eospi7jU0AXBztDmuBkw6btYqAns64y+B/l7K9LSZJ31U7HH0= X-Received: by 2002:a1c:7f96:: with SMTP id a144mr4562835wmd.22.1623768403385; Tue, 15 Jun 2021 07:46:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lorenzo Colitti Date: Tue, 15 Jun 2021 23:46:31 +0900 Message-ID: To: Yiannis Yiakoumis Cc: Int-area@ietf.org Content-Type: multipart/alternative; boundary="000000000000e276c005c4cf0a21" Archived-At: Subject: Re: [Int-area] Comments on "per-app networking considerations" draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 14:46:49 -0000 --000000000000e276c005c4cf0a21 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 15, 2021 at 8:49 PM Yiannis Yiakoumis wrote: > The big challenge with category-based differentiation is definition and > enforcement of categorization. There is significant experience from > Europe's zero-rating implementation, where regulators approved > category-based zero-rating, and more than 30 network operators implemented > it (based on DPI). In my experience, a decentralized approach (where each > operator defines categories themselves, and enforces them through a > heavyweight implementation process like DPI) doesn't work well, especially > for smaller apps that don't have the resources to work with operators, and > end-up being in a bigger disadvantage when their large competitors > participate in such programs. As a reference point, we've seen 10% success > rate and 8-months average integration time for an eligible music streaming > company to participate in Europe's music zero-rating programs, when the > most popular apps were available in most of them from the very beginning > (more details on this here). > That's a good point. I think it would definitely be useful to note in the draft that categories can sometimes be difficult to define, coordinate, and enforce. A good step forward would be to define a metric around time/cost to > participate, and what advances would help reduce this. Tommy/Lorenzo --- > what are your thoughts on category definitions? Have you seen any > other paradigm we could follow/re-use in terms of category definitions and > eligibility? Could Apple/Play stores playing a role in such an effort? > I think categories/manual review/abuse reporting in app stores could play a role here, as could on-device analysis of app behaviour and traffic patterns. That said - the intent of this draft is not to stray too far into solution space; the primary intent is to call attention to the implications of per-app networking, and I think that's valuable in itself. The idea is that while designing solutions may be a lot more work, at least having a document that says, "here are the implications" will help provide food for thought for folks considering implementing these practices. I think the document would benefit from explicitly mentioning incentives of > different stakeholders, and what mitigation mechanisms exist to align > incentives with protections of privacy and neutrality. For example, a > gaming zero-rating category incentivizes operators to ensure that only > "gaming traffic" would go through there, otherwise there is an incentive > for users/apps to mark their traffic as gaming to get a free ride. In > contrast, in a low-latency category operators can use a pay-per-use pricing > structure, and therefore not care much about what traffic goes over it. > It's true that if apps can simply announce themselves to be whatever category they believe is going to give them better treatment, then they have an incentive to do so. We might want to put some text into the draft about this, and noting that possible ways to make this work would be using trusted/neutral third parties, or with existing business relationships (roughly equivalent, if you will, to a finer-grained way of doing QoS signalling). I think it might be difficult to word that text in a way that is technical enough and concrete enough for an IETF draft though; there's a risk that it would be either too vague or too specific. Think you could suggest something? In that direction, another approach to mitigate neutrality and privacy > considerations (especially for pay-per-use types of services like QoS) is a > user-based approach. The only thing that needs to be communicated is the > desire of a user to forward a packet through a certain path. In that sense > it can be application-agnostic, and therefore address all concerns around > both privacy and net neutrality. > Are you envisaging that the user would make these selections manually? That seems very difficult to explain to users. Perhaps I don't understand? > I see that the document has expired. Is there interest to continue the > effort in follow-up meetings? > We definitely want to continue to update the document and seek adoption if there is interest in the WG. --000000000000e276c005c4cf0a21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 15, 2021 at 8:49 PM Yiannis Yiakoumis <gyiakoumis@gmail.com> wrote:
The = big challenge with category-based differentiation is definition and enforce= ment of categorization. There is significant experience from Europe's z= ero-rating implementation, where regulators approved category-based zero-ra= ting, and more than 30 network operators implemented it (based on DPI). In = my experience, a decentralized approach (where each operator defines catego= ries themselves, and enforces them through a heavyweight implementation pro= cess like DPI) doesn't work well, especially for smaller apps that don&= #39;t have the resources to work with operators, and end-up being in a bigg= er disadvantage when their large competitors participate in such programs.= =C2=A0=C2=A0As a reference point, we've seen 10% success rate and 8-mon= ths average integration time for an eligible music streaming company to par= ticipate in Europe's music zero-rating programs, when the most popular = apps were available in most of them from the very beginning (more details o= n this here).

=
That's a good point. I think it would definitely be useful to note= in the draft that categories can sometimes be difficult to define, coordin= ate, and enforce.

A good step forward would be to defin= e a metric around time/cost to participate, and what advances would help re= duce this.=C2=A0Tommy/Lorenzo --- what are your thoughts on category defini= tions? Have you seen any other=C2=A0paradigm we could follow/re-use in term= s of category definitions and eligibility?=C2=A0Could Apple/Play stores pla= ying a role in such an effort?=C2=A0

I think categories/manual review/abuse reportin= g in app stores could play a role here, as could on-device analysis of app = behaviour and traffic patterns. That said - the intent of this draft is not= to stray too far into solution space; the primary intent is to call attent= ion to the implications of per-app networking, and I think that's valua= ble in itself. The idea is that while designing solutions may be a lot more= work, at least having a document that says, "here are the implication= s" will help provide food for thought for folks considering implementi= ng these practices.

I think the do= cument would benefit from explicitly mentioning incentives of different sta= keholders, and what mitigation mechanisms exist to align incentives with pr= otections of privacy and neutrality. For example, a gaming zero-rating cate= gory incentivizes operators to ensure that only "gaming traffic" = would go through there, otherwise there is an incentive for users/apps to m= ark their traffic as gaming to get a free ride. In contrast, in a low-laten= cy category operators can use a pay-per-use pricing structure, and therefor= e not care much about what traffic goes over it.=C2=A0

It's true that if apps can simp= ly announce themselves to be whatever category they believe is going to giv= e them better treatment, then they have an incentive to do so. We might wan= t to put some text into the draft about this, and noting that possible ways= to make this work would be using trusted/neutral third parties, or with ex= isting business relationships (roughly equivalent, if you will, to a finer-= grained way of doing QoS signalling). I think it might be difficult to word= that text in a way that is technical enough and concrete enough for an IET= F draft though; there's a risk that it would be either too vague or too= specific. Think you could suggest something?

In that direction, another approach to mitigate neutrality and privac= y considerations (especially for pay-per-use types of services like QoS) is= a user-based approach. The only thing that needs to be communicated is the= desire of a user to forward a packet through a certain path. In that sense= it can be application-agnostic, and therefore address all concerns around = both privacy and net neutrality.
=

Are you envisaging that the user would make these selec= tions manually? That seems very difficult to explain to users. Perhaps I do= n't understand?
=C2=A0
I see that the document has e= xpired. Is there interest to continue the effort in follow-up meetings?
=

We definitel= y want to continue to update the document and seek adoption if there is int= erest in the WG.
--000000000000e276c005c4cf0a21-- From nobody Thu Jun 17 02:30:16 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4C13A156D for ; Thu, 17 Jun 2021 02:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 At0u7nZhFywa for ; Thu, 17 Jun 2021 02:30:10 -0700 (PDT) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857F53A156A for ; Thu, 17 Jun 2021 02:30:10 -0700 (PDT) Received: by mail-vk1-xa31.google.com with SMTP id c17so1240928vke.3 for ; Thu, 17 Jun 2021 02:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:message-id:from:date:subject:to:cc :in-reply-to; bh=qamgVG6xX1OY+G1BoeIVzAmhOSYanmtjFeHofEI3o4c=; b=AI/RJMRg5wieq2KaJA+phPbqDLXSdo5kfa1TZMgYIC/Mmi8Epk2RRA9iUbqxpHhY2l HkXvxb/wEvfNgzrHqCrO6t4npuOhWNUNEW0LH0x7hkEUVwtfqNZ9zAjk5f8+i41lM+v2 R221QGO7wJ1nHcNwWIEOVFWPgd6Ro4i1cg7ugqVn+tfquAXQvApovUrRY98JARY3ojaW R04SCGn43q8B9IkLponfZQeJKCJxjvOmbdDVOMj64bfib9REcLYOCeriJlhduhJ/QeX3 Ouj2RWGUZxx6eZhbs577Gbeq4oPUGuwmmpXXwSuVnvBafTSAJI+D2AWoNea/piYY/Ns6 ezOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:message-id:from:date :subject:to:cc:in-reply-to; bh=qamgVG6xX1OY+G1BoeIVzAmhOSYanmtjFeHofEI3o4c=; b=RVoIzZ10AmYbq3Lu0TwMV4Er7M3VU6iKbYfZBdkElumjdZmBjl4vh0LC74zC5oNwlZ EiyzsvyGNd8/AeqFkrPQRhYD0quEvImlJdFzATJkkOIQ3bJoG9LNCsRGxitA4UYspl17 iFp5gvJdHDOvXhbh93bsnp12xyGNE941ZhJAPahq4yOPwku6Jk8rgBnzXeNmTRo2PNQa d9YqsFplOcj9/P1yBKH6G9Wu0dCmoUI0aX4w0pqE73MtBlc03SaTGWEFO8tSF6rGVt7z HqRWZLk7Ub++aBbD0RYyUax3IjePQyr4frUnmR/Yj6gzZyf84ZoUGRhCwTGUzpv/L9nQ 17UA== X-Gm-Message-State: AOAM533BBUmm/ptNqlkThAiyBtcEImHeJjueupI1YLbNanzeYwlWei+7 iaZpFdi7Yh4bioMkSJZaTRO3SdtAifw7bA== X-Google-Smtp-Source: ABdhPJy/e/qN8YDqGK0Ah+c8v117A0iWAxU6cT+faUVHedejHpYWp6igxn+fapM+t+Bo6T3F5Zkeag== X-Received: by 2002:a05:6122:a09:: with SMTP id 9mr3202434vkn.10.1623922208407; Thu, 17 Jun 2021 02:30:08 -0700 (PDT) Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with UTF8SMTPSA id o25sm714957vkb.43.2021.06.17.02.30.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Jun 2021 02:30:08 -0700 (PDT) Mime-Version: 1.0 X-Superhuman-ID: kq0pc7rw.de722ae1-7e0c-4c53-8830-92a4f32d90ac X-Superhuman-Draft-ID: draft00177e047fc1c0cd References: Message-ID: X-Mailer: Superhuman Desktop (2021-06-16T22:06:04Z) From: "Yiannis Yiakoumis" Date: Thu, 17 Jun 2021 09:30:06 +0000 To: "Lorenzo Colitti" Cc: Int-area@ietf.org In-Reply-To: Content-Type: multipart/alternative; boundary=661fd43b19121c992a033d0dfda58e4fa2cf56effce6084f62cec76204e8 Archived-At: Subject: Re: [Int-area] Comments on "per-app networking considerations" draft X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 09:30:16 -0000 --661fd43b19121c992a033d0dfda58e4fa2cf56effce6084f62cec76204e8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On Tue, Jun 15, 2021 at 7:46 AM, Lorenzo Colitti < lorenzo@google.com > wro= te: >=20 > On Tue, Jun 15, 2021 at 8:49 PM Yiannis Yiakoumis < gyiakoumis@ gmail. co= m > ( gyiakoumis@gmail.com ) > wrote: >=20 >=20 >> The big challenge with category-based differentiation is definition and >> enforcement of categorization. There is significant experience from >> Europe's zero-rating implementation, where regulators approved >> category-based zero-rating, and more than 30 network operators implement= ed >> it (based on DPI). In my experience, a decentralized approach (where eac= h >> operator defines categories themselves, and enforces them through a >> heavyweight implementation process like DPI) doesn't work well, especial= ly >> for smaller apps that don't have the resources to work with operators, a= nd >> end-up being in a bigger disadvantage when their large competitors >> participate in such programs.=C2=A0=C2=A0As a reference point, we've see= n 10% >> success rate and 8-months average integration time for an eligible music >> streaming company to participate in Europe's music zero-rating programs, >> when the most popular apps were available in most of them from the very >> beginning (more details on this here). >>=20 >>=20 >=20 >=20 >=20 > That's a good point. I think it would definitely be useful to note in the > draft that categories can sometimes be difficult to define, coordinate, > and enforce. >=20 >=20 >=20 >=20 >> A good step forward would be to define a metric around time/cost to >> participate, and what advances would help reduce this.=C2=A0Tommy/Lorenz= o --- >> what are your thoughts on category definitions? Have you seen any other >> paradigm we could follow/re-use in terms of category definitions and >> eligibility?=C2=A0Could Apple/Play stores playing a role in such an effo= rt? >>=20 >>=20 >=20 >=20 >=20 > I think categories/manual review/abuse reporting in app stores could play > a role here, as could on-device analysis of app behaviour and traffic > patterns. That said - the intent of this draft is not to stray too far > into solution space; the primary intent is to call attention to the > implications of per-app networking, and I think that's valuable in itself= . > The idea is that while designing solutions may be a lot more work, at > least having a document that says, "here are the implications" will help > provide food for thought for folks considering implementing these > practices. >=20 >=20 >=20 >=20 Agreed that this document shouldn't go into solution space. This doesn't pr= event us from having some high-level metrics/goals that would have directly= impact the projected implications, and help evaluate whether a solution is= good or not down the road. >=20 >=20 >>=20 >>=20 >> I think the document would benefit from explicitly mentioning incentives >> of different stakeholders, and what mitigation mechanisms exist to align >> incentives with protections of privacy and neutrality. For example, a >> gaming zero-rating category incentivizes operators to ensure that only >> "gaming traffic" would go through there, otherwise there is an incentive >> for users/apps to mark their traffic as gaming to get a free ride. In >> contrast, in a low-latency category operators can use a pay-per-use >> pricing structure, and therefore not care much about what traffic goes >> over it. >>=20 >>=20 >=20 >=20 >=20 > It's true that if apps can simply announce themselves to be whatever > category they believe is going to give them better treatment, then they > have an incentive to do so. We might want to put some text into the draft > about this, and noting that possible ways to make this work would be usin= g > trusted/neutral third parties, or with existing business relationships > (roughly equivalent, if you will, to a finer-grained way of doing QoS > signalling). I think it might be difficult to word that text in a way tha= t > is technical enough and concrete enough for an IETF draft though; there's > a risk that it would be either too vague or too specific. Think you could > suggest something? >=20 >=20 >=20 >=20 It feels that this is too important (and with strong ramifications on the o= verall architecture) to ignore. If categories require strong definition (i.= e, they dictate if an application is eligible to participate), then a neutr= al authority can be essential to protect both privacy and neutrality. This = is not necessary If categories are loose (i.e., they define network charact= eristics but any application could participate subject to cost/caps etc). I= could attempt to add some text on the draft if it is of interest. >=20 >=20 >>=20 >>=20 >> In that direction, another approach to mitigate neutrality and privacy >> considerations (especially for pay-per-use types of services like QoS) i= s >> a user-based approach. The only thing that needs to be communicated is t= he >> desire of a user to forward a packet through a certain path. In that sen= se >> it can be application-agnostic, and therefore address all concerns aroun= d >> both privacy and net neutrality. >>=20 >>=20 >=20 >=20 >=20 > Are you envisaging that the user would make these selections manually? > That seems very difficult to explain to users. Perhaps I don't understand= ? >=20 >=20 >=20 >=20 >=20 Yes, I think there are ways to get the user involved on the selection proce= ss. User experience is a UI/UX problem which there are ways to solve. One w= ay to structure this is as a low-latency permission in your phone OS (simil= ar to location, camera, etc); a developer can ask for this permission and a= user can simply approve/deny/revoke. It is straight forward for the users = and familiar as a workflow. A few of us have been thinking along these line= s and we do have early implementations that do this. >=20 >=20 >> I see that the document has expired. Is there interest to continue the >> effort in follow-up meetings? >>=20 >>=20 >=20 >=20 >=20 > We definitely want to continue to update the document and seek adoption i= f > there is interest in the WG. >=20 >=20 Great to hear and looking forward to the discussion! Yiannia --661fd43b19121c992a033d0dfda58e4fa2cf56effce6084f62cec76204e8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On Tue, Jun 15, 2021 at 7:4= 6 AM, Lorenzo Colitti <lorenzo@google.com> wrote= :
On Tue, Jun 15, 2= 021 at 8:49 PM Yiannis Yiakoumis <gyiakoumis@gmail.com> wrote:
The big challenge with category-based differentiation is definit= ion and enforcement of categorization. There is significant experience from= Europe's zero-rating implementation, where regulators approved categor= y-based zero-rating, and more than 30 network operators implemented it (bas= ed on DPI). In my experience, a decentralized approach (where each operator= defines categories themselves, and enforces them through a heavyweight imp= lementation process like DPI) doesn't work well, especially for smaller= apps that don't have the resources to work with operators, and end-up = being in a bigger disadvantage when their large competitors participate in = such programs.=C2=A0=C2=A0As a reference point, we've seen 10% success = rate and 8-months average integration time for an eligible music streaming = company to participate in Europe's music zero-rating programs, when the= most popular apps were available in most of them from the very beginning (= more details on this here).
=

That's a good point. I think= it would definitely be useful to note in the draft that categories can som= etimes be difficult to define, coordinate, and enforce.

A = good step forward would be to define a metric around time/cost to participa= te, and what advances would help reduce this.=C2=A0Tommy/Lorenzo --- what a= re your thoughts on category definitions? Have you seen any other=C2=A0para= digm we could follow/re-use in terms of category definitions and eligibilit= y?=C2=A0Could Apple/Play stores playing a role in such an effort?=C2=A0

I think categories/manual review/abuse reporting in app stores = could play a role here, as could on-device analysis of app behaviour and tr= affic patterns. That said - the intent of this draft is not to stray too fa= r into solution space; the primary intent is to call attention to the impli= cations of per-app networking, and I think that's valuable in itself. T= he idea is that while designing solutions may be a lot more work, at least = having a document that says, "here are the implications" will help = provide food for thought for folks considering implementing these practices= .


Agreed that this document shouldn't go int= o solution space. This doesn't prevent us from having some high-level m= etrics/goals that would have directly impact the projected implications, an= d help evaluate whether a solution is good or not down the road.=C2=A0


I think t= he document would benefit from explicitly mentioning incentives of differen= t stakeholders, and what mitigation mechanisms exist to align incentives wi= th protections of privacy and neutrality. For example, a gaming zero-rating= category incentivizes operators to ensure that only "gaming traffic= 4; would go through there, otherwise there is an incentive for users/apps t= o mark their traffic as gaming to get a free ride. In contrast, in a low-la= tency category operators can use a pay-per-use pricing structure, and there= fore not care much about what traffic goes over it.=C2=A0
<= /div>

It's= true that if apps can simply announce themselves to be whatever category t= hey believe is going to give them better treatment, then they have an incen= tive to do so. We might want to put some text into the draft about this, an= d noting that possible ways to make this work would be using trusted/neutra= l third parties, or with existing business relationships (roughly equivalen= t, if you will, to a finer-grained way of doing QoS signalling). I think it= might be difficult to word that text in a way that is technical enough and= concrete enough for an IETF draft though; there's a risk that it would= be either too vague or too specific. Think you could suggest something?

<= div>

It feels that this is too important (and with stro= ng ramifications on the overall architecture) to ignore. If categories requ= ire strong definition (i.e, they dictate if an application is eligible to p= articipate), then a neutral authority can be essential to protect both priv= acy and neutrality. This is not necessary If categories are loose (i.e., th= ey define network characteristics but any application could participate sub= ject to cost/caps etc). I could attempt to add some text on the draft if it= is of interest.=C2=A0


In that direction, another approach to mitigate neutrality= and privacy considerations (especially for pay-per-use types of services l= ike QoS) is a user-based approach. The only thing that needs to be communic= ated is the desire of a user to forward a packet through a certain path. In= that sense it can be application-agnostic, and therefore address all conce= rns around both privacy and net neutrality.

Are you envisagi= ng that the user would make these selections manually? That seems very diff= icult to explain to users. Perhaps I don't understand?
=C2=A0

Yes, I think there are ways to get t= he user involved on the selection process. User experience is a UI/UX probl= em which there are ways to solve. One way to structure this is as a low-lat= ency permission in your phone OS (similar to location, camera, etc); a deve= loper can ask for this permission and a user can simply approve/deny/revoke= . It is straight forward for the users and familiar as a workflow. A few of= us have been thinking along these lines and we do have early implementatio= ns that do this.

I see that the d= ocument has expired. Is there interest to continue the effort in follow-up = meetings?
We definitely want to continue to update the docum= ent and seek adoption if there is interest in the WG.

Great to hear and looking forward to the discussion!

=
Yiannia



3D"
--661fd43b19121c992a033d0dfda58e4fa2cf56effce6084f62cec76204e8-- From nobody Tue Jun 22 09:15:35 2021 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 567C83A0B15; Tue, 22 Jun 2021 09:15:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: evyncke@cisco.com, int-area@ietf.org, intarea-chairs@ietf.org, lflynn@amsl.com X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162437853333.17325.1344648668247642943@ietfa.amsl.com> Date: Tue, 22 Jun 2021 09:15:33 -0700 Archived-At: Subject: [Int-area] intarea - Update to a Meeting Session Request for IETF 111 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 16:15:33 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the intarea working group. --------------------------------------------------------- Working Group Name: Internet Area Working Group Area Name: Internet Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: Chair Conflict: lpwan 6tisch 6lo dhc t2trg dmm dprive Technology Overlap: dnsop 6man v6ops saag tsvwg People who must be present: Eric Vyncke Wassim Haddad Juan Carlos Zuniga Erik Kline Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 25 06:49:24 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0ED3A191E for ; Fri, 25 Jun 2021 06:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=interdigital.com header.b=bXHt+H6f; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=interdigital.onmicrosoft.com header.b=JKvxabdR 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 qBwerKKFd7Nr for ; Fri, 25 Jun 2021 06:49:16 -0700 (PDT) Received: from esa2.hc3352-98.iphmx.com (esa2.hc3352-98.iphmx.com [216.71.148.90]) (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 8C27E3A191B for ; Fri, 25 Jun 2021 06:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=interdigital.com; i=@interdigital.com; q=dns/txt; s=esa; t=1624628956; x=1656164956; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QE3hRfNMz68DsgRlDbCVh2iZpS+OIFefknDJiHUwFA4=; b=bXHt+H6fdAveMhv1xUOI5gIKxDo8kO/Na5BmzUeuznVNHLy2pLv5kNmF RhahSjz3aw8rDquTa06FFL4enpzt1Nz1gW/AWmIDOLlb2ibVKBQrC5L5H NsoW2u7Wm4ISI3YTbq1ZzWHAPhOx6ngxrsDmC3z31BtIglnoDFgZkesO7 MruaQISUwSXzNLGdog9C00oHC6e1D1e2CiIKjyD89ISYIMInrB6gq9dbd g+5I1vOwQIKEIrHN5NpG5SjgnO2bhZOmA0aHezw2AT7FTkqM0708+2FAU ae7HMiOO4IhCYOmemriZod3EdFyKgP6sZpHKU6KXNcODQIJHDvGdBshR+ A==; IronPort-SDR: 45UpxlgQ8SsJ4jWUaj3UGGpKajTVCKCCPryJ9i6hlH5v2mTVmAQ6vGQr5iOQkdP9sjIQHqzJDd yBfEAcYaAleipXXbatRE3BFzL24OSUHmAWyETGF0HyvnxbWf7yGP9VhrRwszu2MrlXqTecKsRv N3Kj+wlR3cPROYnJRNQ/OpFtxhRblr8Oebq25P8O/gvsoFV58Qom/P1yYPjgdG2el3+nJtS/5d Rv221N98XXwaKt91q+TYb2PMiA8WqOMhfKQiy1q9hLVwjZshw81ijxx2QQXTQ1quRr9TGVVlhB S7k= Received: from mail-mw2nam10lp2106.outbound.protection.outlook.com (HELO NAM10-MW2-obe.outbound.protection.outlook.com) ([104.47.55.106]) by ob1.hc3352-98.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2021 09:49:15 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SquZ2BK49kwc8h/Q37PZ+wq0HEVJyOgC1I6mzxDQeXbT7abg235FDmqtMCslCFOAfdOnZNvQ29Xi5hnGA1kAg0y+P9FjVV6tugW3XKglU+fyLKtbtc7q9ZyMyWGpSyDxtZL0T3fTJDnDcTApANuDN9OfBZYi3iUttYfuas2XICBdTMDtY+Js1GQiMUUVEKMCy51ihQWIZXcrNTvEzkFyWw2TE53OrJ5mL441xM6AVjk3+7QK1rb5PX0/K2wN+iTX0Rg+BYWqzg0nnvCm5gJDOMBbp9ysiZhM2IX4BUQ4OiZm5Q4GQeVzuFB5a8fqCme3OdF0P68gv9MVt/GVoqyDRA== 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=GzwHLFGj4Vv0zRSINC+XNcUYQ8xOMI8QfzP/Y4P5qLY=; b=AwDQEogjhKFkPcpM3IpcSdRLzjZ5atwr3xfYkDrD6DeKB/lRa4l+I4rJER5Mk5bJ1u0lnb20u6GPvPw895+WZjYiELav3amd11E/Wh6Qa+DmmX/kIOrkMhq8yN8cav9qlOV6PZZdJk3AhfD097ZYjqNMGgIZCUeNPLC1UZ2NI7FfbAju9FnZMZhv/A/ACvJ1Eo05LH+1z3/+n/qOTqIcDlVOInTH/AbUNct3LRFTEmgZoB4CqkU5VVvRSD95YhptRZwLgezlVEp2td36FIGlg0LIcF9f2NqOfVYtuYdU8PURBBcYLZ8+1el9/XVKjNLEPYhytipvs54b1zt9v9CpCA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=interdigital.com; dmarc=pass action=none header.from=interdigital.com; dkim=pass header.d=interdigital.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interdigital.onmicrosoft.com; s=selector2-interdigital-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GzwHLFGj4Vv0zRSINC+XNcUYQ8xOMI8QfzP/Y4P5qLY=; b=JKvxabdRqy5txyzRakG1V9f2TiuPp8vGK1kNe3uWkCi4skMFtwmrYa2HTUNkqFoSmBaFni/A6cmbPDxO7NEU/qQfCN1eX6JwK/6Ff6SUYt1nydXSIoXMBU4nK2pdOoFWkoRLqoQqRa6smXeb3adaeEUk9K9S2KlSjUrJMb8aSIw= Received: from BLAPR10MB4833.namprd10.prod.outlook.com (2603:10b6:208:333::22) by BLAPR10MB5090.namprd10.prod.outlook.com (2603:10b6:208:322::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18; Fri, 25 Jun 2021 13:49:12 +0000 Received: from BLAPR10MB4833.namprd10.prod.outlook.com ([fe80::944b:884e:4b47:2f42]) by BLAPR10MB4833.namprd10.prod.outlook.com ([fe80::944b:884e:4b47:2f42%6]) with mapi id 15.20.4264.023; Fri, 25 Jun 2021 13:49:12 +0000 From: Chathura Sarathchandra To: "int-area@ietf.org" CC: Mona Ghassemian , Morteza Kheirkhah Thread-Topic: New Version Notification for draft-sarathchandra-tactile-internet-00.txt Thread-Index: AQHXacXun8coZuugR0y9pKos1Zgwm6skuH8Q Date: Fri, 25 Jun 2021 13:49:12 +0000 Message-ID: References: <162462768163.24598.6490283884737670168@ietfa.amsl.com> In-Reply-To: <162462768163.24598.6490283884737670168@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=interdigital.com; x-originating-ip: [185.65.26.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c5ff916-cb0d-4c12-2a37-08d937e003ea x-ms-traffictypediagnostic: BLAPR10MB5090: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bXd9sr/QjsCTYSJU/bJJhZgZPseOe5tbWv2PdoEwRBzKMg9MgWzr0vMH3IWJ6MF2eQ7XMzgJ85W9hOPNM+2PlSMKDzzDTbSw74MY4VfCkkJ9gWby7SWkg063gSDXBxPQ5cmD+2wVEIKxOPab6/w5gkJ7D84YckaPG/Yf4IU/VNN+u24HYtOMXwtyKfsmCjH0iAa1oKGn5w814cJDLexsWbT5H5f18u3xPJrKD1yeBnpgaywX2tmECzQWECiegPZ8M4ki5DVlsJchXkeU3kNote+b5ITgbho4/OOlhZBi7QGg9vNz9qYVt1Bku0oXX0ssnRLwZQ6lnrl2hQ/kot81Ah6OaV4J8yagZNd2U6CaZyVP7O+eoh2fPeBQvWe2rj+H4lfXA/Oxg0apkNvKAogHUK09NC0bocKuGmb+aaB98cMoiGTwWNNPk8s/eYmm291rtb1UYuW7peLGioA91On/DvNgwCtM2b9NSkhhxTFQ4+9XgtuCaISfWgWtWUUhhzIi1hDmI74scpcQ9b1vX10h8VPnBpMgKgFC7kIZmjGAIbDQYjm1sgyrzwKg4uMFtszoOWq2KdswW7+oCl+TXQ+mfNrhmOGV4OlOoFch+mXO/Q1HgFw97FSAWCmflevbs6gwl//ahcwZ6DC0PHsqLfJK6dQp7QJZqb0ncKRTnQV8hE+p5/czsy7dYspQ3uhDqXXTBSJ4naM/ocu9HH1GYKXco2cfx0nmDfsGmoxaVI7IkdOlyh29JSqdvl98MBFI9DijOOHApWrSHf+Ol01uGrzPGQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR10MB4833.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(136003)(366004)(39850400004)(396003)(66574015)(83380400001)(7696005)(8936002)(52536014)(66446008)(66556008)(66476007)(64756008)(71200400001)(5660300002)(53546011)(316002)(66946007)(8676002)(33656002)(2906002)(6506007)(76116006)(86362001)(186003)(26005)(6916009)(54906003)(122000001)(107886003)(966005)(9686003)(55016002)(38100700002)(4326008)(15650500001)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NlZaclVkanA0aytRNzcxeFk5RXQrakdpSGUvaGFsTUNUbFYwTWFwY1NwTVpn?= =?utf-8?B?Z0laREpIODV6UXJPdW9XSWlNWVQzNC9mN01DcENPaEc2dkNzTVEwYTB4MEJ2?= =?utf-8?B?bTdrWFF3bmxiMUJGY2hvbklTRHRXeVJ0ak5xdVdqRU1Ea3ZhQ3JvVy9waTVW?= =?utf-8?B?VlNPc1IwQ3lmWEdpR21PUHo3ZHB0SWNsSklGMEduRG9IcGJKYmR2aXB1eXFq?= =?utf-8?B?OUZjVFJVbE9XT2lydHoyNW9hZEVCN3lzaTRrK0FPUGVVVzhVaUhzMDFxa0sv?= =?utf-8?B?d0hVRjFSaXZocTgzY0NYWmFNS0NjUkcvcEhpMTN2ZW9oNXRoQXR1NEhsaFha?= =?utf-8?B?V2xSTmQzTVVJTGpCLzRjY1RKanoxR0R5a1VqT0pEQ0NWZHhaR1JEa0FPbWlo?= =?utf-8?B?cU8xalRoOGhFL2Q1NGI2bEU4SlZadlE0Q0NLWTE3b1pDSUt2NHNjbnh2eGxl?= =?utf-8?B?dXB6V1RSYkFIOGhUSzMxYUtOZHNpZnVYNFpUS1VIOGtCeVpLclZOakd0Ti9z?= =?utf-8?B?SkJsK1I3RGU3b0xVNzFaRE1BMkNhZTBiN2orQ1hEL2s4ODBaNlRWc0crNklI?= =?utf-8?B?THpPNjFkUUd6K2IzdStXTU43ME1FUVJzem5YUExXWi9BSEhXa2lrUXdWd0hV?= =?utf-8?B?RUVwRW16MmhvR2NucjhqTkwrVHBuL1hpRlY1d3ZmN0tLblNmL0JVNWtpcHkw?= =?utf-8?B?Z2FBbi84YzZwSnhiWlM0TUgwR1pBM2hVSjNOSHRWUkF4WjRubVFuZURQQmxh?= =?utf-8?B?SWFYUTYvMElDS0xwUUZ5cEI5SnByUVRvWFJSRk1IQkNIOEtQNXUzR0ZsK0xM?= =?utf-8?B?REEwQ3NZYTNjVFF5U0VhNTl0YzkzNVRmV3QxNGQyOU5QR0dLa3BLVjFZRmY0?= =?utf-8?B?RXF5UVEvMGhub21lV1hTamFGK25jVXVHZGtqQkJSS1BOK3U5ZDBoaS9sMmFM?= =?utf-8?B?dWdxOWt0QW9PMXl4dlI2anRmMEl0U0lCZUx3WTRRc3B3bnE4Q0JCNlRUbFZP?= =?utf-8?B?bHRycUhxMm9FSVlCK29TNHpFeXFjRjVBQys2WVd0TEJLTGxGMHN5cGErZ0VO?= =?utf-8?B?OWJ3dVREM0tUNUhaQmVQcE0xbFZmSG9WbHhOYmh3MkdBeHdWejkyaGdyVEtK?= =?utf-8?B?cTExajlXVytJOGd6L1VnYVdUL3ZhK1E2TDRnamQ2RXJjSXpVblRjS3hndEdV?= =?utf-8?B?QnA4VjRqUkFMb2pyZjlJZkQva3JOSFMxRjJBaXArejUxa3Z4TTdwTk1DOVVQ?= =?utf-8?B?V1NCMkhJOFBpRHFUSi9VUlowSnBKZmQyZGpPT0dRczREeDRIdEtodjEzUi9x?= =?utf-8?B?SHdvRVR3RFBhMWpUTkc1ZW56WTE3RWtwRDJOdE5PSkh1QldXR2lDTHc5ejRp?= =?utf-8?B?QzR0YnA5dW1zR1lGSGtyMjYxbDZ2QmZjU3hVczdMOGV4V1ErR0FTWnY0aXd3?= =?utf-8?B?a0hqRXZ5NWZGQWViZFl1bk92eWRjbzMzZHdQakFMZ0JmRVBjTkdjSTRIRTQx?= =?utf-8?B?Sks5TGdWZ3o2d05sTlR3cXZLR2ExQ05uSzlWYzltRlJiOXRJaXd1MEtlenFo?= =?utf-8?B?L1dZeHJsc0FOVU10ZHNTcTBnaTU4VHUxZE5pekJ1cWM2OWF2YzYvb1F6MnZk?= =?utf-8?B?cGkzcUk5WGFteENYUHQvZk05WEd3TmJaNGRoMksxZjNUOWlZSVBnNEFVWUVN?= =?utf-8?B?eVZ5OEZDUVRIOHZhd3pENTFOL0tpZzZMOEVwdHRseTZrZjZiL3pQY0xZR28z?= =?utf-8?Q?smRac/amiEfPmog7iPE8Xb24GREN7BX+OH+u/t7?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: interdigital.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB4833.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c5ff916-cb0d-4c12-2a37-08d937e003ea X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2021 13:49:12.6400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e351b779-f6d5-4e50-8568-80e922d180ae X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0BmhqXhVPNWH2I/kthVAMtrN4Zvp6Mrthzg7++JVztGP/xLa0q/1lUfV7W13NEdkk9rDm5NURpFryI5+hcsxwWzkQmn2ewbtk4EOLn+V4qXS9rvvl22qOllHK3lN6Z6O X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB5090 Archived-At: Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-tactile-internet-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 13:49:22 -0000 RGVhciBhbGwsDQoNClBsZWFzZSBmaW5kIGJlbG93IG91ciBuZXcgZHJhZnQgc3VibWlzc2lvbiBv biBUYWN0aWxlIEludGVybmV0IFNlcnZpY2UgUmVxdWlyZW1lbnRzLg0KDQpUaGlzIGRyYWZ0IGlu dHJvZHVjZXMgdGFjdGlsZSBpbnRlcm5ldCB1c2UgY2FzZXMgYW5kIHNlcnZpY2UgcmVxdWlyZW1l bnRzIHBvdGVudGlhbGx5IHRvIGJlIHVzZWQgYXMgaW5wdXQgZm9yIGZ1cnRoZXIgZGlzY3Vzc2lv bnMgYW5kL29yIHRvIGJlIGRpcmVjdGx5IGFkZHJlc3NlZCBieSBJRVRGLg0KDQpDb21tZW50cyBh bmQgZmVlZGJhY2sgYXJlIHdhcm1seSB3ZWxjb21lIQ0KDQpCZXN0IHJlZ2FyZHMsDQpDaGF0aHVy YQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IA0KU2VudDogMjUgSnVuZSAyMDIxIDE0 OjI4DQpUbzogQ2hhdGh1cmEgU2FyYXRoY2hhbmRyYSA8Q2hhdGh1cmEuU2FyYXRoY2hhbmRyYUBp bnRlcmRpZ2l0YWwuY29tPjsgTW9uYSBHaGFzc2VtaWFuIDxNb25hLkdoYXNzZW1pYW5ASW50ZXJE aWdpdGFsLmNvbT47IE1vcnRlemEgS2hlaXJraGFoIDxNb3J0ZXphLktoZWlya2hhaEBJbnRlckRp Z2l0YWwuY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1z YXJhdGhjaGFuZHJhLXRhY3RpbGUtaW50ZXJuZXQtMDAudHh0DQoNCiANCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXNhcmF0aGNoYW5kcmEtdGFjdGlsZS1pbnRlcm5ldC0wMC50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2hhdGh1cmEgU2FyYXRoY2hhbmRyYSBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1zYXJhdGhj aGFuZHJhLXRhY3RpbGUtaW50ZXJuZXQNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlUYWN0aWxlIElu dGVybmV0IFNlcnZpY2UgUmVxdWlyZW1lbnRzDQpEb2N1bWVudCBkYXRlOgkyMDIxLTA2LTI1DQpH cm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMQ0KVVJMOiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtc2FyYXRoY2hhbmRyYS10YWN0 aWxlLWludGVybmV0LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXNhcmF0aGNoYW5kcmEtdGFjdGlsZS1pbnRlcm5ldC8NCkh0bWxp emVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNh cmF0aGNoYW5kcmEtdGFjdGlsZS1pbnRlcm5ldA0KDQoNCkFic3RyYWN0Og0KICAgVGhlIFRhY3Rp bGUgSW50ZXJuZXQgcmVmZXJzIHRvIGEgbmV3IGNvbW11bmljYXRpb24gYW5kIG5ldHdvcmtpbmcN CiAgIHBhcmFkaWdtLCB3aGljaCBjYW4gcHJvdmlkZSBsb3ctbGF0ZW5jeSwgcmVsaWFibGUgYW5k IHNlY3VyZQ0KICAgdHJhbnNtaXNzaW9uIGZvciByZWFsLXRpbWUgaW5mb3JtYXRpb24gc3VjaCBh cyBjb250cm9sLCB0b3VjaCwgYW5kDQogICBzZW5zaW5nL2FjdHVhdGlvbiBpbiBlbWVyZ2luZyB0 YWN0aWxlIGludGVybmV0IGFwcGxpY2F0aW9ucyBsaWtlDQogICB0ZWxlb3BlcmF0aW9uLCBpbW1l cnNpdmUgdmlydHVhbCByZWFsaXR5LGFuZCBoYXB0aWNzIGNvbW11bmljYXRpb25zLg0KICAgVGhl IG1haW4gZ29hbCBvZiB0aGlzIGRvY3VtZW50IGlzOiAxKSB0byBicmllZmx5IGludHJvZHVjZSB0 YWN0aWxlDQogICBpbnRlcm5ldCBiYWNrZ3JvdW5kIGFuZCB0eXBpY2FsIGFwcGxpY2F0aW9uczsg MikgdG8gaWRlbnRpZnkNCiAgIHBvdGVudGlhbCBzZXJ2aWNlIHJlcXVpcmVtZW50cyB0aGF0IGNh biBiZSBhZGRyZXNzZWQgYXQgdGhlIElFVEYgb3INCiAgIHJlc2VhcmNoZWQgYXQgdGhlIElSVEYu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQoNCg== From nobody Fri Jun 25 07:03:25 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683653A199C for ; Fri, 25 Jun 2021 07:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DmcRoKFft2W3 for ; Fri, 25 Jun 2021 07:03:19 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 7057B3A199B for ; Fri, 25 Jun 2021 07:03:19 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15PE3Gnn021611; Fri, 25 Jun 2021 15:03:16 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0894746058; Fri, 25 Jun 2021 15:03:16 +0100 (BST) Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EFC2C46055; Fri, 25 Jun 2021 15:03:15 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS; Fri, 25 Jun 2021 15:03:15 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.32.44]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 15PE3F9a012167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Jun 2021 15:03:15 +0100 Reply-To: From: "Adrian Farrel" To: "'Chathura Sarathchandra'" , Cc: "'Mona Ghassemian'" References: <162462768163.24598.6490283884737670168@ietfa.amsl.com> In-Reply-To: Date: Fri, 25 Jun 2021 15:03:14 +0100 Organization: Old Dog Consulting Message-ID: <0ea601d769ca$d7e09950$87a1cbf0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJJqqzR8B9VgUXMUZF+tdOTBlwmdAM9RH+xqiZWBlA= X-Originating-IP: 84.93.32.44 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1017-26242.000 X-TM-AS-Result: No--17.309-10.0-31-10 X-imss-scan-details: No--17.309-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1017-26242.000 X-TMASE-Result: 10--17.309300-10.000000 X-TMASE-MatchedRID: pS5owHKhBO1or4mPA3EMtnFPUrVDm6jt82SgwNf6SK4G2HMvWEJenrA/ QRou0gCu0358+AbTtZ97nZmSglxg9jR43n0ulJJBUlu/qwZkdiq5I3Jkp5qIPkxScvlKr6fm81o SKb4F9XA2AjvSSs99nfXYR5PPzmsujOOpQEl/CqkxqPSO9PjTebBUpjZ3M0LCEoBacoHAF/8EVg RlP8d0Trenr9gWkU6qZvmjlvBmDkQeGK1H+WbKLmNW0DAjL5p+E84OITRIYTM2zrTcMEhlTgShl qBb6h43aZVAr7e0tXT7BuUrW9ZThBhTd5nWbn6fa4H5csZgN7Jv+B0owAW3BjGQt2RbsLmqAe9j Kv1n7mUusFuoC+/agdG0A+y7qX/46hNZec9WB6xQ1o+KC+IpH1HewY36PuY04TKzelTQRYE+J5V GCaEyf1cnZ4aX4owPpIedSklLP4X/zwOJRkAZvX+muMN+rZIR0VNHqads3gvVDsweybyEDSvC34 sFimMjq52b7WeJFhwNG2l8OIT6cdkYMdLUyvZUo90M/hchIwYL//VMxXlyExLf1vz7ecPHOKQZ9 jBdqwNDKL/ywk3FheDEVictPKL67YtyMLUpviusoC9I+K53Iex8b780hPr+a0TOsL14A2mpvKrY HQCqxgA1xPFd5qRFs4DW2QIMPzSagvq+uK+0JAlbBe5jKGf9QlZJSw4rxxSCTJUvpDBm3H2OLrz KFJBvO4HWgk7wz/kZijt1cgK90Kkv9z5O2l4Gs/qHY/9cqiq7x6BKDZREH2FHVj+6F+rI7UbCRx D+UhIofobenAmSsZGTpe1iiCJqCjQ91G0rshap/mH7gW9/gAU5rQ/jDZbqjoczmuoPCq2UTGVAh B5EbQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-tactile-internet-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 14:03:25 -0000 Hi Chathura, Your draft is an interesting piece of work. Three places you could go to look for support... You might want to advertise it on the SARAH mailing list (subscribe via https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=SARAH&A=1). This mailing list is a research-oriented forum for discussing work concerned with changes to addressing and routing in the Internet specifically to facilitate new services that have varied traffic delivery requirements. The "Application Aware Networking" (APN) effort is a new drive at the edge of the IETF to produce a way to mark traffic in the Internet so that it may be given different handling (routing, queuing, etc.) by the routers. There is a mailing list at https://www.ietf.org/mailman/listinfo/apn and we are planning a first meeting at IETF-111 next month (https://www.ietf.org/how/meetings/111/). The TEAS working group (https://datatracker.ietf.org/wg/teas/about/) is working on "Network Slicing". One purpose of slicing is to produce a partition of a network's resources in order to support enhanced connectivity services (enhanced VPNs) that facilitate services like those you describe. See https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/ and https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/ for more information. Best regards, Adrian -----Original Message----- From: Int-area On Behalf Of Chathura Sarathchandra Sent: 25 June 2021 14:49 To: int-area@ietf.org Cc: Mona Ghassemian Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-tactile-internet-00.txt Dear all, Please find below our new draft submission on Tactile Internet Service Requirements. This draft introduces tactile internet use cases and service requirements potentially to be used as input for further discussions and/or to be directly addressed by IETF. Comments and feedback are warmly welcome! Best regards, Chathura -----Original Message----- From: internet-drafts@ietf.org Sent: 25 June 2021 14:28 To: Chathura Sarathchandra ; Mona Ghassemian ; Morteza Kheirkhah Subject: New Version Notification for draft-sarathchandra-tactile-internet-00.txt A new version of I-D, draft-sarathchandra-tactile-internet-00.txt has been successfully submitted by Chathura Sarathchandra and posted to the IETF repository. Name: draft-sarathchandra-tactile-internet Revision: 00 Title: Tactile Internet Service Requirements Document date: 2021-06-25 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-sarathchandra-tactile-internet-00.txt Status: https://datatracker.ietf.org/doc/draft-sarathchandra-tactile-internet/ Htmlized: https://datatracker.ietf.org/doc/html/draft-sarathchandra-tactile-internet Abstract: The Tactile Internet refers to a new communication and networking paradigm, which can provide low-latency, reliable and secure transmission for real-time information such as control, touch, and sensing/actuation in emerging tactile internet applications like teleoperation, immersive virtual reality,and haptics communications. The main goal of this document is: 1) to briefly introduce tactile internet background and typical applications; 2) to identify potential service requirements that can be addressed at the IETF or researched at the IRTF. The IETF Secretariat _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Jun 25 07:20:53 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7D3A1A0F for ; Fri, 25 Jun 2021 07:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WkDpnZ-AA4lT for ; Fri, 25 Jun 2021 07:20:47 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B255A3A1A0A for ; Fri, 25 Jun 2021 07:20:46 -0700 (PDT) Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GBJj71HFLz6L52T; Fri, 25 Jun 2021 22:07:07 +0800 (CST) Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 25 Jun 2021 16:20:40 +0200 Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 25 Jun 2021 15:20:39 +0100 Received: from lhreml701-chm.china.huawei.com ([10.201.68.196]) by lhreml701-chm.china.huawei.com ([10.201.68.196]) with mapi id 15.01.2176.012; Fri, 25 Jun 2021 15:20:39 +0100 From: Dirk Trossen To: Chathura Sarathchandra , "int-area@ietf.org" CC: Mona Ghassemian Thread-Topic: New Version Notification for draft-sarathchandra-tactile-internet-00.txt Thread-Index: AQHXacXun8coZuugR0y9pKos1Zgwm6skuH8QgAAMVbA= Date: Fri, 25 Jun 2021 14:20:39 +0000 Message-ID: <1731b19a3f3a448cb8e5fb865866547a@huawei.com> References: <162462768163.24598.6490283884737670168@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.64.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-tactile-internet-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 14:20:52 -0000 Hi Chathura, Interesting draft, indeed, to start a discussion here on this list. Adrian'= s responded with a piece I'd also recommended, namely the SARAH list, where= this contribution may well contribute to possible discussions on addressin= g and routing aspects related to the Tactile Internet.=20 Apart from that, I wonder about the degree of dynamicity that you foresee i= n your scenarios (of Section 4)? The use case draft in the COIN RG (https:/= /datatracker.ietf.org/doc/draft-irtf-coinrg-use-cases/) outlines an enterta= inment use case with a personalized and interactive nature, where dynamic r= elations, e.g., between (parts of the) performers and (parts of the) audien= ce are foreseen. The tactile notion is not emphasized here, leading to high= er acceptable latencies maybe (although when mixing distributed music, you = are still down at few ms latency). But it's the dynamic relations that I wa= nted to point out, which pose additional requirements. This may also be the= case for industrial use cases, BTW. Maybe something to consider as a possi= ble dimension? Best, Dirk -----Original Message----- From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Chathura Sar= athchandra Sent: 25 June 2021 15:49 To: int-area@ietf.org Cc: Mona Ghassemian Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-ta= ctile-internet-00.txt Dear all, Please find below our new draft submission on Tactile Internet Service Requ= irements. This draft introduces tactile internet use cases and service requirements p= otentially to be used as input for further discussions and/or to be directl= y addressed by IETF. Comments and feedback are warmly welcome! Best regards, Chathura -----Original Message----- From: internet-drafts@ietf.org =20 Sent: 25 June 2021 14:28 To: Chathura Sarathchandra ; Mona = Ghassemian ; Morteza Kheirkhah Subject: New Version Notification for draft-sarathchandra-tactile-internet-= 00.txt =20 A new version of I-D, draft-sarathchandra-tactile-internet-00.txt has been successfully submitted by Chathura Sarathchandra and posted to the= IETF repository. Name: draft-sarathchandra-tactile-internet Revision: 00 Title: Tactile Internet Service Requirements Document date: 2021-06-25 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-sarathchandra-tactile= -internet-00.txt Status: https://datatracker.ietf.org/doc/draft-sarathchandra-tactil= e-internet/ Htmlized: https://datatracker.ietf.org/doc/html/draft-sarathchandra-t= actile-internet Abstract: The Tactile Internet refers to a new communication and networking paradigm, which can provide low-latency, reliable and secure transmission for real-time information such as control, touch, and sensing/actuation in emerging tactile internet applications like teleoperation, immersive virtual reality,and haptics communications. The main goal of this document is: 1) to briefly introduce tactile internet background and typical applications; 2) to identify potential service requirements that can be addressed at the IETF or researched at the IRTF. = =20 The IETF Secretariat _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From nobody Sun Jun 27 14:22:21 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE983A1B05; Sun, 27 Jun 2021 14:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 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.338, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 HJ_3skOUDxoY; Sun, 27 Jun 2021 14:22:15 -0700 (PDT) Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 0C0753A1B02; Sun, 27 Jun 2021 14:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fd0iZ6Q2atBgYYOmairczK19x3MFshAF8CYB4L9GuHA=; b=4mqBtE3a9iattUjuo0/YXZCMP6 GpYHBjkOpnr64ifEtn4WK9ME1BbYDcPsw2hXxkJVL6w7FEdUvgiD347kTEAoOeLPoohK7lQUEXUyy V3+MxUguzg8CGNWDGgDQHqOFWnnRpsYUXvPxKthFj2hZuIa7zD+MtaVf+/wAp0ysbIxuHa6wc7OzM b2nj2ByNsQYSrs6Hqy1O6Ugmt89o0Xvsa61tPLXvuxSdzX56fHenbEZZy1HWPzMt64ffgGxQ8Q3Mz nGjwfpCC9mAkTVNyGfe//QTEEqVwmEgAnaqpi0uCpKAnR1+ObPm6dmTAjvGxS0obNcXYjgLjC9bCO rsP2Y1fQ==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:40030 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lxcEG-0003is-DI; Sun, 27 Jun 2021 22:22:12 +0100 To: James Bensley , intarea IETF list , pals@ietf.org References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> From: Bob Briscoe Message-ID: <3421c34d-0fba-df94-89a3-64abdc325633@bobbriscoe.net> Date: Sun, 27 Jun 2021 22:22:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 21:22:20 -0000 James, [First apologies to everyone for asking the question then not following up on the answers until now - I went off line for a while.] See inline tagged [BB]... On 10/06/2021 13:09, James Bensley wrote: > On Wed, 9 Jun 2021 at 15:57, Derek Fawcus > wrote: >> On Wed, Jun 09, 2021 at 03:07:41PM +0200, James Bensley wrote: >>> On Wed, 9 Jun 2021 at 14:05, Giles Heron wrote: >>>> Re BT specifically (and again my info is outdated and may be mis-remembered) the 20C network used L2TP, and I think it’s an option on 21C for handoff to smaller ISPs. Should all be in the SINs somewhere? >>> I work in the UK ISP sector. I can confirm that L2TP is in wide spread >>> use for wholesale services by all major ISPs (except Liberty). I think >>> the real question here (unless I've misunderstood) is not "is L2TP >>> being used" but "is L2TP being used AND sequencing is being used >>> and/or enforced?" - is that understanding correct? >> Yes. > In that case - sequencing isn't used for BT Wholesale services. [BB] Thank you. It sounds like you have some reason for your certainty here. Can you elaborate on what makes you so certain sequencing isn't used? Bob > > Cheers, > James. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Sun Jun 27 16:23:47 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002063A1FA5; Sun, 27 Jun 2021 16:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 iEUYcvTNNDFh; Sun, 27 Jun 2021 16:23:39 -0700 (PDT) Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 7A1743A1FA3; Sun, 27 Jun 2021 16:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mGL8cBBOyr8uVPfDjSNPs5p7JmQpb8mPreSklnYWvXU=; b=XplEshLSAn3/IaLmTBaRyJeXnJ xh6wwotZTES1qPAxcy8Dd7Mtd82GD4nWUHN2QxLFbZJz07sDLTsDRFcmvetEcXSLvmxB2Yy7gBuTr 4aV98utS98+/0bundqL8SAwzOIbgdRkFbv4L8u0+AllK5tea1qGkJm+4YZ+c9dJToyYJihq/zuDKQ rsPAYTMTzvlSGGdGr9Rl2sJVEaIe9pEm4+f5cbmil1V/rXRppdu/zuwL+SYSnoakOJIFDqIuVElmx 3Mn5BC4IoYzXqszw9VwLf2/zLlH76BgEs3jw2+VNvdk0kaYDc5wpjJLuxAcUiII+n7SHciCjH8aSa fOmIvTew==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:40518 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lxe7l-0003Du-1B; Mon, 28 Jun 2021 00:23:36 +0100 To: Giles Heron , Mark Townsley Cc: Carlos Pignataro , intarea IETF list , pals@ietf.org, "Andrew G. Malis" References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com> <50ADB293-A7EC-4574-9430-43E68073A6D1@townsley.net> <4AC24C92-DD6C-4D5E-B113-0123DFD842A5@layerfree.net> From: Bob Briscoe Message-ID: <7c89b2b3-1576-bdec-c2d5-64393f27f7bf@bobbriscoe.net> Date: Mon, 28 Jun 2021 00:23:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <4AC24C92-DD6C-4D5E-B113-0123DFD842A5@layerfree.net> Content-Type: multipart/alternative; boundary="------------AF1AF4F7105C7A8236C31AC8" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 23:23:45 -0000 This is a multi-part message in MIME format. --------------AF1AF4F7105C7A8236C31AC8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Giles, Mark, On 10/06/2021 13:22, Giles Heron wrote: > So AFAIK SP networks don’t generally reorder packets in the steady > state, but of course reordering can occur under rerouting. [BB] The cases I'm concerned about are where the operator * deliberately reorders packets using a multi-queue scheduler at a node contrived to act as the bottleneck (the BNG) * AND the node is within an L2TPv2/3 tunnel * AND the tunnel needs sequencing at the egress for some other reason. In many cases, such a scheduler would be located prior to the tunnel ingress, so not a concern. I believe the DOCSIS rPHY case below falls into that category (both downstream and up). In contrast, where a BNG sits /within/ the span of an L2TP tunnel, I think it will often (or at least sometimes?) have been constructed as the bottleneck. Any operator having designed such a QoS arrangement would not want to support sequencing... > > As noted by Derek I’m guessing reordering is an issue for L2TPv2 if > stateful PPP compression schemes are in play (which I suspect is > unlikely to be the case given we usually have abundant bandwidth in > the aggregation network, and given that compression can occur at other > layers).  Though given that BNGs inherently keep state per subscriber > maybe the NPU scaling issues that Stewart mentioned are less of an > issue in that use case than for MPLS PEs doing PWE? My concern was that 'keep it simple' operators that are using L2TPv2/3 and had not previously bothered with the complexities of QoS might want to support L4S, because it has the potential to cut out queue delay for /all/ traffic. Altho' L4S is eventually for all traffic, it still requires two queues at the bottleneck for transition - one for L4S and one for not-yet-L4S ('Classic') traffic flows, and therefore introduces reordering at the aggregate level... From the replies so far, even if such 'keep it simple' operators were using compression, I can't see any reason why having to turn off compression and sequencing (in order to support L4S) would be a significant problem nowadays. So, in conclusion, I don't think we even need to raise any concerns about L2TP sequencing in the L4S specs. If anyone here thinks otherwise, pls speak now. Thank you everyone who has contributed to this discussion. Cheers Bob > > From a quick look at the DOCSIS rPHY specs it seems they do require > support for L2TPv3 sequence numbers.  Of course in that case the > payload is the DOCSIS MAC rather than IP (even though, of course, most > DOCSIS frames ultimately carry an IP payload). > > Giles > >> On 10 Jun 2021, at 12:49, Andrew G. Malis > > wrote: >> >> (resending with cc: list trimmed to pass the too many recipients filter) >> Mark, >> >> The original question was, how many (if any) of these L2TPv2 and v3 >> use cases use sequencing, especially when carrying IP? >> >> Cheers, >> Andy >> >> On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley > > wrote: >> >> Hi folks, >> >> In addition to the DSL arena, L2TP is still in use with >> host-based VPN clients as it is embedded in Apple, Android, and >> Windows based operating systems (new and old). Despite most VPN >> solutions preferring their own client software that must be >> installed on hosts to operate, there are still admins that >> appreciate not having to ask their employees to download an app >> for the VPN to work - in which case PPTP and L2TP with >> transport-mode IPsec are your most widely available options. >> >> Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. >> L2TPv3 generalized L2TP to support other L2 (including MPLS, but >> I don’t want to argue what layer MPLS operates within here). >> There was never a strong push to replace L2TPv2 used in DSL, >> Dialup and host VPN software with L2TPv3 (there was one use case >> for an important L2TP operator that wanted to carry PPPoE over >> L2TPv3 in DSL, but that was overcome by RFC3817 which achieved >> the same goal without altering the dataplane). Ironically, I >> would expect to see very little PPP over L2TPv3 in the wild, >> though obviously it is possible. >> >> In the cable broadband world, the DOCSIS DEPI “Remote PHY” >> specification (similar I suppose to the split BNG spec Joel is >> referring to) standardized on L2TPv3 and is in active use. >> >> I also know of at least one vendor that uses Ethernet over L2TPv3 >> for some wifi backhaul use cases. >> >> There could be more, this is just what I am personally aware of >> off the top of my head. Even I am surprised to see how much L2TP >> is still out there once you start really looking around ;-) >> >> Best Regards, >> >> - Mark >> >> >> >> >> > On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct >> > >> wrote: >> > >> > 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 > > 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 > > >> 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 >> > >> > >> 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 >> > >> >>>>> 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 >> >> >> _______________________________________________ >> Pals mailing list >> Pals@ietf.org >> https://www.ietf.org/mailman/listinfo/pals > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------AF1AF4F7105C7A8236C31AC8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Giles, Mark,

On 10/06/2021 13:22, Giles Heron wrote:
So AFAIK SP networks don’t generally reorder packets in the steady state, but of course reordering can occur under rerouting.

[BB] The cases I'm concerned about are where the operator
* deliberately reorders packets using a multi-queue scheduler at a node contrived to act as the bottleneck (the BNG)
* AND the node is within an L2TPv2/3 tunnel
* AND the tunnel needs sequencing at the egress for some other reason.

In many cases, such a scheduler would be located prior to the tunnel ingress, so not a concern. I believe the DOCSIS rPHY case below falls into that category (both downstream and up).

In contrast, where a BNG sits /within/ the span of an L2TP tunnel, I think it will often (or at least sometimes?) have been constructed as the bottleneck. Any operator having designed such a QoS arrangement would not want to support sequencing...


As noted by Derek I’m guessing reordering is an issue for L2TPv2 if stateful PPP compression schemes are in play (which I suspect is unlikely to be the case given we usually have abundant bandwidth in the aggregation network, and given that compression can occur at other layers).  Though given that BNGs inherently keep state per subscriber maybe the NPU scaling issues that Stewart mentioned are less of an issue in that use case than for MPLS PEs doing PWE?

My concern was that 'keep it simple' operators that are using L2TPv2/3 and had not previously bothered with the complexities of QoS might want to support L4S, because it has the potential to cut out queue delay for /all/ traffic. Altho' L4S is eventually for all traffic, it still requires two queues at the bottleneck for transition - one for L4S and one for not-yet-L4S ('Classic') traffic flows, and therefore introduces reordering at the aggregate level...

From the replies so far, even if such 'keep it simple' operators were using compression, I can't see any reason why having to turn off compression and sequencing (in order to support L4S) would be a significant problem nowadays.

So, in conclusion, I don't think we even need to raise any concerns about L2TP sequencing in the L4S specs.

If anyone here thinks otherwise, pls speak now.

Thank you everyone who has contributed to this discussion.

Cheers



Bob




From a quick look at the DOCSIS rPHY specs it seems they do require support for L2TPv3 sequence numbers.  Of course in that case the payload is the DOCSIS MAC rather than IP (even though, of course, most DOCSIS frames ultimately carry an IP payload).

Giles

On 10 Jun 2021, at 12:49, Andrew G. Malis <agmalis@gmail.com> wrote:

(resending with cc: list trimmed to pass the too many recipients filter)
Mark,

The original question was, how many (if any) of these L2TPv2 and v3 use cases use sequencing, especially when carrying IP?

Cheers,
Andy

On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley <mark@townsley.net> wrote:
Hi folks,

In addition to the DSL arena, L2TP is still in use with host-based VPN clients as it is embedded in Apple, Android, and Windows based operating systems (new and old). Despite most VPN solutions preferring their own client software that must be installed on hosts to operate, there are still admins that appreciate not having to ask their employees to download an app for the VPN to work - in which case PPTP and L2TP with transport-mode IPsec are your most widely available options.

Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. L2TPv3 generalized L2TP to support other L2 (including MPLS, but I don’t want to argue what layer MPLS operates within here). There was never a strong push to replace L2TPv2 used in DSL, Dialup and host VPN software with L2TPv3 (there was one use case for an important L2TP operator that wanted to carry PPPoE over L2TPv3 in DSL, but that was overcome by RFC3817 which achieved the same goal without altering the dataplane). Ironically, I would expect to see very little PPP over L2TPv3 in the wild, though obviously it is possible.

In the cable broadband world, the DOCSIS DEPI “Remote PHY” specification (similar I suppose to the split BNG spec Joel is referring to) standardized on L2TPv3 and is in active use.

I also know of at least one vendor that uses Ethernet over L2TPv3 for some wifi backhaul use cases.

There could be more, this is just what I am personally aware of off the top of my head. Even I am surprised to see how much L2TP is still out there once you start really looking around ;-)

Best Regards,

- Mark




> On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct <jmh.direct@joelhalpern.com> wrote:
>
> 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

_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------AF1AF4F7105C7A8236C31AC8-- From nobody Mon Jun 28 01:17:58 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFDC3A3033; Mon, 28 Jun 2021 01:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UuZ4WJoEbQBX; Mon, 28 Jun 2021 01:17:48 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B493A3031; Mon, 28 Jun 2021 01:17:47 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id c11so24374830ljd.6; Mon, 28 Jun 2021 01:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BkPOYQsKc4oQ7ufsNBa+e72wzfNLQ1eHs+iDr7DeAtc=; b=YeVWzy78lzfMIKS1rqOWiTiF49AyCHMP88x+XTf76kwyTrQPD9B8syoMUxee+OsWq4 859LB3XFg9v2sFgk+KQCtQdjMEQl/0r2nUrNKxJGtRRs8Vry04pj3FAJO2ulQXD4tvOx DdE9BfbKj1Zi7KL7m9Tm6FLYW5Alnl3RXfHxTQEwIHUoML92yJzvKNwx5NEquU2BXVmC zy5vsTnY4q50cxpRxgzWXk7IZ558vawhwY8LDTkMcUMXbLmBhrojwNdhegfHnVJPdDR8 7AzXldWe5XbdTpA6sRS6SNLbztQ+8hC6FqbiGFPobd61tlxuHsL1Fwnt4ZR0cPjCN8dR 3GzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BkPOYQsKc4oQ7ufsNBa+e72wzfNLQ1eHs+iDr7DeAtc=; b=nVZqFmSfcmMba3pM/FMaKrWOBZI7RhKVBrUP4wFPBqCCGb8YqDdbTcOF/ZfQX23dle MG+qIRw6mNzV6busFqNBLpyX64xhBjhWPAEAcYaU3Gj8ABto8xAfz0g7BS0faEKE0okj iziyu/pW6xT50yRmL0WsYbnsg+lOX49PHoPTy4IWus7c89ptslqb6JZjS4HbQYbyhkak niv2AlD1GOtIRc2b5gFbZIW4j6TfFWhwpgpU1wieNUZVWuGIsME/USqma2kjlWA32zOt 0I+/9uGsFXWaq3E/NUnKDD01Vc+mwh0yL7KJdfTxtf2NYmnrZNXm3mXSxcNf/BCqKmwc ceBw== X-Gm-Message-State: AOAM532f9BDGcqdcwUumjt8yiPH6lHnVtt0eg4yi/k27jgPXw3s6oqZr wli4MWBt7GpCoC9pYJsQjaF7GYeOdgJR80I/rJw= X-Google-Smtp-Source: ABdhPJxuDl/kRYBwwtm40CJ9PRurYcEd/a/3rNvaij3TLMQR8w1wQjAjy7jTVzy6136s3IVHypDClX2ajNGMbAhWzWk= X-Received: by 2002:a2e:8e8a:: with SMTP id z10mr608175ljk.314.1624868260810; Mon, 28 Jun 2021 01:17:40 -0700 (PDT) MIME-Version: 1.0 References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> <3421c34d-0fba-df94-89a3-64abdc325633@bobbriscoe.net> In-Reply-To: <3421c34d-0fba-df94-89a3-64abdc325633@bobbriscoe.net> From: James Bensley Date: Mon, 28 Jun 2021 10:17:12 +0200 Message-ID: To: Bob Briscoe , pals@ietf.org, intarea IETF list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 08:17:53 -0000 On Sun, 27 Jun 2021 at 23:22, Bob Briscoe wrote: > > James, > > [First apologies to everyone for asking the question then not following > up on the answers until now - I went off line for a while.] > See inline tagged [BB]... >> [JB] In that case - sequencing isn't used for BT Wholesale services. > > [BB] Thank you. It sounds like you have some reason for your certainty > here. Can you elaborate on what makes you so certain sequencing isn't used? Hi Bob, Sure, my current employer is a BTW customer and I have checked our live/current set-up and L2TP sequencing is disabled. I also worked for different UK operator previously that was also a BTW customer. I've checked the old configs and outputs from when I was there, and again L2TP sequencing was disabled (I'm in close contact with those former colleagues they confirm it is still disabled). I've asked a few friends at other UK operators, and none of them have L2TP sequencing enabled on their BTW tunnels. I've also scanned the BTW docs and can't find anything that mentions it is supported. Cheers, James. From nobody Mon Jun 28 01:39:50 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A993A30F8; Mon, 28 Jun 2021 01:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 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.338, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 Y081dk1MLAWZ; Mon, 28 Jun 2021 01:39:44 -0700 (PDT) Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 1AC413A30F1; Mon, 28 Jun 2021 01:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BsovClnQo7Va+8Dn7OSnUZQ2svzm9fs3/Ot+PqYQ61E=; b=SptbDzNuvYsCmq6YE3+4QdAwPH JcirNJdgf3BV5IFfR3qcFEjy6YLPuh0j+4J9OBn5XOv4E/rAYUAoiPy2jVkfBYIleB2nTMzXKusjT y8og8Z4ZUXKN6zBPwIJHA0KnOHnrmdihpvunO9IWPqNjd5WbgJC4UbRSWUWuoWJzZNCAem9mW7PRQ NtbMN09EpPH3fLWtkFIGcKW8yqFEmPvvnL8wL7NfVhyzWZtHvno6HDpFWAXbiICKN73WclCf3nsc/ vE+mjTQcBXatkpcEq16TADOsUcFPi61RW29Ke3RDp7PyoqNOBXbgHt+Mtf3LVb58e2TQ8VEdyiAC4 pfNVy6ow==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:40734 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lxmnp-0005Zz-Fx; Mon, 28 Jun 2021 09:39:36 +0100 To: James Bensley , pals@ietf.org, intarea IETF list References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> <3421c34d-0fba-df94-89a3-64abdc325633@bobbriscoe.net> From: Bob Briscoe Message-ID: Date: Mon, 28 Jun 2021 09:39:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 08:39:49 -0000 James, On 28/06/2021 09:17, James Bensley wrote: > On Sun, 27 Jun 2021 at 23:22, Bob Briscoe wrote: >> James, >> >> [First apologies to everyone for asking the question then not following >> up on the answers until now - I went off line for a while.] >> See inline tagged [BB]... > >>> [JB] In that case - sequencing isn't used for BT Wholesale services. >> [BB] Thank you. It sounds like you have some reason for your certainty >> here. Can you elaborate on what makes you so certain sequencing isn't used? > Hi Bob, > > Sure, my current employer is a BTW customer and I have checked our > live/current set-up and L2TP sequencing is disabled. I also worked for > different UK operator previously that was also a BTW customer. I've > checked the old configs and outputs from when I was there, and again > L2TP sequencing was disabled (I'm in close contact with those former > colleagues they confirm it is still disabled). I've asked a few > friends at other UK operators, and none of them have L2TP sequencing > enabled on their BTW tunnels. I've also scanned the BTW docs and can't > find anything that mentions it is supported. [BB] Thx for looking into this in such depth. My attempt to generalize this UK-specific knowledge: No-one is going to add sequencing without a reason, and the only possible reason mentioned so far would be stateful compression, which these days would just slow things down more than the bandwidth saved. Cheers Bob > > Cheers, > James. -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Jun 28 01:41:34 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDF23A310E; Mon, 28 Jun 2021 01:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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=btconnect.onmicrosoft.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 hSY0Zk-rRcdM; Mon, 28 Jun 2021 01:41:24 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30129.outbound.protection.outlook.com [40.107.3.129]) (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 24DB93A30FD; Mon, 28 Jun 2021 01:41:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OQvTvd4yiamnQ0cAYJsKaixia6JHGALcpT9lNSGLF/VC1VNFc2327L/E29AnWX+ToQxR+kxDXzwWypIb1TL9xTSz4Gzy/AqYmgBY5xxJix1G5+WMWnZX+Ib7cDTLV4tz8P6VLqpFHmgC6mnnMFqSw5Gz1qQGEw33u0x7yN594jIL3oRXIs1pxg9UM/zOlh7UUbtXuuqPE61FyDkqBsxX1OoKc99jkJlDBhMcEKyJMmSVAfWbE93AMjZiSLcOVgzZG+zYDK6k2p0xKMoquFSNLulqneRCs4Yjrm/8GMG6v2swRrKTOWCsfJ+5FguEALBxmXiHaQG47mgrt6Cb5aYyjg== 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=Sw5EFDMquJVF3LQWDB4Q26FAGWkw9ad6fX2xi3MNxYw=; b=jDDQXuoyaGEFaxcWCo8UIDYTXlJkMpmnX9F/fTgilTz8rdKslQRDvvF5J0UAGabFLYP1MW7vXdOGLtLhf/sHaF1Wc3ODuR114bAro2jm8NSWYZ7/xRS1YxvKZbsphKH8NrZKhX8mfQTCtwHQB/yjLAAgOWfhsqzgFpx4ZYOFHLWe93dto3kV62UCocN0UVlOvu40pIb0glxaB4esYk6Syrsd1ATyi8eEKhsMXKQbeZJXxATuYok0SZIjr/dD19rhmjmOzs6K0bwJBvS/xgaFsQ4eOLhsxVnu0wHCIozhxTcn00fQcFEh/DbwW2iKYcRh1a8tpKDHFkuFjDcdbjXphA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sw5EFDMquJVF3LQWDB4Q26FAGWkw9ad6fX2xi3MNxYw=; b=SVX/wTFvo1MU7OWBndzDHVE34xPKRNA/ix+f2R4GGn9erYbt7czGSj0KhUkhvNzrm8O3pEciAdGjeQzubbp7LBEbJ2J71yGahwvfimGEH5cEsmlj19kFLqs7eTReXUukyjU8XRTaiN0DvQKtxh904OlqTuVlj49KYqrgRtDXOZg= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB6167.eurprd07.prod.outlook.com (2603:10a6:20b:65::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.14; Mon, 28 Jun 2021 08:41:20 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d%7]) with mapi id 15.20.4287.021; Mon, 28 Jun 2021 08:41:20 +0000 From: tom petch To: Bob Briscoe , James Bensley , intarea IETF list , "pals@ietf.org" Thread-Topic: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? Thread-Index: AQHXa5p9U9Ir8TOIyEq2GOWWmKh/faspGheK Date: Mon, 28 Jun 2021 08:41:20 +0000 Message-ID: References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> , <3421c34d-0fba-df94-89a3-64abdc325633@bobbriscoe.net> In-Reply-To: <3421c34d-0fba-df94-89a3-64abdc325633@bobbriscoe.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb4b3c5c-4e88-40ef-241c-08d93a1080ba x-ms-traffictypediagnostic: AM6PR07MB6167: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w+T8v0v90JGhzOG96FiZP9of17Tuql+Vk7EkclVe+khBdn+quqsgZiq8apu5oMD6ViI6Y0tMVtLOWtRJgUTsShPaajLfAUNS4+qO7hFrjYWK7DDy0h8/HNRIBdtfDXyqUg8GLaoAtGp7GFe1Up5LNkEisyyXDZ7iIAkqq+HEE2VkPDaKl6ERI3g8SvorBuKlZwGbL4dy32BG+nWgZKrOnQ5mmVU3ed/0zHr5HYXYkT/sQlz/VhpJROYGJdyjHWxppMnkq6EUTISCNH3EhfayLlZG6Vwytvph/lueDDVh+bey4QankfrUqJ+dvgpvzBn6CU2EP8LoErStzihXWzG6s9VxUTua3GMsAuzT6yH7hDGbO9Zl/Hd1O1AX6j5CfkBHVuiSl8ICf2/+OjVkoTimvS7utcIlaINLpHTJR97ZFJ1GftSktCQq1L7mE6CTlMApb+NHsBIZQ1jjS30GIt/iQP0AwZ58miacnt5+CL0gpjP0/anEy5wUzLUQZOI917201dtoOYgRWf+zdyLPtWqcgdt6dfHwjKoQXuBusWWm4gUL21jk0vD4yYZUh8WyNHVcfxCowpzv6bphN8rCcLjI7rbEAWNHM5D362Z0fcpjS12QQAxCJwTY2u9MRssZIGo7zE5JQ9lBdzeEh13qcVxQUNBbCFTmGdmWQZGXe7QpULIQnMQVGb7nODyjsItZi6nJJtEXvRxTlhBJozZAPQuww2rBEET42GcnZQxcBvI+Uk6VRQVKQsFz33yAf3tFlU2e9xhuVVJs5YBGmD0tO7SOvw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(396003)(366004)(39860400002)(8936002)(316002)(53546011)(6506007)(8676002)(478600001)(33656002)(110136005)(71200400001)(26005)(7696005)(2906002)(966005)(83380400001)(186003)(91956017)(76116006)(66446008)(64756008)(5660300002)(66476007)(66556008)(66946007)(9686003)(38100700002)(86362001)(52536014)(55016002)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?IRouj3dKuZZqdTg0njFpWWKRFDc3FlZT5bARBFa95KpZ2FzK3AzVzrF1?= =?Windows-1252?Q?2TpmdS+EmC64ht7W0i8IWnH59dAFfwbEh2AqYVO89UT6V5z/bVwhonU7?= =?Windows-1252?Q?cQWyjyh91wObEDIX88jZ09QiiYjmKr1LP44MCL9Av4shvQ1v5MLwamwJ?= =?Windows-1252?Q?L4kdW+UG7JgGzoiBG7iyueCygl3/RWTbAD0SY4iKsBvQ8Jjbwd+HVtDZ?= =?Windows-1252?Q?b/iU7ZTJyNYDKLpWwNTRe+LrGP9vZ6gJsqyikn7fOTIqpcy/tzF8wJ9v?= =?Windows-1252?Q?F/GZKYwIDBWIzwqiJRk/zFboeNyox7dIQGbJIFRuM5MjoxHZnjNEUykH?= =?Windows-1252?Q?tg303/sgUTOOvCN+rAm31swD/K3XdHwfPm9onH8ieAtnP8oVLCKu/UhP?= =?Windows-1252?Q?sxUrZ/NvSk6d8VZTZW0xoVCQOy8tLT1ouQcts4e4O8vKg/GH149grS8m?= =?Windows-1252?Q?ijfwTADrf1NsjAtspJEbTYI9V6OQs/r3bhCcR06XZlDebxzdUqNaJIax?= =?Windows-1252?Q?1asqg3H83QbWCd9iV66RyCZZ2hwuc1F6QAu5nql1stOSTdwZt05fMeys?= =?Windows-1252?Q?rSAm7NpqWPx4RVRxNiDb7afISbGj+sAfNHpUNUGOUlyOq1IEy+RUfnQ9?= =?Windows-1252?Q?5qUu5Vy5k57zD8jYNaPlECtxNRH9Ug0r66DvTJQmKBWuOgf96LJOcI1/?= =?Windows-1252?Q?0rPtBkNOiuB7dKD2+Dc6xpXS6crW12Ukayj64P6F9yRxB5IQmRbWEiQE?= =?Windows-1252?Q?TIQZv4llQfagkqSnWI9PL0vPPePayHdXr2XXWaCiWwLyKmjhiPmeBVKW?= =?Windows-1252?Q?EUxYkcwBWT9pq2YWr30SEp5JzjqZ7VNqADRmNmaa3fBdTsJjj8V960Ag?= =?Windows-1252?Q?JQPTHVTHgYvu5xomzUWWa00StzZRRlxu/zuwS3oGmYL4my/sPYk5gyag?= =?Windows-1252?Q?KMJt2wamiM7jQY665ZpEqL8nGP//hq32Msm3hYo1RtB9Em5nOy/C1Kp7?= =?Windows-1252?Q?klZ/PPGb1+ph345FShOrZMU2qJ0Xmjll7utEj4VfSxKcbJoHnb31N61V?= =?Windows-1252?Q?B/xbLNf6M4meE0yzvRfmL7nMgTzsrKW7TG0PzZd/4aZR6Ay8Xi1FJLvJ?= =?Windows-1252?Q?f59Zs8kWr3D5SV6FmPLnMGqvOnr8PHN+mMTva2ewgITq854y6E/967eS?= =?Windows-1252?Q?b6cDZmZucn8dN0gjLlgVJHMacBd4ASiuX1eB1NOX7/xW7kBDG0tzTec1?= =?Windows-1252?Q?j0TvqlXpTc9FifiBS7pQ+BXDvPVW7MHB+Ch1U6aqKY1jHy2TIbq4JwQF?= =?Windows-1252?Q?+3SgdIc2DiyrglXWTel0KcIwiNNAQZI8/JRVUwiJLqv5rTfKpAv+Oflr?= =?Windows-1252?Q?RvXpMJBDG17r3/sygV1+eWi3C5eUibG2dHg=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb4b3c5c-4e88-40ef-241c-08d93a1080ba X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2021 08:41:20.2678 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: m+z6Q9canne5D1sZQRHzvXPz0R60zcB9nPtz2zJEhhl18SA2f4nVUOFtfdCJedx6SeXMBB15XIBQO6a5jpcujw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB6167 Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 08:41:29 -0000 =0A= =0A= From: Int-area on behalf of Bob Briscoe =0A= Sent: 27 June 2021 22:22=0A= =0A= James,=0A= =0A= [First apologies to everyone for asking the question then not following=0A= up on the answers until now - I went off line for a while.]=0A= See inline tagged [BB]...=0A= =0A= On 10/06/2021 13:09, James Bensley wrote:=0A= > On Wed, 9 Jun 2021 at 15:57, Derek Fawcus=0A= > wrote:=0A= >> On Wed, Jun 09, 2021 at 03:07:41PM +0200, James Bensley wrote:=0A= >>> On Wed, 9 Jun 2021 at 14:05, Giles Heron wrote:= =0A= >>>> Re BT specifically (and again my info is outdated and may be mis-remem= bered) the 20C network used L2TP, and I think it=92s an option on 21C for h= andoff to smaller ISPs. Should all be in the SINs somewhere?=0A= >>> I work in the UK ISP sector. I can confirm that L2TP is in wide spread= =0A= >>> use for wholesale services by all major ISPs (except Liberty). I think= =0A= >>> the real question here (unless I've misunderstood) is not "is L2TP=0A= >>> being used" but "is L2TP being used AND sequencing is being used=0A= >>> and/or enforced?" - is that understanding correct?=0A= >> Yes.=0A= > In that case - sequencing isn't used for BT Wholesale services.=0A= =0A= [BB] Thank you. It sounds like you have some reason for your certainty=0A= here. Can you elaborate on what makes you so certain sequencing isn't used?= =0A= =0A= =0A= =0A= Perhaps a coincidence or perhaps not, but an I-D has just been posted =0A= Author : Yogesh Nautiyal=0A= Filename : draft-nautiyal-l2tpext-tunnel-ka-control-channel-00.txt= =0A= which uses L2TP sequencing, I note the author has an affiliation of Junipe= r.=0A= =0A= The draft would need a fair bit of work.=0A= =0A= Tom Petch=0A= =0A= Bob=0A= =0A= > Cheers,=0A= > James.=0A= >=0A= > _______________________________________________=0A= > Int-area mailing list=0A= > Int-area@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/int-area=0A= =0A= --=0A= ________________________________________________________________=0A= Bob Briscoe http://bobbriscoe.net/=0A= =0A= _______________________________________________=0A= Int-area mailing list=0A= Int-area@ietf.org=0A= https://www.ietf.org/mailman/listinfo/int-area=0A= From nobody Mon Jun 28 09:24:35 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0963A0CD4 for ; Mon, 28 Jun 2021 09:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=interdigital.com header.b=C+A8XR5c; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=interdigital.onmicrosoft.com header.b=F8f0VhUd 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 nY2c1-YPM168 for ; Mon, 28 Jun 2021 09:24:26 -0700 (PDT) Received: from esa1.hc3352-98.iphmx.com (esa1.hc3352-98.iphmx.com [216.71.145.135]) (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 C62B03A0C37 for ; Mon, 28 Jun 2021 09:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=interdigital.com; i=@interdigital.com; q=dns/txt; s=esa; t=1624897466; x=1656433466; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WUS6cU1b4NM4wDqJwPHBYI3+zEHMKsQhyWzv+MVpnT0=; b=C+A8XR5cAnxDLdh3tKIt46WkB4rbD00iP1+UEx1eFGfM0UWF+bb2qbjR NcamnZSheWqDdVxGFh0hnFS8AItwvh0FitlBq5P9KT7kXpCcm+kML4ZKO gPUtUM58/taQhe+OQG5yDca2F+Z4KuF5q6kI5fbDJn0U8m0Ju25f3EaF9 brouwGJ8OGs92kQ1VKyk/Ez2N8YgTx5vyZXD0xeSThakFZJRN94RSbWWQ cpFX+anXVIEJOM1a85lYr3XptkIn5bLNpFcwQSjDiBxheS6ofkITKxS9O f638pxNmoKrIRzHWoEzwdebaCx8eRGvONwkyYgij+DGecRyCdcpXSQ8Hj w==; IronPort-SDR: zE4zr+zLStBRt/nHMYa7koMoXVyFIawR9E4Q196xJuYW1dZJ9UUh/bAHPKNPyjZIq1JrED6/vj S8+xbVS0qNaILUuGb+2Elcg5OXRRUPIxuTEJz2jLmPL49vMHs5gv6QDK1gkw5qUVESb4FGyZvP qL+J4ALTNrXe/zrS1uwpeq1PNdk/1ncbz641hzwzeyz5ewqwZAokQD3ER0Cs2Er3DTsZ0CIA5o nrkf/aFH/cdskSzLWp826QlwPNfc6kfi4lqL1HVipY7rIOPrxbvdfRwjAQ6tP33XL/DVT9OTO5 Obw= Received: from mail-bn8nam11lp2177.outbound.protection.outlook.com (HELO NAM11-BN8-obe.outbound.protection.outlook.com) ([104.47.58.177]) by ob1.hc3352-98.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2021 12:24:25 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jmwOIq5IqRaKp8dgm4twvbd4aWgrUnPrYivMYWDGdsXkbvV9+3Emj7+T25vIaPd0r4BYpDXLsHR6Os9c9+258LrjQZLHWWTYFWXn2LyVQq0qB0IhdfWDk1Vd6KnmxCTFLvQ+SAEy5eX+7+8KrxEHnbm9FozOG4mNdpRLOr+QQ9Uv6wQFGlYO9XCo83OYVttxj++r71ic/k4jv4uhaNgRg9Bp+Ho13KhH7Updg8w17YYzycEdNcEA5oFlTT3HUr+l4WUdVCBFh/H0i9oGOjVQ3OkVJPsiQbeOxT6+MXd7JeDUmbEepBlcRiqNu0Nn2XoAfyrN0OwNnKoK3RrWgEPizw== 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=pcCv/0iuABoCN9HBp0ScaDwoWnnIdNwhoxLeVrME1GU=; b=eb+al//h5YGc3qQ8/G1BXyEc47TBV1Pj+yNtLJpbjKxB3qkLfG8WK6nOyWLxZn9QTQ4ETZ1uVKorOAq+7XHun95MpDMT9qJVjk3FX/gkuN3/d3OGBahN7S0BufzwKGbiOM0YAuBiR2n247Ssla9g1hXBQwUYNRd821GOYsJQdBcLDY4yIvlQdNqXiXWKVxePuRHtHLfVcm5ScHRXFUPGTt6+075rhjjBOc/M7yS9boSgpklQuT86XK9k7FG0Kd5a54e/uLYLCX654a4MKXyU3viXYMS4hd9trQjhYvINQYEjsbhlk8JwD0vqXP776KDevjtFFYF9OOlntjMrfkg6dQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=interdigital.com; dmarc=pass action=none header.from=interdigital.com; dkim=pass header.d=interdigital.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interdigital.onmicrosoft.com; s=selector2-interdigital-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pcCv/0iuABoCN9HBp0ScaDwoWnnIdNwhoxLeVrME1GU=; b=F8f0VhUdINx6lIuZ16PTvU/u2eozFK+UmexypNOqFSdZKKBCTz877r1BYjj+RmQruHniPBNIJpGdS+UMy7Dv4cSnlXMr91pJ4L/XE/jfO+howbLB0nqrVm4hcbElkJlIG8nOVpBaDOeho9CTQigYiTDx/vj+5OG7TIpcC6wPvzM= Received: from BLAPR10MB4833.namprd10.prod.outlook.com (2603:10b6:208:333::22) by BLAPR10MB4977.namprd10.prod.outlook.com (2603:10b6:208:306::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.19; Mon, 28 Jun 2021 16:24:22 +0000 Received: from BLAPR10MB4833.namprd10.prod.outlook.com ([fe80::944b:884e:4b47:2f42]) by BLAPR10MB4833.namprd10.prod.outlook.com ([fe80::944b:884e:4b47:2f42%6]) with mapi id 15.20.4264.026; Mon, 28 Jun 2021 16:24:22 +0000 From: Chathura Sarathchandra To: "adrian@olddog.co.uk" , "int-area@ietf.org" CC: Mona Ghassemian , Morteza Kheirkhah , Renan Krishna Thread-Topic: [Int-area] New Version Notification for draft-sarathchandra-tactile-internet-00.txt Thread-Index: AQHXacXun8coZuugR0y9pKos1Zgwm6skuH8QgAAJogCABN4SwA== Date: Mon, 28 Jun 2021 16:24:22 +0000 Message-ID: References: <162462768163.24598.6490283884737670168@ietfa.amsl.com> <0ea601d769ca$d7e09950$87a1cbf0$@olddog.co.uk> In-Reply-To: <0ea601d769ca$d7e09950$87a1cbf0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=interdigital.com; x-originating-ip: [89.36.69.52] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 20cf9efa-2652-4ab2-99e3-08d93a513050 x-ms-traffictypediagnostic: BLAPR10MB4977: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UYZ0CxxsRKzYMZq0KVxZfQ6A8aadJob9es2brJ1dXp9cSDqM5PNWDAwTJJChyT2ht67KVI37ymXIeyKhndcaMVwT8aNroyFKw19yAD9kHzK8g3MeaNbXDJNZz7/I2Y5iOmLqlJbuYKN50lPU2h3Bu5nZ9bHVKiyrXz1YAXiQU3ctbpzJjn9Yd6dRVOh9vYcgwsxH9mfa1MWGu5KRGvLYPQhI9veuzlYg7bVB4eV7/qp6aZUK0qfG9WP7DUlCrP3lP5KWb0kvba163YdbvYGtCfswtiQZix9/lgPIa0vM+Zw/bd8YWJ/nQGrOUipD08e3bP23yxpYTUjLg+VHdD3Q2DnvQKW6QebR2bBWZe6I+vvHdahygbKvidXbeZBtELvKVwgWxVOuuToPz2GJ/WPD84dXXGU1kKCqQqr9dojxNEbdSKyvmZdWZHXr0tC4/78zpSOt+0jvS8rG+g+b1CeZEMs9uRGys5c6Kgad+vhMEGBiwVisLkwxte98J/wLVa2Ifc3m7+ePNWUZdgs0sv1VPx45ZFVVzkqQFRiOp9dB3hD18v4pgVa3j8YViqlyOFlk9CHYL38hiZwhvJJNyvhHr2WE6CrDXjZrFX3F6f+vCU9uIx37RVi3UQyGrgqUWr6wX6aG+fF9ahw0RznXubicBhmCymc+Cq3Mu3D/087dujyqmfX8RDWDo13lOZaA7rViNYj1Iu00ObXCHBzzQGmg4JAj9kw3QmmiOWwqLWnpLokGlfRMNIIhD4G4hbAfmFY2i6XByJTY0OGIeBFEFF77jw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR10MB4833.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(33656002)(107886003)(66946007)(9686003)(66574015)(71200400001)(66476007)(76116006)(66446008)(83380400001)(66556008)(52536014)(64756008)(55016002)(8676002)(8936002)(186003)(966005)(26005)(6506007)(122000001)(86362001)(7696005)(54906003)(110136005)(498600001)(53546011)(2906002)(15650500001)(4326008)(38100700002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?HKc2HA2ylcOOM1HPm8PKcCA6Iq9cvCaBvoxfboOCQ5bWQQC7ndDotA63dNdO?= =?us-ascii?Q?2HbG4zWaAJh8OvmPAKRO+DgA0/pOS159WU7+WUZ1spuneYx2FF+IPuS2fZQl?= =?us-ascii?Q?O3AvC2e8Ib4sb90/1fAQYlki5nZKoc+XXY9ycNDik4Lk5UwzjG9MGQ0uULSv?= =?us-ascii?Q?XI/N9Nd6geOD7sAh1JdQkycKQ67nTGw0iTIa3p36ay6Vd76sJWKHlCdc0KMG?= =?us-ascii?Q?j2FVQOqYs7kgKRfUnB1xoT4Ci+IsdCExR66KTsRx83CW4v9N8MI/5MOr7zVB?= =?us-ascii?Q?UZWoF2sK5AxFgTCcOTb5UCV1efNoweg6obeO1uDtNe1lmjO21ENe4vGYYMS6?= =?us-ascii?Q?jJexsuc4jyq7U5IGfFfHTFh1M4ybgR0cRye1K+7GRq/Or0xu+lNJlwx1AhUZ?= =?us-ascii?Q?eXbTNwuQFFVkfPzMg05xaofhuq4Z9j6dFyEiUxzVlfCXze0tRCgmmcz7MUK1?= =?us-ascii?Q?fiUHujKbKGLGR1xE5gKQjYhHFJqHQI4HxEkcjSct1uCLDkHTtIeVVqLPu6IG?= =?us-ascii?Q?b7uvfJ0C58hPu14ztIFQpOr4lozxNNl2ccKfLiM+7dxcw6dy+F3yl8ZL3G2N?= =?us-ascii?Q?gHECq8fPX3fDV4tDZ1XBYUAOO2h+ytqGlKcFG2dL11ayon8J2gZAunB58EOu?= =?us-ascii?Q?TToHF+wH7X1+nHH3aTkBRxA5NzyEC9/Z23KOdw7yckM5tVIaEy8gRKbj2nSO?= =?us-ascii?Q?PgI/Qw00ud8ZtV8dlqvCC2AHi+8Rrmr2yyW9gLLrbHe7hiazDBMNYkBnOhzV?= =?us-ascii?Q?2xwOTyHHbPX6Nu5J5fuWteW379vI1BSM5Ieaq3dOOkO2VngmqBER9zhwXQcy?= =?us-ascii?Q?3vwteR9MiYD+PzdrxfDSK1RxkHsH8pb0JqX+UNB+xzPV4zfLVBoe5l9mnf3+?= =?us-ascii?Q?wrYHq2UTpZslsQbcLPxIrrgznWiL5brufxgH92+nx6AuQM8ynkp0hDNNyv9/?= =?us-ascii?Q?pZwYn1q/E0QbruTI7Nw/waB2GFkBO0I4tOiXzFZTX2ekgIxLfgU8YMIHYXcc?= =?us-ascii?Q?WRMOPFgmAfBMj+gjNIsnd5qaAUhmxvbnPSbzuIVr+JHyj8m7gJci3u/0Wk8k?= =?us-ascii?Q?hmBETofidsTF/6SiVdJUWrlY17IVRV8unYUxZxypx+kIbcdBIhp2Wo/mi+Fx?= =?us-ascii?Q?F9ZpLFfmRoaxT7QC2pcJCMMRIbBYR7X0tF7PPtFQj8YiYDQptietg34at1qm?= =?us-ascii?Q?twWK3wmSVBbeIG45YkPtSTIyyE4m+e3UXbWSPqK4XlAEcrCf4IHq5aGtzYkI?= =?us-ascii?Q?PAVyBqe6Tj3OndW6XkX4hfsBjTVr/Jnyza4C8vWQX8fgAgrNU+pte10RygO7?= =?us-ascii?Q?TNY=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: interdigital.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB4833.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 20cf9efa-2652-4ab2-99e3-08d93a513050 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2021 16:24:22.5811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e351b779-f6d5-4e50-8568-80e922d180ae X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: h567FK3e/wL6w2waCIkYXZsOmbxh+kTvSWGHYzYlJjdJMUbxoHwFqAlCLGwGmNYIRgMukRdCy7sigXZLC/HoJbCJsti8ghDejY74Qe16+SE9vyIF3VBYu3Q57xyQbPey X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB4977 Archived-At: Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-tactile-internet-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 16:24:33 -0000 Hi Adrian, Thank you for your suggestions on potential places we can get support from.= We will proceed accordingly. Best regards, Chathura -----Original Message----- From: Adrian Farrel =20 Sent: 25 June 2021 15:03 To: Chathura Sarathchandra ; int-a= rea@ietf.org Cc: Mona Ghassemian Subject: RE: [Int-area] New Version Notification for draft-sarathchandra-ta= ctile-internet-00.txt =20 Hi Chathura, Your draft is an interesting piece of work. Three places you could go to look for support... You might want to advertise it on the SARAH mailing list (subscribe via htt= ps://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=3DSARAH&A=3D1). This mailin= g list is a research-oriented forum for discussing work concerned with chan= ges to addressing and routing in the Internet specifically to facilitate ne= w services that have varied traffic delivery requirements. The "Application Aware Networking" (APN) effort is a new drive at the edge = of the IETF to produce a way to mark traffic in the Internet so that it may= be given different handling (routing, queuing, etc.) by the routers. There= is a mailing list at https://www.ietf.org/mailman/listinfo/apn and we are = planning a first meeting at IETF-111 next month (https://www.ietf.org/how/m= eetings/111/). The TEAS working group (https://datatracker.ietf.org/wg/teas/about/) is wor= king on "Network Slicing". One purpose of slicing is to produce a partition= of a network's resources in order to support enhanced connectivity service= s (enhanced VPNs) that facilitate services like those you describe. See https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/ and https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/ for more= information. Best regards, Adrian -----Original Message----- From: Int-area On Behalf Of Chathura Sarathchan= dra Sent: 25 June 2021 14:49 To: int-area@ietf.org Cc: Mona Ghassemian Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-ta= ctile-internet-00.txt Dear all, Please find below our new draft submission on Tactile Internet Service Requ= irements. This draft introduces tactile internet use cases and service requirements p= otentially to be used as input for further discussions and/or to be directl= y addressed by IETF. Comments and feedback are warmly welcome! Best regards, Chathura -----Original Message----- From: internet-drafts@ietf.org Sent: 25 June 2021 14:28 To: Chathura Sarathchandra ; Mona = Ghassemian ; Morteza Kheirkhah Subject: New Version Notification for draft-sarathchandra-tactile-internet-00.txt =20 A new version of I-D, draft-sarathchandra-tactile-internet-00.txt has been successfully submitted by Chathura Sarathchandra and posted to the= IETF repository. Name: draft-sarathchandra-tactile-internet Revision: 00 Title: Tactile Internet Service Requirements Document date: 2021-06-25 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-sarathchandra-tactile-internet-00.txt Status: https://datatracker.ietf.org/doc/draft-sarathchandra-tactile-internet/ Htmlized: https://datatracker.ietf.org/doc/html/draft-sarathchandra-tactile-internet Abstract: The Tactile Internet refers to a new communication and networking paradigm, which can provide low-latency, reliable and secure transmission for real-time information such as control, touch, and sensing/actuation in emerging tactile internet applications like teleoperation, immersive virtual reality,and haptics communications. The main goal of this document is: 1) to briefly introduce tactile internet background and typical applications; 2) to identify potential service requirements that can be addressed at the IETF or researched at the IRTF. =20 The IETF Secretariat _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From nobody Mon Jun 28 09:25:52 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BA13A0CFA for ; Mon, 28 Jun 2021 09:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=interdigital.com header.b=o2ZbCDQF; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=interdigital.onmicrosoft.com header.b=vNgkGK5q 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 M-_uqyC-vVdM for ; Mon, 28 Jun 2021 09:25:44 -0700 (PDT) Received: from esa2.hc3352-98.iphmx.com (esa2.hc3352-98.iphmx.com [216.71.148.90]) (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 BE4D03A0CE7 for ; Mon, 28 Jun 2021 09:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=interdigital.com; i=@interdigital.com; q=dns/txt; s=esa; t=1624897544; x=1656433544; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=po8upbLyk9nan9O3t3HdmWMkxAVxSHqNxdttE9qEPYI=; b=o2ZbCDQFiFYWtmdvtqxWxFohmUxQoqsYvkaa7dc3oGTfhtJtYSrOmSPh u3MMI02OlDJhSS2jCJDJUJXgJLH5tGetIcaJ2Nm38GukPaXl6cAOC78KK 1OFzoY+msTGMvRSKLFMCRVJ4njScieAgJNFU56qBls6m/VTUPmBQ1yXfO 5PoHP5kfGW9827itrc7PggvADPdmv2HkNcnjrI/ktnFZ3YI8S/jMfhF90 E672JZhePofCA0tNwDWig/eJloBluSLOvfVws9iiq6E6axuhzwwYgrwlM /+jNRHuUT8oXzaao2hqDo9fhbkl/ukMmt+jc3WwDpyP8N+TL9Sr98+Dcg w==; IronPort-SDR: W/w5+81MFkAYs4Yetl8zixLFeL9ppELqqEeLPpLATZbCdniO9YhQcq67oWy1+BIWGwZa7gIVHO S80p3MEJSatu84/F63PUs5WUDI3ZLSq3RM4hF6v2MOZcXaCjUYrkAHXN57tUQkTXP92jbRkkN0 wvyAQTKJYo0jii47QhAn1KkYJ5IsjuzKR9988nsLB2vllBRoTHykwKuTj+GoirFI8y5S7ERhhP MbMLBTI37NvMrb4xdSwgAFTSw/9iFHvYzobVcZRYlVHBKduUoWznyGelN8ZGz721XUAp0v2bpQ cSE= Received: from mail-dm6nam12lp2171.outbound.protection.outlook.com (HELO NAM12-DM6-obe.outbound.protection.outlook.com) ([104.47.59.171]) by ob1.hc3352-98.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2021 12:25:42 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fifz5jqadaQ44Es8wVPfswahk74TRf9xUxELlj8qoH/ZeIQB1KS1OZybl2394BeVOFO9tIyZ7LI9sHHn/k3wLHxTubeYdFrHipsuzvwrskIH+ATm+bFWYQlD0q7yc5wHqp6vS89ofKJxnWtElpNWNc+TZ8/nZNfQh9/k+EwcHU5f9XggqkP6hY2AEWFQ/diz8AVJdbttkwI4GH6xfC/2NUGVfkJBKHt3HQ4T6FTq2aE5ycJyOjNpeyajsgcsk73zW8enIA80KX2GBooScQCEaUGD8PTAgabSQw2+GTwEEl72Lndbnmg/TScRN6qSSH5G9dpDO1YkwmqFzKkdveXfSg== 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=CcLGCGYLLbLYwxAhBcdLpP7Tvfo5iAJ2zRQBltLuDYE=; b=cdyI95NbIUC7KcZ0ZrzBdb77aAR/Lbigx7ODd/0Z2RQbMvOOzD1VSkT5fKmHk9lbmseW5HW92cjTQDJ1Ac+oLwMsjndvNkAYGcq993FTrydXTuAREwIjjPs/f4gKBvQkuT5b6jp4rFtb3BmrL2eYLXSSw3WhwEnKS04iWlDPg2EA1c0y/DTMawRDwCqECsrujOVtMY2Vb43wN3Tcgjw+e2iehK+GVWTwqmqKz507ufZva8BGgUNAdVrDhcO/l/OyAx9GXPO57Gd1rOLUjezmORFzllwecYMVWsRGxaFuBvpJitC0SsUcvaa52Xi7RqrH/I7tLvFU5tKVLcXDwm4PHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=interdigital.com; dmarc=pass action=none header.from=interdigital.com; dkim=pass header.d=interdigital.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interdigital.onmicrosoft.com; s=selector2-interdigital-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CcLGCGYLLbLYwxAhBcdLpP7Tvfo5iAJ2zRQBltLuDYE=; b=vNgkGK5q91ET/newgPd1/lP+fyMBauzjICr1M+t6Q+HUWbwqbG6MUwHwDm+GkjYz6QsoVAnNT6cRKYtOj5CzJnYjTgmXr48VT2XeJhjiQ8xENpYd1r5kMP1jYKO348L68cgceUif+7PIb67PMIhkcjnbUpznnQslde/XHt43LXQ= Received: from BLAPR10MB4833.namprd10.prod.outlook.com (2603:10b6:208:333::22) by MN2PR10MB4061.namprd10.prod.outlook.com (2603:10b6:208:182::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.20; Mon, 28 Jun 2021 16:25:39 +0000 Received: from BLAPR10MB4833.namprd10.prod.outlook.com ([fe80::944b:884e:4b47:2f42]) by BLAPR10MB4833.namprd10.prod.outlook.com ([fe80::944b:884e:4b47:2f42%6]) with mapi id 15.20.4264.026; Mon, 28 Jun 2021 16:25:39 +0000 From: Chathura Sarathchandra To: Dirk Trossen , "int-area@ietf.org" CC: Mona Ghassemian , Morteza Kheirkhah , Renan Krishna Thread-Topic: New Version Notification for draft-sarathchandra-tactile-internet-00.txt Thread-Index: AQHXacXun8coZuugR0y9pKos1Zgwm6skuH8QgAAMVbCABFuL4A== Date: Mon, 28 Jun 2021 16:25:39 +0000 Message-ID: References: <162462768163.24598.6490283884737670168@ietfa.amsl.com> <1731b19a3f3a448cb8e5fb865866547a@huawei.com> In-Reply-To: <1731b19a3f3a448cb8e5fb865866547a@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=interdigital.com; x-originating-ip: [89.36.69.52] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5564328e-8f8c-4a7f-e134-08d93a515de7 x-ms-traffictypediagnostic: MN2PR10MB4061: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pX/Ct3FHM6beAmWpsPQad9K1gtBggcM0lzM0a6D6WjMezLwE36zHHfAKaI30bXJye5AQEv1RUCdar/UUKw59qhtSvV4mfHtS+kUvkPzCqSp4Z8rrIKj47V8fwvbwUV9NVnjzSdgB4RuBKp5rQiOegmMrj2c7B7C9Nd46PC1nsavTffwz1/ONiAlRDOiUD11Y29JEG/qiysuqTIDLfylaXdJid4EAdeg/9Zy4ZqkU94jU2F+0jucLy1RbJHJ2SsiWm3wawyCV5QbWX92zLL8DIhNDLDL0dngrge9Cw/9Ul735aGvR9wHE1wpQjbaRXOBxyOB6MDaKL6RgPLu5lcqgwM2HY89DQLpIOVY2jouE9NsJY1c9NE20SYeSfwT0p/w4yFSy2R4HANiolKq0PDTPFQZpICunSJEPdOTv61+D2ZPoLprlA6ytLZKgXiw36V/D4gqxbwsweFGi0C3kDk/fDe7Axx4KUrI5s5GaAv38z0LUww8w8+C78lb6j24hPVMQXQ8QVhqT5pi+gcX7Z9UjLK7uhCYM1XWkAiSzcIHxZ+UKOQj0FmsreNLIE12nThjSbY81M5ebBuEF12Fm+YWtrAkPCdf8MwW2gD/Lo/DrMKwQ2Nxaew2RI9dOos+IH4kl/KgJGz5KTh7eAYvApO6HNzwAqDuStufUR1PzGU4hfMF4ZIkHmPpX8i/7bMEqmX4G1Csb4b+uTnNpNhX8zlO0aw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR10MB4833.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(366004)(39850400004)(136003)(376002)(7696005)(5660300002)(2906002)(478600001)(53546011)(66446008)(66556008)(66476007)(8936002)(8676002)(66574015)(6506007)(86362001)(64756008)(66946007)(316002)(9686003)(76116006)(54906003)(52536014)(4326008)(83380400001)(71200400001)(55016002)(107886003)(15650500001)(110136005)(122000001)(186003)(966005)(38100700002)(26005)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?eD34WFZRYQ2QN6EDm9ek7T8e6DNHGV9je2eatA7SZ/uFmVvlsyOdDQdjaD6d?= =?us-ascii?Q?TSRmhg+6WMrzjMCbFmPGJy7JlSnBYuaK39H/FXaJ0bhpxu3Qq2iKkTdWrmdM?= =?us-ascii?Q?yOGfvHL1+g4i7Udlqi3Rr//JBVzEf2uvzMPyyutXIK4cG0yNg+mHcAKB/Oww?= =?us-ascii?Q?w+mkwb9M4YMX6vqQLn4GaPNOdwCS3VsWHW+LOf0ZwvD1hMS264g5Nl8xRW2q?= =?us-ascii?Q?oAKZTsRwNxXSmXWbrSZRtE+XoqPChPY7YzygyJXd1ggcQpm6nGBRDLFuqhvU?= =?us-ascii?Q?5k5vlCm5Jtcu7ivGOKQ9wgNKKizrtKivej/vhSg+6+naHuyArNVhigw26zIW?= =?us-ascii?Q?JCrCrsbgZq/HwfXUCjbFMFftdDgbBCrS62H54qnVSMaW/pQ0L/nKhaUs6Wa1?= =?us-ascii?Q?bSYemmHt2z3UPbsfLRokmGqNeY6Isw+d3Vn83PIMFcvNJVDaWEnuRlOKIyVe?= =?us-ascii?Q?2dAtOw6keTnBYy4sEtULVibb7rWS9aWyGL6+1Q2r8oaAW/D8r9VVH/Otnhgp?= =?us-ascii?Q?J3JH9zdqCrioPEhQ+SAXnbN67BEE3JlW4LJM5AetDP9PqzEV5j6sWeItV5BM?= =?us-ascii?Q?lazey/XRPXawFyqvfxyJ1VpX1515wQi+TyhzhI2NStv6ZoSs1N3SdkbX0uGF?= =?us-ascii?Q?qYW+cbZ3sbYt3ocCL85IhQO7P+9bQ9/RRl7ZYw2GThyWOxI8sxCmLNayOWsb?= =?us-ascii?Q?hog+VTgzkQ37otMd1B452RMP5flGLxw5UVYQzQ+yr51zXl9M45QgH8mDUpzA?= =?us-ascii?Q?2aEZfMkI5rwjDPcXrPuYF1wRdXZCX6DVGbylwmxNkVq6vNbR57I3/c9KRTa4?= =?us-ascii?Q?/3wSGctHgXjseQ28hbnDjPG/7lPKedhw3OEGDCU5jhWxxyIPJoVTdonM4XaI?= =?us-ascii?Q?VhoR1KwjHfaYYvRwZ6URhbEWLb4cN1HUx5VwnjuXFfrUkK886BDgMTbqaqdP?= =?us-ascii?Q?N7s1pLKVuJz5/8BNeNCrA8U1DEWNVc/DNyowWnxt1O+ZHMVgMyDK3hG7NjNz?= =?us-ascii?Q?lhAGRm+eQHfBCoJB9mkg9Tjj7Zfm2dy+qO07LTlXZKoCkCIIWmvqXcFGOljE?= =?us-ascii?Q?kpRmAPaicac73T6o5jwQCdWmk5+Am4SVuzbiOqofnSwGeTicMkRsZr/s8Zgb?= =?us-ascii?Q?rlHDrlyUPECia3QKVVLAbWB7iAhKWgzvx9304Tw2m9Jt7jHmuBiKBvYmXAIB?= =?us-ascii?Q?Mapo+271UTNKVej5/7cgnpr0lKm1TxL88LqR+WPtH2/59VlFRfx0/U7CUxsX?= =?us-ascii?Q?ct1LqiQHcw++oJxO6gChSCstcwcOy5zv00zaOCRTT3sNe7pADSO/S1lS7Za2?= =?us-ascii?Q?K8o=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: interdigital.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB4833.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5564328e-8f8c-4a7f-e134-08d93a515de7 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2021 16:25:39.0561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e351b779-f6d5-4e50-8568-80e922d180ae X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fsRq2LtfFAKRi8FCflGOYgzsyfVrgKSjxwWv/n2L4cD8tOKFOSeB91abWUdkicqF+fqIgCYuD2CnUn9aeyZB98nJbuvq5w+bTMhWrW0TRZhnzpu8hv35h4fWl7x4Gr7f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR10MB4061 Archived-At: Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-tactile-internet-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 16:25:51 -0000 Hi Dirk, Thanks for the suggested additional dimension for the use cases. The use c= ase referenced is an interesting one indeed (user interactivity and persona= lization added on top of https://www.kcl.ac.uk/news/the-worlds-first-5g-low= -latency-3-way-distributed-orchestra-at-kcl)! Could not find a link however= to haptic communication aspect. Maybe can provide a haptic experience that= is in sync with music for users who are disabled and can't perceive audio = and/or video?=20 By dynamicity do you mean how different user profiles and user interactions= are taken into consideration, in multi-user scenarios? And how the resulti= ng user-specific information (of the same experience) being transferred to = users (audio-video-haptic) ? If yes, certainly it is another dimension of = the use cases, e.g., Entertainment (gaming), Training (training simulations= ). For example, in scenarios where virtual simulation environments used for= training, where multiple users act upon the same virtual objects, the info= rmation received by individual 'trainee users' may differ due to 1) user pr= eferences (e.g., with haptic feedback vs without) 2) individual user's perc= eption (e.g.., audio, video haptic) of objects and actions/events within th= e virtual environment (e.g., based on viewpoint, distance to objects/events= , and properties of virtual objects [different users may receive different = haptic feedback depending on the type of actions performed], experiences ma= y differ per each user). Moreover, the trainer (human or virtual) may choos= e to provide corresponding feedback (using audio-visual or audio-visual-hap= tic mediums) to an individual or a group/subset of trainees in real-time. S= uch an experience must be provided while meeting stringent latency requirem= ents imposed by haptic. We may add the aforementioned aspects related to dy= namicity into the use cases in the next version of the draft. Best regards, Chathura -----Original Message----- From: Dirk Trossen =20 Sent: 25 June 2021 15:21 To: Chathura Sarathchandra ; int-a= rea@ietf.org Cc: Mona Ghassemian Subject: RE: New Version Notification for draft-sarathchandra-tactile-inter= net-00.txt =20 Hi Chathura, Interesting draft, indeed, to start a discussion here on this list. Adrian'= s responded with a piece I'd also recommended, namely the SARAH list, where= this contribution may well contribute to possible discussions on addressin= g and routing aspects related to the Tactile Internet.=20 Apart from that, I wonder about the degree of dynamicity that you foresee i= n your scenarios (of Section 4)? The use case draft in the COIN RG (https:/= /datatracker.ietf.org/doc/draft-irtf-coinrg-use-cases/) outlines an enterta= inment use case with a personalized and interactive nature, where dynamic r= elations, e.g., between (parts of the) performers and (parts of the) audien= ce are foreseen. The tactile notion is not emphasized here, leading to high= er acceptable latencies maybe (although when mixing distributed music, you = are still down at few ms latency). But it's the dynamic relations that I wa= nted to point out, which pose additional requirements. This may also be the= case for industrial use cases, BTW. Maybe something to consider as a possi= ble dimension? Best, Dirk -----Original Message----- From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Chathura Sar= athchandra Sent: 25 June 2021 15:49 To: int-area@ietf.org Cc: Mona Ghassemian Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-ta= ctile-internet-00.txt Dear all, Please find below our new draft submission on Tactile Internet Service Requ= irements. This draft introduces tactile internet use cases and service requirements p= otentially to be used as input for further discussions and/or to be directl= y addressed by IETF. Comments and feedback are warmly welcome! Best regards, Chathura -----Original Message----- From: internet-drafts@ietf.org =20 Sent: 25 June 2021 14:28 To: Chathura Sarathchandra ; Mona = Ghassemian ; Morteza Kheirkhah Subject: New Version Notification for draft-sarathchandra-tactile-internet-= 00.txt =20 A new version of I-D, draft-sarathchandra-tactile-internet-00.txt has been successfully submitted by Chathura Sarathchandra and posted to the= IETF repository. Name: draft-sarathchandra-tactile-internet Revision: 00 Title: Tactile Internet Service Requirements Document date: 2021-06-25 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-sarathchandra-tactile= -internet-00.txt Status: https://datatracker.ietf.org/doc/draft-sarathchandra-tactil= e-internet/ Htmlized: https://datatracker.ietf.org/doc/html/draft-sarathchandra-t= actile-internet Abstract: The Tactile Internet refers to a new communication and networking paradigm, which can provide low-latency, reliable and secure transmission for real-time information such as control, touch, and sensing/actuation in emerging tactile internet applications like teleoperation, immersive virtual reality,and haptics communications. The main goal of this document is: 1) to briefly introduce tactile internet background and typical applications; 2) to identify potential service requirements that can be addressed at the IETF or researched at the IRTF. = =20 The IETF Secretariat _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From nobody Mon Jun 28 11:46:19 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8A53A003D; Mon, 28 Jun 2021 11:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 o1SB6HfZNnJa; Mon, 28 Jun 2021 11:46:15 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE253A0035; Mon, 28 Jun 2021 11:46:14 -0700 (PDT) Received: by clarinet.employees.org (Postfix, from userid 1736) id A95004E11DAB; Mon, 28 Jun 2021 18:46:13 +0000 (UTC) Date: Mon, 28 Jun 2021 19:46:13 +0100 From: Derek Fawcus To: pals@ietf.org, intarea IETF list Message-ID: References: <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> <3421c34d-0fba-df94-89a3-64abdc325633@bobbriscoe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 18:46:18 -0000 On Mon, Jun 28, 2021 at 09:39:34AM +0100, Bob Briscoe wrote: > > My attempt to generalize this UK-specific knowledge: No-one is going to > add sequencing without a reason, and the only possible reason mentioned > so far would be stateful compression, which these days would just slow > things down more than the bandwidth saved. I also mentioned PWE fragmentation - rfc4623 - it depends upon the sequence numbers as a fragment identifier. So depending upon how it is implemented, it may implicitly turn on sequencing, without the user knowing. So the related question then becomes, where is that fragmentation support being used - if anywhere? DF From nobody Tue Jun 29 02:23:46 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CB13A2CA1 for ; Tue, 29 Jun 2021 02:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 fjaUX9uRGWDs for ; Tue, 29 Jun 2021 02:23:41 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A438E3A2C2B for ; Tue, 29 Jun 2021 02:23:40 -0700 (PDT) Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GDf070swbz6GBWB; Tue, 29 Jun 2021 17:13:11 +0800 (CST) Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 29 Jun 2021 11:23:32 +0200 Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 29 Jun 2021 10:23:31 +0100 Received: from lhreml701-chm.china.huawei.com ([10.201.68.196]) by lhreml701-chm.china.huawei.com ([10.201.68.196]) with mapi id 15.01.2176.012; Tue, 29 Jun 2021 10:23:31 +0100 From: Dirk Trossen To: Chathura Sarathchandra , "int-area@ietf.org" , "SARAH@JISCMAIL.AC.UK" CC: Mona Ghassemian , Morteza Kheirkhah , Renan Krishna Thread-Topic: New Version Notification for draft-sarathchandra-tactile-internet-00.txt Thread-Index: AQHXacXun8coZuugR0y9pKos1Zgwm6skuH8QgAAMVbCABFuL4IABmYPg Date: Tue, 29 Jun 2021 09:23:31 +0000 Message-ID: <655c3a34235344149ebb4aa89a233c22@huawei.com> References: <162462768163.24598.6490283884737670168@ietfa.amsl.com> <1731b19a3f3a448cb8e5fb865866547a@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.210.166.157] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-tactile-internet-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 09:23:46 -0000 Hi Chathura, Please see inline. I'm also CCing the SARAH list where some members may hav= e comments on this draft, too.=20 Best, Dirk -----Original Message----- From: Chathura Sarathchandra [mailto:Chathura.Sarathchandra@interdigital.co= m]=20 Sent: 28 June 2021 18:26 To: Dirk Trossen ; int-area@ietf.org Cc: Mona Ghassemian ; Morteza Kheirkhah <= Morteza.Kheirkhah@InterDigital.com>; Renan Krishna Subject: RE: New Version Notification for draft-sarathchandra-tactile-inter= net-00.txt Hi Dirk, Thanks for the suggested additional dimension for the use cases. The use c= ase referenced is an interesting one indeed (user interactivity and persona= lization added on top of https://www.kcl.ac.uk/news/the-worlds-first-5g-low= -latency-3-way-distributed-orchestra-at-kcl)!=20 [DOT] AFAIK the KCL demonstration was focused on audio sync, not haptic. Could not find a link however to haptic communication aspect. Maybe can pro= vide a haptic experience that is in sync with music for users who are disab= led and can't perceive audio and/or video? [DOT] The COIN RG case does not talk about haptics, specifically. But it's = mainly linked into music and theatre performance but more 'haptic performan= ces' could be in scope, too. By dynamicity do you mean how different user profiles and user interactions= are taken into consideration, in multi-user scenarios? And how the resulti= ng user-specific information (of the same experience) being transferred to = users (audio-video-haptic) ? If yes, certainly it is another dimension of = the use cases, e.g., Entertainment (gaming), Training (training simulations= ). For example, in scenarios where virtual simulation environments used for= training, where multiple users act upon the same virtual objects, the info= rmation received by individual 'trainee users' may differ due to 1) user pr= eferences (e.g., with haptic feedback vs without) 2) individual user's perc= eption (e.g.., audio, video haptic) of objects and actions/events within th= e virtual environment (e.g., based on viewpoint, distance to objects/events= , and properties of virtual objects [different users may receive different = haptic feedback depending on the type of actions performed], experiences ma= y differ per each user). Moreover, the trainer (human or virtual) may choos= e to provide corresponding feedback (using audio-visual or audio-visual-hap= tic mediums) to an individual or a group/subset of trainees in real-time. S= uch an experience must be provided while meeting stringent latency requirem= ents imposed by haptic. We may add the aforementioned aspects related to dy= namicity into the use cases in the next version of the draft. [DOT] Indeed, it's the dynamics of user interactions, particularly when mov= ing towards multi-modal interactions; surely this will depend on the intend= ed dynamicity of the interaction as well (e.g., going beyond lecture style = of interaction). This also may bring in aspects of multi-flow synchronizati= on, which need to be coordinated, too.=20 Best regards, Chathura -----Original Message----- From: Dirk Trossen Sent: 25 June 2021 15:21 To: Chathura Sarathchandra ; int-a= rea@ietf.org Cc: Mona Ghassemian Subject: RE: New Version Notification for draft-sarathchandra-tactile-inter= net-00.txt =20 Hi Chathura, Interesting draft, indeed, to start a discussion here on this list. Adrian'= s responded with a piece I'd also recommended, namely the SARAH list, where= this contribution may well contribute to possible discussions on addressin= g and routing aspects related to the Tactile Internet. Apart from that, I wonder about the degree of dynamicity that you foresee i= n your scenarios (of Section 4)? The use case draft in the COIN RG (https:/= /datatracker.ietf.org/doc/draft-irtf-coinrg-use-cases/) outlines an enterta= inment use case with a personalized and interactive nature, where dynamic r= elations, e.g., between (parts of the) performers and (parts of the) audien= ce are foreseen. The tactile notion is not emphasized here, leading to high= er acceptable latencies maybe (although when mixing distributed music, you = are still down at few ms latency). But it's the dynamic relations that I wa= nted to point out, which pose additional requirements. This may also be the= case for industrial use cases, BTW. Maybe something to consider as a possi= ble dimension? Best, Dirk -----Original Message----- From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Chathura Sar= athchandra Sent: 25 June 2021 15:49 To: int-area@ietf.org Cc: Mona Ghassemian Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-ta= ctile-internet-00.txt Dear all, Please find below our new draft submission on Tactile Internet Service Requ= irements. This draft introduces tactile internet use cases and service requirements p= otentially to be used as input for further discussions and/or to be directl= y addressed by IETF. Comments and feedback are warmly welcome! Best regards, Chathura -----Original Message----- From: internet-drafts@ietf.org Sent: 25 June 2021 14:28 To: Chathura Sarathchandra ; Mona = Ghassemian ; Morteza Kheirkhah Subject: New Version Notification for draft-sarathchandra-tactile-internet-= 00.txt A new version of I-D, draft-sarathchandra-tactile-internet-00.txt has been successfully submitted by Chathura Sarathchandra and posted to the= IETF repository. Name: draft-sarathchandra-tactile-internet Revision: 00 Title: Tactile Internet Service Requirements Document date: 2021-06-25 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/archive/id/draft-sarathchandra-tactile= -internet-00.txt Status: https://datatracker.ietf.org/doc/draft-sarathchandra-tactil= e-internet/ Htmlized: https://datatracker.ietf.org/doc/html/draft-sarathchandra-t= actile-internet Abstract: The Tactile Internet refers to a new communication and networking paradigm, which can provide low-latency, reliable and secure transmission for real-time information such as control, touch, and sensing/actuation in emerging tactile internet applications like teleoperation, immersive virtual reality,and haptics communications. The main goal of this document is: 1) to briefly introduce tactile internet background and typical applications; 2) to identify potential service requirements that can be addressed at the IETF or researched at the IRTF. The IETF Secretariat _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area [Banner] [Banner] Sustainability in a Wireless World: Research dedicated to understanding the= impact of our technologies on the planet. This e-mail is intended only for the use of the individual or entity to whi= ch it is addressed, and may contain information that is privileged, confide= ntial and/or otherwise protected from disclosure to anyone other than its i= ntended recipient. Unintended transmission shall not constitute waiver of a= ny privilege or confidentiality obligation. If you received this communicat= ion in error, please do not review, copy or distribute it, notify me immedi= ately by email, and delete the original message and any attachments. Unless= expressly stated in this e-mail, nothing in this message or any attachment= should be construed as a digital or electronic signature. From nobody Tue Jun 29 03:02:20 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2489C3A2DDF; Tue, 29 Jun 2021 03:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 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.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 6LMBSzOnWMvs; Tue, 29 Jun 2021 03:02:12 -0700 (PDT) Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 DD5643A2DC7; Tue, 29 Jun 2021 03:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4loFXTfG7kU/dhq4G2P1TRnFgnKt6nRUcvnHx3UNp0k=; b=4H+qjGdyvsBSn5ipebZdFybK10 4fpZzfQ+vnouVznsrf3eMURKyET9/lxrQbsvbdOhOtE74xWXhY5jH6Bre2seq9+N7dAIA86Sj9nyq 5+g10WmuDnUtpT2EtcOgLvXhyz1tD2tBJrjYjfh7xd099MS9pllRafZzvj9ssRi0qkJdhvE7r1hxg 95ohRRE3irM8IKeHgR+KuhlMP3nSjlBZ4aYVGJqEp55pyB/XifM2bCM3mEcIQQAziYFhjJlAIcWR2 zVGbgmg1U8eMXp0bvgxqlQRv8/X9dMKFiIKTqGD7XCTugpi/DZqvs6NQW9yQOj7xwoVVal/hhTqFR g/nAJl/g==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:43374 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lyAZH-0001fJ-Hc; Tue, 29 Jun 2021 11:02:09 +0100 To: tom petch , intarea IETF list , "pals@ietf.org" References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> <3421c34d-0fba-df94-89a3-64abdc325633@bobbriscoe.net> From: Bob Briscoe Message-ID: <055fc148-ce81-d548-a5f6-90e4bc353171@bobbriscoe.net> Date: Tue, 29 Jun 2021 11:02:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 10:02:19 -0000 Tom, see [BB2] On 28/06/2021 09:41, tom petch wrote: > > > From: Int-area on behalf of Bob Briscoe > Sent: 27 June 2021 22:22 > > James, > > [First apologies to everyone for asking the question then not following > up on the answers until now - I went off line for a while.] > See inline tagged [BB]... > > On 10/06/2021 13:09, James Bensley wrote: >> On Wed, 9 Jun 2021 at 15:57, Derek Fawcus >> wrote: >>> On Wed, Jun 09, 2021 at 03:07:41PM +0200, James Bensley wrote: >>>> On Wed, 9 Jun 2021 at 14:05, Giles Heron wrote: >>>>> Re BT specifically (and again my info is outdated and may be mis-remembered) the 20C network used L2TP, and I think its an option on 21C for handoff to smaller ISPs. Should all be in the SINs somewhere? >>>> I work in the UK ISP sector. I can confirm that L2TP is in wide spread >>>> use for wholesale services by all major ISPs (except Liberty). I think >>>> the real question here (unless I've misunderstood) is not "is L2TP >>>> being used" but "is L2TP being used AND sequencing is being used >>>> and/or enforced?" - is that understanding correct? >>> Yes. >> In that case - sequencing isn't used for BT Wholesale services. > [BB] Thank you. It sounds like you have some reason for your certainty > here. Can you elaborate on what makes you so certain sequencing isn't used? > > > > Perhaps a coincidence or perhaps not, but an I-D has just been posted > Author : Yogesh Nautiyal > Filename : draft-nautiyal-l2tpext-tunnel-ka-control-channel-00.txt > which uses L2TP sequencing, I note the author has an affiliation of Juniper. [BB] Thanks for pointing this out. It's quite normal and expected for L2TP to use its sequencing facility for a control channel. I'm not concerned about that. My original question was scoped to IP as data. But thanks anyway. Cheers Bob > > The draft would need a fair bit of work. > > Tom Petch > > Bob > >> Cheers, >> James. >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Tue Jun 29 03:24:09 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A983A2EAC; Tue, 29 Jun 2021 03:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 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.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 c6niWXDUuwSw; Tue, 29 Jun 2021 03:24:03 -0700 (PDT) Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 08C783A2EAB; Tue, 29 Jun 2021 03:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8EtCMSYvZbZHs+QGt9rDH4wqw0B6pzZttQD/o01/jnw=; b=8kZ8nV2DG3ZMEF3KEZ+Es4GF2q PH9zWi+Wk2T4RNbMtgNioTWOJXOCVXgUVbHys9+Q0k59lmTUnSzDqQWi/iJAKVFsggwyP3sZA8NHd hgV2cqbAmIDKMcr7tQ+ofcPf/MTWTbH+9U9RegkKEifQ9a67mW7vEzioB8QxgAZ+bDQ9xP14gC78G jCdE9MUr76JXDPTGY2W5BWM30S6r1eOX/ol3+IVHPoS5o5lNWSmD44mwdYRQNkGXTqVMpIH0mpwxH Llm3GUhtQwGyZs3/OgSnKW7Z7XBUv483AU8bd2zV444JGeROI576B9YHUWAI3/Qgyam6K8kGwcynU 6WZ2hpWA==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:43528 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lyAuR-0002u9-0W; Tue, 29 Jun 2021 11:24:01 +0100 To: Derek Fawcus , pals@ietf.org, intarea IETF list References: <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <881FF4F8-27BA-4B58-B54E-68F3811BE1D4@layerfree.net> <3421c34d-0fba-df94-89a3-64abdc325633@bobbriscoe.net> From: Bob Briscoe Message-ID: <5b228077-d80a-4214-713d-d78b38d3fac1@bobbriscoe.net> Date: Tue, 29 Jun 2021 11:23:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 10:24:08 -0000 Derek, On 28/06/2021 19:46, Derek Fawcus wrote: > On Mon, Jun 28, 2021 at 09:39:34AM +0100, Bob Briscoe wrote: >> My attempt to generalize this UK-specific knowledge: No-one is going to >> add sequencing without a reason, and the only possible reason mentioned >> so far would be stateful compression, which these days would just slow >> things down more than the bandwidth saved. > I also mentioned PWE fragmentation - rfc4623 - it depends upon the sequence > numbers as a fragment identifier. So depending upon how it is implemented, > it may implicitly turn on sequencing, without the user knowing. > > So the related question then becomes, where is that fragmentation support > being used - if anywhere? [BB] Sorry, I omitted to explain that, in the PWE case, I didn't think differential delay would be a problem, because all traffic in the PWE would be expected to want the same low delay service. My concern was about sequencing of tunnelled packets undoing deliberately differentiated delay between different types of IP traffic within an aggregate. But thanks for picking me up on not explaining that. Cheers Bob > > DF > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Tue Jun 29 04:41:27 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6143A3128; Tue, 29 Jun 2021 04:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 68Zdrdt377An; Tue, 29 Jun 2021 04:41:19 -0700 (PDT) Received: from layerfree.net (heronab2.miniserver.com [89.200.138.104]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B443A312B; Tue, 29 Jun 2021 04:41:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)); envelope-from=173.38.220.34; From: Giles Heron Message-Id: <4823D617-4DF2-4F8B-BBAD-382910D309CF@layerfree.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_AF6FE63A-D69E-4A9C-A1AF-296287C728AF" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 29 Jun 2021 12:41:08 +0100 In-Reply-To: <7c89b2b3-1576-bdec-c2d5-64393f27f7bf@bobbriscoe.net> Cc: Mark Townsley , Carlos Pignataro , intarea IETF list , pals@ietf.org, "Andrew G. Malis" To: Bob Briscoe References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com> <50ADB293-A7EC-4574-9430-43E68073A6D1@townsley.net> <4AC24C92-DD6C-4D5E-B113-0123DFD842A5@layerfree.net> <7c89b2b3-1576-bdec-c2d5-64393f27f7bf@bobbriscoe.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-IP-stats: Incoming Last 92, First 91, in=1, out=0, spam=0 ip=HiddenIP Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 11:41:24 -0000 --Apple-Mail=_AF6FE63A-D69E-4A9C-A1AF-296287C728AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bob, > On 28 Jun 2021, at 00:23, Bob Briscoe wrote: >=20 > Giles, Mark, >=20 > On 10/06/2021 13:22, Giles Heron wrote: >> So AFAIK SP networks don=E2=80=99t generally reorder packets in the = steady state, but of course reordering can occur under rerouting. >=20 > [BB] The cases I'm concerned about are where the operator > * deliberately reorders packets using a multi-queue scheduler at a = node contrived to act as the bottleneck (the BNG) > * AND the node is within an L2TPv2/3 tunnel=20 > * AND the tunnel needs sequencing at the egress for some other reason.=20= If that=E2=80=99s the case then the node almost certainly won=E2=80=99t = re-order packets within the tunnel, even if it is deliberately = reordering packets between clients. As far as the node is concerned the = L2TPv3 tunnel is one flow within one subscriber=E2=80=99s traffic. BNG = reordering is generally between subscribers (e.g. where subscribers get = serviced round-robin to ensure fairness), or potentially within classes = of service per subscriber (e.g. strict priority for on-net voice and = IPTV over Internet traffic). >=20 > In many cases, such a scheduler would be located prior to the tunnel = ingress, so not a concern. I believe the DOCSIS rPHY case below falls = into that category (both downstream and up). Agreed >=20 > In contrast, where a BNG sits /within/ the span of an L2TP tunnel, I = think it will often (or at least sometimes?) have been constructed as = the bottleneck. Any operator having designed such a QoS arrangement = would not want to support sequencing... Yes, BNGs are often planned to be the bottleneck. But as I say that=E2=80= =99s about fairness between subscribers and potentially prioritising = different traffic for each subscriber. >> As noted by Derek I=E2=80=99m guessing reordering is an issue for = L2TPv2 if stateful PPP compression schemes are in play (which I suspect = is unlikely to be the case given we usually have abundant bandwidth in = the aggregation network, and given that compression can occur at other = layers). Though given that BNGs inherently keep state per subscriber = maybe the NPU scaling issues that Stewart mentioned are less of an issue = in that use case than for MPLS PEs doing PWE? >=20 > My concern was that 'keep it simple' operators that are using L2TPv2/3 = and had not previously bothered with the complexities of QoS might want = to support L4S, because it has the potential to cut out queue delay for = /all/ traffic. Altho' L4S is eventually for all traffic, it still = requires two queues at the bottleneck for transition - one for L4S and = one for not-yet-L4S ('Classic') traffic flows, and therefore introduces = reordering at the aggregate level... Again I presume any single tunnel being passed *through* a BNG would = either be L4S or not-yet-L4S, and hence not subject to reordering? Giles >=20 > =46rom the replies so far, even if such 'keep it simple' operators = were using compression, I can't see any reason why having to turn off = compression and sequencing (in order to support L4S) would be a = significant problem nowadays. >=20 > So, in conclusion, I don't think we even need to raise any concerns = about L2TP sequencing in the L4S specs. >=20 > If anyone here thinks otherwise, pls speak now. >=20 > Thank you everyone who has contributed to this discussion. >=20 > Cheers >=20 >=20 >=20 > Bob >=20 >=20 >=20 >>=20 >> =46rom a quick look at the DOCSIS rPHY specs it seems they do require = support for L2TPv3 sequence numbers. Of course in that case the payload = is the DOCSIS MAC rather than IP (even though, of course, most DOCSIS = frames ultimately carry an IP payload). >>=20 >> Giles >>=20 >>> On 10 Jun 2021, at 12:49, Andrew G. Malis > wrote: >>>=20 >>> (resending with cc: list trimmed to pass the too many recipients = filter) >>> Mark, >>>=20 >>> The original question was, how many (if any) of these L2TPv2 and v3 = use cases use sequencing, especially when carrying IP? >>>=20 >>> Cheers, >>> Andy >>>=20 >>> On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley > wrote: >>> Hi folks, >>>=20 >>> In addition to the DSL arena, L2TP is still in use with host-based = VPN clients as it is embedded in Apple, Android, and Windows based = operating systems (new and old). Despite most VPN solutions preferring = their own client software that must be installed on hosts to operate, = there are still admins that appreciate not having to ask their employees = to download an app for the VPN to work - in which case PPTP and L2TP = with transport-mode IPsec are your most widely available options.=20 >>>=20 >>> Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. = L2TPv3 generalized L2TP to support other L2 (including MPLS, but I = don=E2=80=99t want to argue what layer MPLS operates within here). There = was never a strong push to replace L2TPv2 used in DSL, Dialup and host = VPN software with L2TPv3 (there was one use case for an important L2TP = operator that wanted to carry PPPoE over L2TPv3 in DSL, but that was = overcome by RFC3817 which achieved the same goal without altering the = dataplane). Ironically, I would expect to see very little PPP over = L2TPv3 in the wild, though obviously it is possible. >>>=20 >>> In the cable broadband world, the DOCSIS DEPI =E2=80=9CRemote PHY=E2=80= =9D specification (similar I suppose to the split BNG spec Joel is = referring to) standardized on L2TPv3 and is in active use. >>>=20 >>> I also know of at least one vendor that uses Ethernet over L2TPv3 = for some wifi backhaul use cases.=20 >>>=20 >>> There could be more, this is just what I am personally aware of off = the top of my head. Even I am surprised to see how much L2TP is still = out there once you start really looking around ;-) >>>=20 >>> Best Regards, >>>=20 >>> - Mark >>>=20 >>>=20 >>>=20 >>>=20 >>> > On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct = > wrote: >>> >=20 >>> > 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. >>> >=20 >>> > Yours, >>> > Joel >>> >=20 >>> > 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 > wrote: >>> >>>=20 >>> >>> There is plenty of L2TP still in use. >>> >>> Yours, >>> >>> Joel >>> >>>=20 >>> >>> 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 >> wrote: >>> >>>>>=20 >>> >>>>> Bob, >>> >>>>>=20 >>> >>>>> 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 :-). >>> >>>>>=20 >>> >>>>> 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. >>> >>>>>=20 >>> >>>>> 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. >>> >>>>>=20 >>> >>>>> Cheers, >>> >>>>> Andy >>> >>>>>=20 >>> >>>>>=20 >>> >>>>> On Sat, Jun 5, 2021 at 10:07 AM Derek Fawcus = = >> wrote: >>> >>>>>=20 >>> >>>>> 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? >>> >>>>>=20 >>> >>>>> How many intermediate headers are you considering between = L2TP and >>> >>>>> where >>> >>>>> a carried IP header may exist? >>> >>>>>=20 >>> >>>>> Maybe I'm getting the wrong end of the stick, but surely = this engages >>> >>>>> the text from section 5.4 of RFC 2661: >>> >>>>>=20 >>> >>>>> "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." >>> >>>>>=20 >>> >>>>> 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. >>> >>>>>=20 >>> >>>>> So such an L2TP data session may well make use of sequence = numbers to >>> >>>>> prevent reordering. >>> >>>>>=20 >>> >>>>> 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. >>> >>>>>=20 >>> >>>>>=20 >>> >>>>> DF >>> >>>>>=20 >>> >>>>> (not an operator) >>> >>>>>=20 >>> >>>>> _______________________________________________ >>> >>>>> Int-area mailing list >>> >>>>> Int-area@ietf.org = > >>> >>>>> https://www.ietf.org/mailman/listinfo/int-area = >>> >>>>> > >>> >>>>>=20 >>> >>>>> _______________________________________________ >>> >>>>> 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 = >>>=20 >>> _______________________________________________ >>> Pals mailing list >>> Pals@ietf.org >>> https://www.ietf.org/mailman/listinfo/pals = >>=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ = --Apple-Mail=_AF6FE63A-D69E-4A9C-A1AF-296287C728AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Bob,

On 28 Jun 2021, at 00:23, Bob Briscoe <ietf@bobbriscoe.net>= wrote:

=20 =20
Giles, Mark,

On 10/06/2021 13:22, Giles Heron = wrote:
So AFAIK SP networks don=E2=80=99t generally = reorder packets in the steady state, but of course reordering can occur under rerouting.

[BB] The cases I'm concerned about are where the operator
* deliberately reorders packets using a multi-queue scheduler at a node contrived to act as the bottleneck (the BNG)
* AND the node is within an L2TPv2/3 tunnel
* AND the tunnel needs sequencing at the egress for some other reason. 

If = that=E2=80=99s the case then the node almost certainly won=E2=80=99t = re-order packets within the tunnel, even if it is deliberately = reordering packets between clients.  As far as the node is = concerned the L2TPv3 tunnel is one flow within one subscriber=E2=80=99s = traffic.   BNG reordering is generally between subscribers (e.g. = where subscribers get serviced round-robin to ensure fairness), or = potentially within classes of service per subscriber (e.g. strict = priority for on-net voice and IPTV over Internet traffic).


In many cases, such a scheduler would be located prior to the tunnel ingress, so not a concern. I believe the DOCSIS rPHY case below falls into that category (both downstream and up).

Agreed


In contrast, where a BNG sits /within/ the span of an L2TP tunnel, I think it will often (or at least sometimes?) have been constructed as the bottleneck. Any operator having designed such a QoS arrangement would not want to support sequencing...

Yes, BNGs = are often planned to be the bottleneck.  But as I say that=E2=80=99s = about fairness between subscribers and potentially prioritising = different traffic for each subscriber.

=20
As noted by Derek I=E2=80=99m guessing reordering = is an issue for L2TPv2 if stateful PPP compression schemes are in play (which I suspect is unlikely to be the case given we usually have abundant bandwidth in the aggregation network, and given that compression can occur at other layers).  Though given = that BNGs inherently keep state per subscriber maybe the NPU scaling issues that Stewart mentioned are less of an issue in that use case than for MPLS PEs doing PWE?

My concern was that 'keep it simple' operators that are using L2TPv2/3 and had not previously bothered with the complexities of QoS might want to support L4S, because it has the potential to cut out queue delay for /all/ traffic. Altho' L4S is eventually for all traffic, it still requires two queues at the bottleneck for transition - one for L4S and one for not-yet-L4S ('Classic') traffic flows, and therefore introduces reordering at the aggregate level...
Again I presume any single tunnel being passed = *through* a BNG would either be L4S or not-yet-L4S, and hence not = subject to reordering?

Giles


=46rom the replies so far, even if such 'keep it simple' operators were using compression, I can't see any reason why having to turn off compression and sequencing (in order to support L4S) would be a significant problem nowadays.

So, in conclusion, I don't think we even need to raise any concerns about L2TP sequencing in the L4S specs.

If anyone here thinks otherwise, pls speak now.

Thank you everyone who has contributed to this discussion.

Cheers



Bob




=46rom a quick look at the DOCSIS rPHY specs it = seems they do require support for L2TPv3 sequence numbers.  Of = course in that case the payload is the DOCSIS MAC rather than IP (even though, of course, most DOCSIS frames ultimately carry an IP payload).

Giles

On 10 Jun 2021, at 12:49, Andrew G. Malis = <agmalis@gmail.com> wrote:

(resending with cc: list trimmed = to pass the too many recipients filter)
Mark,

The original question was, = how many (if any) of these L2TPv2 and v3 use cases use sequencing, especially when carrying IP?

Cheers,
Andy

On Wed, Jun 9, 2021 = at 6:32 PM Mark Townsley <mark@townsley.net> wrote:
Hi folks,

In addition to the DSL arena, L2TP is still in use with host-based VPN clients as it is embedded in Apple, Android, and Windows based operating systems (new and old). Despite most VPN solutions preferring their own client software that must be installed on hosts to operate, there are still admins that appreciate not having to ask their employees to download an app for the VPN to work - in which case PPTP and L2TP with transport-mode IPsec are your most widely available options.

Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. L2TPv3 generalized L2TP to support other L2 (including MPLS, but I don=E2=80=99t want to argue what = layer MPLS operates within here). There was never a strong push to replace L2TPv2 used in DSL, Dialup and host VPN software with L2TPv3 (there was one use case for an important L2TP operator that wanted to carry PPPoE over L2TPv3 in DSL, but that was overcome by RFC3817 which achieved the same goal without altering the dataplane). Ironically, I would expect to see very little PPP over L2TPv3 in the wild, though obviously it is possible.

In the cable broadband world, the DOCSIS DEPI =E2=80=9CRem= ote PHY=E2=80=9D specification (similar I suppose to the = split BNG spec Joel is referring to) standardized on L2TPv3 and is in active use.

I also know of at least one vendor that uses Ethernet over L2TPv3 for some wifi backhaul use cases.

There could be more, this is just what I am personally aware of off the top of my head. Even I am surprised to see how much L2TP is still out there once you start really looking around ;-)

Best Regards,

- Mark




> On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct <jmh.direct@joelhalpern.com> wrote:
>
> 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

_______________________________________________
= Pals mailing list
Pals@ietf.org
https://www.ietf.org/m= ailman/listinfo/pals


--=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

= --Apple-Mail=_AF6FE63A-D69E-4A9C-A1AF-296287C728AF-- From nobody Tue Jun 29 08:09:24 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAE43A3720 for ; Tue, 29 Jun 2021 08:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 knOg97w_zeeb for ; Tue, 29 Jun 2021 08:09:17 -0700 (PDT) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0503A371D for ; Tue, 29 Jun 2021 08:09:16 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id p22so11671151yba.7 for ; Tue, 29 Jun 2021 08:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=32KSo0i9O8eCQDHkBRAlRhJPNOJmXNYlYy93DYWr8fQ=; b=A1KCUTWwu+SDDnpO+m85AnaBAAs5hmN2Npou964K7IRyqYeDiN5HlvlhTwsegHR8oR WptKr7RZb29AfVXC1EqiQr7lMU8Sb5DtActfC/CGaw04clEnY4cvLInyOooTVtuWVQ7C SPxRnshS1VBz/3jE5u6q8LEZZhznzIBxCZf4jx2mxjOKIJ+GNnu4VlDbJHSr+hfsB8dn i9i7ud7AzeTEHaqAZxjMmaq8LtQFpVALgx8kdUUZ9UOur11LbeJMkRye6g7MKMPCYCYI lxQ99T8O3eA421Msw3wnZLOI5jjrVBduU11Ixq5TZjL7Iit7GIUL3Lb2Jq8nREcpawDL q43g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=32KSo0i9O8eCQDHkBRAlRhJPNOJmXNYlYy93DYWr8fQ=; b=sRsXVQE9AW241OaKGR6ba5aFayQTfehdpF8ea6CXdSkxQgZMHVtesI9fZHoZPqaQYB K67v1k93PQCSS2uBD6BKWpKnAAhcKvFl9hc7SyWTtDF6dqxazDOLlWVtbwX3GujBd2iS tFNdJRoJpsj0aX0+XguLAUl6HNqWE0YtNb2Qs7+F2Z/lYM6TqNDkz3i0oUODsa0fCzq+ IVAcTYFK0VlHwKcBU2BB62ikWhYBG+b5uAz6wGjdf1CY/JGCePCNEsjX+uc532ni/dsS hIsSBo3c9fmbsu4Xer0ScAX9mAqQ7O/UL+Tm8P/KZ7mlfKjmVRqSyMNi9G23gLjNMsBG hcDQ== X-Gm-Message-State: AOAM533GNArhcrQmLfwtBVkMvM6NXNXNVY6oLZyN4lRYUIWU8IB69RSR kxNKltxMJHg1elGbv07mBEHJzsrJiFpauvwruLE= X-Google-Smtp-Source: ABdhPJwHtZgfbjveWE+m1hUlxVGExvwQdrv872tRuyWZbRMq8iy8HQMHsknIABTQX6GvK5okJAddUayQfzbMDl8GXOU= X-Received: by 2002:a25:1c1:: with SMTP id 184mr19281099ybb.175.1624979353200; Tue, 29 Jun 2021 08:09:13 -0700 (PDT) MIME-Version: 1.0 References: <162462768163.24598.6490283884737670168@ietfa.amsl.com> <1731b19a3f3a448cb8e5fb865866547a@huawei.com> <655c3a34235344149ebb4aa89a233c22@huawei.com> In-Reply-To: <655c3a34235344149ebb4aa89a233c22@huawei.com> Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Tue, 29 Jun 2021 10:09:02 -0500 Message-ID: To: Dirk Trossen Cc: Chathura Sarathchandra , "int-area@ietf.org" , "SARAH@JISCMAIL.AC.UK" , Mona Ghassemian Content-Type: multipart/alternative; boundary="0000000000001d7e8205c5e8fd59" Archived-At: Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-tactile-internet-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 15:09:22 -0000 --0000000000001d7e8205c5e8fd59 Content-Type: text/plain; charset="UTF-8" To Intarea chairs, I was glancing through the mails on this draft and related ones. It seems like the issue discussed is or very similar to those already being discussed in IRTF. So spend WG time on this? Behcet On Tue, Jun 29, 2021 at 4:23 AM Dirk Trossen wrote: > Hi Chathura, > > Please see inline. I'm also CCing the SARAH list where some members may > have comments on this draft, too. > > Best, > > Dirk > > -----Original Message----- > From: Chathura Sarathchandra [mailto: > Chathura.Sarathchandra@interdigital.com] > Sent: 28 June 2021 18:26 > To: Dirk Trossen ; int-area@ietf.org > Cc: Mona Ghassemian ; Morteza Kheirkhah > ; Renan Krishna > > Subject: RE: New Version Notification for > draft-sarathchandra-tactile-internet-00.txt > > Hi Dirk, > > Thanks for the suggested additional dimension for the use cases. The use > case referenced is an interesting one indeed (user interactivity and > personalization added on top of > https://www.kcl.ac.uk/news/the-worlds-first-5g-low-latency-3-way-distributed-orchestra-at-kcl)! > > [DOT] AFAIK the KCL demonstration was focused on audio sync, not haptic. > > Could not find a link however to haptic communication aspect. Maybe can > provide a haptic experience that is in sync with music for users who are > disabled and can't perceive audio and/or video? > [DOT] The COIN RG case does not talk about haptics, specifically. But it's > mainly linked into music and theatre performance but more 'haptic > performances' could be in scope, too. > > By dynamicity do you mean how different user profiles and user > interactions are taken into consideration, in multi-user scenarios? And how > the resulting user-specific information (of the same experience) being > transferred to users (audio-video-haptic) ? If yes, certainly it is > another dimension of the use cases, e.g., Entertainment (gaming), Training > (training simulations). For example, in scenarios where virtual simulation > environments used for training, where multiple users act upon the same > virtual objects, the information received by individual 'trainee users' may > differ due to 1) user preferences (e.g., with haptic feedback vs without) > 2) individual user's perception (e.g.., audio, video haptic) of objects and > actions/events within the virtual environment (e.g., based on viewpoint, > distance to objects/events, and properties of virtual objects [different > users may receive different haptic feedback depending on the type of > actions performed], experiences may differ per each user) > . Moreover, the trainer (human or virtual) may choose to provide > corresponding feedback (using audio-visual or audio-visual-haptic mediums) > to an individual or a group/subset of trainees in real-time. Such an > experience must be provided while meeting stringent latency requirements > imposed by haptic. We may add the aforementioned aspects related to > dynamicity into the use cases in the next version of the draft. > [DOT] Indeed, it's the dynamics of user interactions, particularly when > moving towards multi-modal interactions; surely this will depend on the > intended dynamicity of the interaction as well (e.g., going beyond lecture > style of interaction). This also may bring in aspects of multi-flow > synchronization, which need to be coordinated, too. > > Best regards, > Chathura > > -----Original Message----- > From: Dirk Trossen > Sent: 25 June 2021 15:21 > To: Chathura Sarathchandra ; > int-area@ietf.org > Cc: Mona Ghassemian > Subject: RE: New Version Notification for > draft-sarathchandra-tactile-internet-00.txt > > > > Hi Chathura, > > Interesting draft, indeed, to start a discussion here on this list. > Adrian's responded with a piece I'd also recommended, namely the SARAH > list, where this contribution may well contribute to possible discussions > on addressing and routing aspects related to the Tactile Internet. > > Apart from that, I wonder about the degree of dynamicity that you foresee > in your scenarios (of Section 4)? The use case draft in the COIN RG ( > https://datatracker.ietf.org/doc/draft-irtf-coinrg-use-cases/) outlines > an entertainment use case with a personalized and interactive nature, where > dynamic relations, e.g., between (parts of the) performers and (parts of > the) audience are foreseen. The tactile notion is not emphasized here, > leading to higher acceptable latencies maybe (although when mixing > distributed music, you are still down at few ms latency). But it's the > dynamic relations that I wanted to point out, which pose additional > requirements. This may also be the case for industrial use cases, BTW. > Maybe something to consider as a possible dimension? > > Best, > > Dirk > > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Chathura > Sarathchandra > Sent: 25 June 2021 15:49 > To: int-area@ietf.org > Cc: Mona Ghassemian > Subject: Re: [Int-area] New Version Notification for > draft-sarathchandra-tactile-internet-00.txt > > Dear all, > > Please find below our new draft submission on Tactile Internet Service > Requirements. > > This draft introduces tactile internet use cases and service requirements > potentially to be used as input for further discussions and/or to be > directly addressed by IETF. > > Comments and feedback are warmly welcome! > > Best regards, > Chathura > > -----Original Message----- > From: internet-drafts@ietf.org > Sent: 25 June 2021 14:28 > To: Chathura Sarathchandra ; > Mona Ghassemian ; Morteza Kheirkhah > > Subject: New Version Notification for > draft-sarathchandra-tactile-internet-00.txt > > > > A new version of I-D, draft-sarathchandra-tactile-internet-00.txt > has been successfully submitted by Chathura Sarathchandra and posted to > the IETF repository. > > Name: draft-sarathchandra-tactile-internet > Revision: 00 > Title: Tactile Internet Service Requirements > Document date: 2021-06-25 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/archive/id/draft-sarathchandra-tactile-internet-00.txt > Status: > https://datatracker.ietf.org/doc/draft-sarathchandra-tactile-internet/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-sarathchandra-tactile-internet > > > Abstract: > The Tactile Internet refers to a new communication and networking > paradigm, which can provide low-latency, reliable and secure > transmission for real-time information such as control, touch, and > sensing/actuation in emerging tactile internet applications like > teleoperation, immersive virtual reality,and haptics communications. > The main goal of this document is: 1) to briefly introduce tactile > internet background and typical applications; 2) to identify > potential service requirements that can be addressed at the IETF or > researched at the IRTF. > > > > > The IETF Secretariat > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > > [Banner] > > [Banner]< > https://www.interdigital.com/features/sustainability-in-a-wireless-world> > > Sustainability in a Wireless World: Research dedicated to understanding > the impact of our technologies on the planet.< > https://www.interdigital.com/features/sustainability-in-a-wireless-world> > This e-mail is intended only for the use of the individual or entity to > which it is addressed, and may contain information that is privileged, > confidential and/or otherwise protected from disclosure to anyone other > than its intended recipient. Unintended transmission shall not constitute > waiver of any privilege or confidentiality obligation. If you received this > communication in error, please do not review, copy or distribute it, notify > me immediately by email, and delete the original message and any > attachments. Unless expressly stated in this e-mail, nothing in this > message or any attachment should be construed as a digital or electronic > signature. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > --0000000000001d7e8205c5e8fd59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To Intarea chairs,

I was glancing throu= gh the mails on this draft and related ones.
It seems like the is= sue discussed is or very similar to those already being discussed in IRTF.<= /div>
So spend WG time on this?

Behcet

On= Tue, Jun 29, 2021 at 4:23 AM Dirk Trossen <dirk.trossen@huawei.com> wrote:
Hi Chathura,

Please see inline. I'm also CCing the SARAH list where some members may= have comments on this draft, too.

Best,

Dirk

-----Original Message-----
From: Chathura Sarathchandra [mailto:Chathura.Sarathchandra@interdigital.= com]
Sent: 28 June 2021 18:26
To: Dirk Trossen <dirk.trossen@huawei.com>; int-area@ietf.org
Cc: Mona Ghassemian <Mona.Ghassemian@InterDigital.com>; Morteza Kheir= khah <Morteza.Kheirkhah@InterDigital.com>; Renan Krishna <Renan.Kr= ishna@InterDigital.com>
Subject: RE: New Version Notification for draft-sarathchandra-tactile-inter= net-00.txt

Hi Dirk,

Thanks for the suggested additional dimension for the use cases.=C2=A0 The = use case referenced is an interesting one indeed (user interactivity and pe= rsonalization added on top of https://www.kcl.ac.uk/news/the-worlds-first-5g-low-l= atency-3-way-distributed-orchestra-at-kcl)!
[DOT] AFAIK the KCL demonstration was focused on audio sync, not haptic.
Could not find a link however to haptic communication aspect. Maybe can pro= vide a haptic experience that is in sync with music for users who are disab= led and can't perceive audio and/or video?
[DOT] The COIN RG case does not talk about haptics, specifically. But it= 9;s mainly linked into music and theatre performance but more 'haptic p= erformances' could be in scope, too.

By dynamicity do you mean how different user profiles and user interactions= are taken into consideration, in multi-user scenarios? And how the resulti= ng user-specific information (of the same experience) being transferred to = users=C2=A0 (audio-video-haptic) ? If yes, certainly it is another dimensio= n of the use cases, e.g., Entertainment (gaming), Training (training simula= tions). For example, in scenarios where virtual simulation environments use= d for training, where multiple users act upon the same virtual objects, the= information received by individual 'trainee users' may differ due = to 1) user preferences (e.g., with haptic feedback vs without) 2) individua= l user's perception (e.g.., audio, video haptic) of objects and actions= /events within the virtual environment (e.g., based on viewpoint, distance = to objects/events, and properties of virtual objects [different users may r= eceive different haptic feedback depending on the type of actions performed= ], experiences may differ per each user)
=C2=A0. Moreover, the trainer (human or virtual) may choose to provide corr= esponding feedback (using audio-visual or audio-visual-haptic mediums) to a= n individual or a group/subset of trainees in real-time. Such an experience= must be provided while meeting stringent latency requirements imposed by h= aptic. We may add the aforementioned aspects related to dynamicity into the= use cases in the next version of the draft.
[DOT] Indeed, it's the dynamics of user interactions, particularly when= moving towards multi-modal interactions; surely this will depend on the in= tended dynamicity of the interaction as well (e.g., going beyond lecture st= yle of interaction). This also may bring in aspects of multi-flow synchroni= zation, which need to be coordinated, too.

Best regards,
Chathura

-----Original Message-----
From: Dirk Trossen <dirk.trossen@huawei.com>
Sent: 25 June 2021 15:21
To: Chathura Sarathchandra <Chathura.Sarathchandra@interdigital.com>; int-area@ietf= .org
Cc: Mona Ghassemian <Mona.Ghassemian@InterDigital.com>
Subject: RE: New Version Notification for draft-sarathchandra-tactile-inter= net-00.txt



Hi Chathura,

Interesting draft, indeed, to start a discussion here on this list. Adrian&= #39;s responded with a piece I'd also recommended, namely the SARAH lis= t, where this contribution may well contribute to possible discussions on a= ddressing and routing aspects related to the Tactile Internet.

Apart from that, I wonder about the degree of dynamicity that you foresee i= n your scenarios (of Section 4)? The use case draft in the COIN RG (https://datatracker.ietf.org/doc/draft-irtf-co= inrg-use-cases/) outlines an entertainment use case with a personalized= and interactive nature, where dynamic relations, e.g., between (parts of t= he) performers and (parts of the) audience are foreseen. The tactile notion= is not emphasized here, leading to higher acceptable latencies maybe (alth= ough when mixing distributed music, you are still down at few ms latency). = But it's the dynamic relations that I wanted to point out, which pose a= dditional requirements. This may also be the case for industrial use cases,= BTW. Maybe something to consider as a possible dimension?

Best,

Dirk

-----Original Message-----
From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Chathura Sarathchan= dra
Sent: 25 June 2021 15:49
To: int-area@ietf.or= g
Cc: Mona Ghassemian <Mona.Ghassemian@InterDigital.com>
Subject: Re: [Int-area] New Version Notification for draft-sarathchandra-ta= ctile-internet-00.txt

Dear all,

Please find below our new draft submission on Tactile Internet Service Requ= irements.

This draft introduces tactile internet use cases and service requirements p= otentially to be used as input for further discussions and/or to be directl= y addressed by IETF.

Comments and feedback are warmly welcome!

Best regards,
Chathura

-----Original Message-----
From: interne= t-drafts@ietf.org <internet-drafts@ietf.org>
Sent: 25 June 2021 14:28
To: Chathura Sarathchandra <Chathura.Sarathchandra@interdigital.com>; Mona Ghassemian <Mona.Ghassemian@InterDigital.com>; Morteza Kh= eirkhah <Morteza.Kheirkhah@InterDigital.com>
Subject: New Version Notification for draft-sarathchandra-tactile-internet-= 00.txt



A new version of I-D, draft-sarathchandra-tactile-internet-00.txt
has been successfully submitted by Chathura Sarathchandra and posted to the= IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-sarathchandra-tactile-i= nternet
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tactile Internet Service Requireme= nts
Document date:=C2=A0 2021-06-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
https://www.ietf.org/archive/id/draft-sarathchandra-ta= ctile-internet-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-sarathchandra-tactile-in= ternet/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-sarathchandra-tacti= le-internet


Abstract:
=C2=A0 =C2=A0The Tactile Internet refers to a new communication and network= ing
=C2=A0 =C2=A0paradigm, which can provide low-latency, reliable and secure =C2=A0 =C2=A0transmission for real-time information such as control, touch,= and
=C2=A0 =C2=A0sensing/actuation in emerging tactile internet applications li= ke
=C2=A0 =C2=A0teleoperation, immersive virtual reality,and haptics communica= tions.
=C2=A0 =C2=A0The main goal of this document is: 1) to briefly introduce tac= tile
=C2=A0 =C2=A0internet background and typical applications; 2) to identify =C2=A0 =C2=A0potential service requirements that can be addressed at the IE= TF or
=C2=A0 =C2=A0researched at the IRTF.




The IETF Secretariat


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

[Banner]

[Banner]<https://www.inte= rdigital.com/features/sustainability-in-a-wireless-world>

Sustainability in a Wireless World: Research dedicated to understanding the= impact of our technologies on the planet.<https://www.interdigital.com/features/sustainability-in-a= -wireless-world>
This e-mail is intended only for the use of the individual or entity to whi= ch it is addressed, and may contain information that is privileged, confide= ntial and/or otherwise protected from disclosure to anyone other than its i= ntended recipient. Unintended transmission shall not constitute waiver of a= ny privilege or confidentiality obligation. If you received this communicat= ion in error, please do not review, copy or distribute it, notify me immedi= ately by email, and delete the original message and any attachments. Unless= expressly stated in this e-mail, nothing in this message or any attachment= should be construed as a digital or electronic signature.

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
--0000000000001d7e8205c5e8fd59-- From nobody Tue Jun 29 09:10:09 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D013A3852; Tue, 29 Jun 2021 08:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 n38AZyFfulPx; Tue, 29 Jun 2021 08:55:51 -0700 (PDT) Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 05FAA3A3853; Tue, 29 Jun 2021 08:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=08aMmExVFuxXMrycCBDbCL7InJl5uzBs4e3wEXSshVk=; b=dTi3jTVb2RKNczVjkPYDq3V7nd HSNYHQAO99gQGKTb8GNysqui1oOy8fvYnWS714Xo359kbknL8hhoJzjmvr7Xr5avgqn0zwA4cxOEt qoR7jTDftVXdPe5tIHcYGcWccrYlcap+0K5rHr1PKMfLRpV13LxNuDg4Jfo1DxiOlmGzWJ9aN1ydT cC80+tVvsTXrSkufJqPCmNVln0dLkUJiqPoBw3EH5JDwF8fhc+8Jz2LnqO24vVpUVo0tqCpTXVmwz ssC/SuxlBOxDsukJ8WCABTLCf0/+HpZKYrg55/eWxzDcKt5nnfdrk1tz6AessTA5cstHmZxJocsBw 7gq4Ns6A==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:44482 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lyG5W-0001mD-Og; Tue, 29 Jun 2021 16:55:48 +0100 To: Giles Heron Cc: intarea IETF list , pals@ietf.org References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com> <50ADB293-A7EC-4574-9430-43E68073A6D1@townsley.net> <4AC24C92-DD6C-4D5E-B113-0123DFD842A5@layerfree.net> <7c89b2b3-1576-bdec-c2d5-64393f27f7bf@bobbriscoe.net> <4823D617-4DF2-4F8B-BBAD-382910D309CF@layerfree.net> From: Bob Briscoe Message-ID: Date: Tue, 29 Jun 2021 16:55:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <4823D617-4DF2-4F8B-BBAD-382910D309CF@layerfree.net> Content-Type: multipart/alternative; boundary="------------FE3D132629BFDED844A3A411" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: X-Mailman-Approved-At: Tue, 29 Jun 2021 09:10:08 -0700 Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 15:55:57 -0000 This is a multi-part message in MIME format. --------------FE3D132629BFDED844A3A411 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Giles, On 29/06/2021 12:41, Giles Heron wrote: > Hi Bob, > >> On 28 Jun 2021, at 00:23, Bob Briscoe > > wrote: >> >> Giles, Mark, >> >> On 10/06/2021 13:22, Giles Heron wrote: >>> So AFAIK SP networks don’t generally reorder packets in the steady >>> state, but of course reordering can occur under rerouting. >> >> [BB] The cases I'm concerned about are where the operator >> * deliberately reorders packets using a multi-queue scheduler at a >> node contrived to act as the bottleneck (the BNG) >> * AND the node is within an L2TPv2/3 tunnel >> * AND the tunnel needs sequencing at the egress for some other reason. > > If that’s the case then the node almost certainly won’t re-order > packets within the tunnel, even if it is deliberately reordering > packets between clients.  As far as the node is concerned the L2TPv3 > tunnel is one flow within one subscriber’s traffic.   BNG reordering > is generally between subscribers (e.g. where subscribers get serviced > round-robin to ensure fairness), or potentially within classes of > service per subscriber (e.g. strict priority for on-net voice and IPTV > over Internet traffic). [BB] Not so. There are certainly cases where packets /are/ reordered within a per-customer tunnel. For instance, in the BT wholesale case, the BNG uses the BBF framework to schedule a set of QoS queues for each customer CVLAN. I know this intimately, because it was what I had been asked to simplify when we came up with L4S in the first place. Indeed, I was given permission to include a picture and description of it in this public report we did for the EU-funded project: https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3-public1.pdf#12 Also, there are probably many cases of accidental reordering too, e.g. due to channel bonding or multipath links that are left out of order rather than resequenced, or reroutes, including those at L7, when the traffic source moves to a CDN after a flow starts, etc. etc. Whatever, the question is the converse: where packets are /not/ deliberately re-ordered by the network operator today, might these operators be sequencing IP data emerging from an L2TP tunnel? If so, they would have to disable sequencing if they wanted to introduce deliberate reordering (to transition to L4S). But (based partly on the insights you've given already) I doubt there is much if any sequencing going on of IP data over tunnels. > >> >> In many cases, such a scheduler would be located prior to the tunnel >> ingress, so not a concern. I believe the DOCSIS rPHY case below falls >> into that category (both downstream and up). > > Agreed > >> >> In contrast, where a BNG sits /within/ the span of an L2TP tunnel, I >> think it will often (or at least sometimes?) have been constructed as >> the bottleneck. Any operator having designed such a QoS arrangement >> would not want to support sequencing... > > Yes, BNGs are often planned to be the bottleneck.  But as I say that’s > about fairness between subscribers and potentially prioritising > different traffic for each subscriber. > >>> As noted by Derek I’m guessing reordering is an issue for L2TPv2 if >>> stateful PPP compression schemes are in play (which I suspect is >>> unlikely to be the case given we usually have abundant bandwidth in >>> the aggregation network, and given that compression can occur at >>> other layers).  Though given that BNGs inherently keep state per >>> subscriber maybe the NPU scaling issues that Stewart mentioned are >>> less of an issue in that use case than for MPLS PEs doing PWE? >> >> My concern was that 'keep it simple' operators that are using >> L2TPv2/3 and had not previously bothered with the complexities of QoS >> might want to support L4S, because it has the potential to cut out >> queue delay for /all/ traffic. Altho' L4S is eventually for all >> traffic, it still requires two queues at the bottleneck for >> transition - one for L4S and one for not-yet-L4S ('Classic') traffic >> flows, and therefore introduces reordering at the aggregate level... > > Again I presume any single tunnel being passed *through* a BNG would > either be L4S or not-yet-L4S, and hence not subject to reordering? [BB] Not so, I'm afraid. L4S is enabled on a per-host basis, and during the transition, some traffic in the IP aggregate to (or from) a customer site will be L4S, and some Classic (not-yet-L4S). It's this reordering scenario that begged my original question - whether sequencing might be used anywhere for IP data over a tunnel. Cheers Bob > > Giles > >> >> From the replies so far, even if such 'keep it simple' operators were >> using compression, I can't see any reason why having to turn off >> compression and sequencing (in order to support L4S) would be a >> significant problem nowadays. >> >> So, in conclusion, I don't think we even need to raise any concerns >> about L2TP sequencing in the L4S specs. >> >> If anyone here thinks otherwise, pls speak now. >> >> Thank you everyone who has contributed to this discussion. >> >> Cheers >> >> >> >> Bob >> >> >> >>> >>> From a quick look at the DOCSIS rPHY specs it seems they do require >>> support for L2TPv3 sequence numbers.  Of course in that case the >>> payload is the DOCSIS MAC rather than IP (even though, of course, >>> most DOCSIS frames ultimately carry an IP payload). >>> >>> Giles >>> >>>> On 10 Jun 2021, at 12:49, Andrew G. Malis >>> > wrote: >>>> >>>> (resending with cc: list trimmed to pass the too many recipients >>>> filter) >>>> Mark, >>>> >>>> The original question was, how many (if any) of these L2TPv2 and v3 >>>> use cases use sequencing, especially when carrying IP? >>>> >>>> Cheers, >>>> Andy >>>> >>>> On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley >>> > wrote: >>>> >>>> Hi folks, >>>> >>>> In addition to the DSL arena, L2TP is still in use with >>>> host-based VPN clients as it is embedded in Apple, Android, and >>>> Windows based operating systems (new and old). Despite most VPN >>>> solutions preferring their own client software that must be >>>> installed on hosts to operate, there are still admins that >>>> appreciate not having to ask their employees to download an app >>>> for the VPN to work - in which case PPTP and L2TP with >>>> transport-mode IPsec are your most widely available options. >>>> >>>> Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP >>>> only. L2TPv3 generalized L2TP to support other L2 (including >>>> MPLS, but I don’t want to argue what layer MPLS operates within >>>> here). There was never a strong push to replace L2TPv2 used in >>>> DSL, Dialup and host VPN software with L2TPv3 (there was one >>>> use case for an important L2TP operator that wanted to carry >>>> PPPoE over L2TPv3 in DSL, but that was overcome by RFC3817 >>>> which achieved the same goal without altering the dataplane). >>>> Ironically, I would expect to see very little PPP over L2TPv3 >>>> in the wild, though obviously it is possible. >>>> >>>> In the cable broadband world, the DOCSIS DEPI “Remote PHY” >>>> specification (similar I suppose to the split BNG spec Joel is >>>> referring to) standardized on L2TPv3 and is in active use. >>>> >>>> I also know of at least one vendor that uses Ethernet over >>>> L2TPv3 for some wifi backhaul use cases. >>>> >>>> There could be more, this is just what I am personally aware of >>>> off the top of my head. Even I am surprised to see how much >>>> L2TP is still out there once you start really looking around ;-) >>>> >>>> Best Regards, >>>> >>>> - Mark >>>> >>>> >>>> >>>> >>>> > On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct >>>> >>> > wrote: >>>> > >>>> > 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 >>>> > 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 >>>> >>>> >> 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 >>>> >>> >>>> >>> >> 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 >>>> > >>>> >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> Pals mailing list >>>> Pals@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pals >>> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------FE3D132629BFDED844A3A411 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Giles,

On 29/06/2021 12:41, Giles Heron wrote:
Hi Bob,

On 28 Jun 2021, at 00:23, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Giles, Mark,

On 10/06/2021 13:22, Giles Heron wrote:
So AFAIK SP networks don’t generally reorder packets in the steady state, but of course reordering can occur under rerouting.

[BB] The cases I'm concerned about are where the operator
* deliberately reorders packets using a multi-queue scheduler at a node contrived to act as the bottleneck (the BNG)
* AND the node is within an L2TPv2/3 tunnel
* AND the tunnel needs sequencing at the egress for some other reason. 

If that’s the case then the node almost certainly won’t re-order packets within the tunnel, even if it is deliberately reordering packets between clients.  As far as the node is concerned the L2TPv3 tunnel is one flow within one subscriber’s traffic.   BNG reordering is generally between subscribers (e.g. where subscribers get serviced round-robin to ensure fairness), or potentially within classes of service per subscriber (e.g. strict priority for on-net voice and IPTV over Internet traffic).

[BB] Not so. There are certainly cases where packets /are/ reordered within a per-customer tunnel. For instance, in the BT wholesale case, the BNG uses the BBF framework to schedule a set of QoS queues for each customer CVLAN. I know this intimately, because it was what I had been asked to simplify when we came up with L4S in the first place. Indeed, I was given permission to include a picture and description of it in this public report we did for the EU-funded project: https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3-public1.pdf#12

Also, there are probably many cases of accidental reordering too, e.g. due to channel bonding or multipath links that are left out of order rather than resequenced, or reroutes, including those at L7, when the traffic source moves to a CDN after a flow starts, etc. etc.


Whatever, the question is the converse: where packets are /not/ deliberately re-ordered by the network operator today, might these operators be sequencing IP data emerging from an L2TP tunnel? If so, they would have to disable sequencing if they wanted to introduce deliberate reordering (to transition to L4S). But (based partly on the insights you've given already) I doubt there is much if any sequencing going on of IP data over tunnels.



In many cases, such a scheduler would be located prior to the tunnel ingress, so not a concern. I believe the DOCSIS rPHY case below falls into that category (both downstream and up).

Agreed


In contrast, where a BNG sits /within/ the span of an L2TP tunnel, I think it will often (or at least sometimes?) have been constructed as the bottleneck. Any operator having designed such a QoS arrangement would not want to support sequencing...

Yes, BNGs are often planned to be the bottleneck.  But as I say that’s about fairness between subscribers and potentially prioritising different traffic for each subscriber.

As noted by Derek I’m guessing reordering is an issue for L2TPv2 if stateful PPP compression schemes are in play (which I suspect is unlikely to be the case given we usually have abundant bandwidth in the aggregation network, and given that compression can occur at other layers).  Though given that BNGs inherently keep state per subscriber maybe the NPU scaling issues that Stewart mentioned are less of an issue in that use case than for MPLS PEs doing PWE?

My concern was that 'keep it simple' operators that are using L2TPv2/3 and had not previously bothered with the complexities of QoS might want to support L4S, because it has the potential to cut out queue delay for /all/ traffic. Altho' L4S is eventually for all traffic, it still requires two queues at the bottleneck for transition - one for L4S and one for not-yet-L4S ('Classic') traffic flows, and therefore introduces reordering at the aggregate level...

Again I presume any single tunnel being passed *through* a BNG would either be L4S or not-yet-L4S, and hence not subject to reordering?

[BB] Not so, I'm afraid. L4S is enabled on a per-host basis, and during the transition, some traffic in the IP aggregate to (or from) a customer site will be L4S, and some Classic (not-yet-L4S).

It's this reordering scenario that begged my original question - whether sequencing might be used anywhere for IP data over a tunnel.

Cheers



Bob


Giles


From the replies so far, even if such 'keep it simple' operators were using compression, I can't see any reason why having to turn off compression and sequencing (in order to support L4S) would be a significant problem nowadays.

So, in conclusion, I don't think we even need to raise any concerns about L2TP sequencing in the L4S specs.

If anyone here thinks otherwise, pls speak now.

Thank you everyone who has contributed to this discussion.

Cheers



Bob




From a quick look at the DOCSIS rPHY specs it seems they do require support for L2TPv3 sequence numbers.  Of course in that case the payload is the DOCSIS MAC rather than IP (even though, of course, most DOCSIS frames ultimately carry an IP payload).

Giles

On 10 Jun 2021, at 12:49, Andrew G. Malis <agmalis@gmail.com> wrote:

(resending with cc: list trimmed to pass the too many recipients filter)
Mark,

The original question was, how many (if any) of these L2TPv2 and v3 use cases use sequencing, especially when carrying IP?

Cheers,
Andy

On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley <mark@townsley.net> wrote:
Hi folks,

In addition to the DSL arena, L2TP is still in use with host-based VPN clients as it is embedded in Apple, Android, and Windows based operating systems (new and old). Despite most VPN solutions preferring their own client software that must be installed on hosts to operate, there are still admins that appreciate not having to ask their employees to download an app for the VPN to work - in which case PPTP and L2TP with transport-mode IPsec are your most widely available options.

Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. L2TPv3 generalized L2TP to support other L2 (including MPLS, but I don’t want to argue what layer MPLS operates within here). There was never a strong push to replace L2TPv2 used in DSL, Dialup and host VPN software with L2TPv3 (there was one use case for an important L2TP operator that wanted to carry PPPoE over L2TPv3 in DSL, but that was overcome by RFC3817 which achieved the same goal without altering the dataplane). Ironically, I would expect to see very little PPP over L2TPv3 in the wild, though obviously it is possible.

In the cable broadband world, the DOCSIS DEPI “Remote PHY” specification (similar I suppose to the split BNG spec Joel is referring to) standardized on L2TPv3 and is in active use.

I also know of at least one vendor that uses Ethernet over L2TPv3 for some wifi backhaul use cases.

There could be more, this is just what I am personally aware of off the top of my head. Even I am surprised to see how much L2TP is still out there once you start really looking around ;-)

Best Regards,

- Mark




> On Jun 9, 2021, at 6:10 AM, Joel Halpern Direct <jmh.direct@joelhalpern.com> wrote:
>
> 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

_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------FE3D132629BFDED844A3A411-- From nobody Tue Jun 29 09:23:38 2021 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185B73A396A; Tue, 29 Jun 2021 09:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 U7-rmFbundkw; Tue, 29 Jun 2021 09:23:27 -0700 (PDT) Received: from layerfree.net (heronab2.miniserver.com [89.200.138.104]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9FF3A3976; Tue, 29 Jun 2021 09:23:03 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)); envelope-from=173.38.220.34; From: Giles Heron Message-Id: <16FC122D-EBFB-4B83-9FB1-52332D83C478@layerfree.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_6D6EF28F-6744-4F53-8EA5-B2C71AFEF20C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 29 Jun 2021 17:22:55 +0100 In-Reply-To: <519F0CB1-C9CF-4EA6-95A9-7D58078A386C@layerfree.net> Cc: intarea IETF list , pals@ietf.org To: Bob Briscoe References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com> <50ADB293-A7EC-4574-9430-43E68073A6D1@townsley.net> <4AC24C92-DD6C-4D5E-B113-0123DFD842A5@layerfree.net> <7c89b2b3-1576-bdec-c2d5-64393f27f7bf@bobbriscoe.net> <4823D617-4DF2-4F8B-BBAD-382910D309CF@layerfree.net> <519F0CB1-C9CF-4EA6-95A9-7D58078A386C@layerfree.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-IP-stats: Incoming Last 0, First 91, in=3, out=0, spam=0 ip=HiddenIP Archived-At: Subject: Re: [Int-area] [Pals] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 16:23:33 -0000 --Apple-Mail=_6D6EF28F-6744-4F53-8EA5-B2C71AFEF20C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Re-sending trimmed to 40k > On 29 Jun 2021, at 17:16, Giles Heron wrote: >=20 > Hi Bob, >=20 >> On 29 Jun 2021, at 16:55, Bob Briscoe > wrote: >>=20 >> Giles, >>=20 >> On 29/06/2021 12:41, Giles Heron wrote: >>> Hi Bob, >>>=20 >>>> On 28 Jun 2021, at 00:23, Bob Briscoe > wrote: >>>>=20 >>>> Giles, Mark, >>>>=20 >>>> On 10/06/2021 13:22, Giles Heron wrote: >>>>> So AFAIK SP networks don=E2=80=99t generally reorder packets in = the steady state, but of course reordering can occur under rerouting. >>>>=20 >>>> [BB] The cases I'm concerned about are where the operator >>>> * deliberately reorders packets using a multi-queue scheduler at a = node contrived to act as the bottleneck (the BNG) >>>> * AND the node is within an L2TPv2/3 tunnel=20 >>>> * AND the tunnel needs sequencing at the egress for some other = reason.=20 >>>=20 >>> If that=E2=80=99s the case then the node almost certainly won=E2=80=99= t re-order packets within the tunnel, even if it is deliberately = reordering packets between clients. As far as the node is concerned the = L2TPv3 tunnel is one flow within one subscriber=E2=80=99s traffic. BNG = reordering is generally between subscribers (e.g. where subscribers get = serviced round-robin to ensure fairness), or potentially within classes = of service per subscriber (e.g. strict priority for on-net voice and = IPTV over Internet traffic). >>=20 >> [BB] Not so. There are certainly cases where packets /are/ reordered = within a per-customer tunnel. For instance, in the BT wholesale case, = the BNG uses the BBF framework to schedule a set of QoS queues for each = customer CVLAN. I know this intimately, because it was what I had been = asked to simplify when we came up with L4S in the first place. Indeed, I = was given permission to include a picture and description of it in this = public report we did for the EU-funded project: = https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3-publi= c1.pdf#12 = >=20 > Yup - what I said. BNGs may reorder classes of service per sub. But = one L2TP tunnel where the endpoints are either side of the BNG ought to = map to a single CoS, right? And if it does then it won=E2=80=99t be = reordered. >=20 >> Also, there are probably many cases of accidental reordering too, = e.g. due to channel bonding or multipath links that are left out of = order rather than resequenced, or reroutes, including those at L7, when = the traffic source moves to a CDN after a flow starts, etc. etc. >=20 > Channel bonding and multipath links are generally set up very = carefully NOT to reorder packets within one flow. >=20 > I covered rerouting in my original reply to you. >=20 > And I think we can safely ignore CDNs in discussion of L2TP ;) >=20 >> Whatever, the question is the converse: where packets are /not/ = deliberately re-ordered by the network operator today, might these = operators be sequencing IP data emerging from an L2TP tunnel? If so, = they would have to disable sequencing if they wanted to introduce = deliberate reordering (to transition to L4S). But (based partly on the = insights you've given already) I doubt there is much if any sequencing = going on of IP data over tunnels. >=20 > Agreed. >=20 > Giles >=20 >>>=20 >>>>=20 >>>> In many cases, such a scheduler would be located prior to the = tunnel ingress, so not a concern. I believe the DOCSIS rPHY case below = falls into that category (both downstream and up). >>>=20 >>> Agreed >>>=20 >>>>=20 >>>> In contrast, where a BNG sits /within/ the span of an L2TP tunnel, = I think it will often (or at least sometimes?) have been constructed as = the bottleneck. Any operator having designed such a QoS arrangement = would not want to support sequencing... >>>=20 >>> Yes, BNGs are often planned to be the bottleneck. But as I say = that=E2=80=99s about fairness between subscribers and potentially = prioritising different traffic for each subscriber. >>>=20 >>>>> As noted by Derek I=E2=80=99m guessing reordering is an issue for = L2TPv2 if stateful PPP compression schemes are in play (which I suspect = is unlikely to be the case given we usually have abundant bandwidth in = the aggregation network, and given that compression can occur at other = layers). Though given that BNGs inherently keep state per subscriber = maybe the NPU scaling issues that Stewart mentioned are less of an issue = in that use case than for MPLS PEs doing PWE? >>>>=20 >>>> My concern was that 'keep it simple' operators that are using = L2TPv2/3 and had not previously bothered with the complexities of QoS = might want to support L4S, because it has the potential to cut out queue = delay for /all/ traffic. Altho' L4S is eventually for all traffic, it = still requires two queues at the bottleneck for transition - one for L4S = and one for not-yet-L4S ('Classic') traffic flows, and therefore = introduces reordering at the aggregate level... >>>=20 >>> Again I presume any single tunnel being passed *through* a BNG would = either be L4S or not-yet-L4S, and hence not subject to reordering? >>=20 >> [BB] Not so, I'm afraid. L4S is enabled on a per-host basis, and = during the transition, some traffic in the IP aggregate to (or from) a = customer site will be L4S, and some Classic (not-yet-L4S). >>=20 >> It's this reordering scenario that begged my original question - = whether sequencing might be used anywhere for IP data over a tunnel.=20 >>=20 >> Cheers >>=20 >>=20 >>=20 >> Bob >>=20 >>>=20 >>> Giles >>>=20 >>>>=20 >>>> =46rom the replies so far, even if such 'keep it simple' operators = were using compression, I can't see any reason why having to turn off = compression and sequencing (in order to support L4S) would be a = significant problem nowadays. >>>>=20 >>>> So, in conclusion, I don't think we even need to raise any concerns = about L2TP sequencing in the L4S specs. >>>>=20 >>>> If anyone here thinks otherwise, pls speak now. >>>>=20 >>>> Thank you everyone who has contributed to this discussion. >>>>=20 >>>> Cheers >>>>=20 >>>>=20 >>>>=20 >>>> Bob >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> =46rom a quick look at the DOCSIS rPHY specs it seems they do = require support for L2TPv3 sequence numbers. Of course in that case the = payload is the DOCSIS MAC rather than IP (even though, of course, most = DOCSIS frames ultimately carry an IP payload). >>>>>=20 >>>>> Giles >>>>>=20 >>>>>> On 10 Jun 2021, at 12:49, Andrew G. Malis > wrote: >>>>>>=20 >>>>>> (resending with cc: list trimmed to pass the too many recipients = filter) >>>>>> Mark, >>>>>>=20 >>>>>> The original question was, how many (if any) of these L2TPv2 and = v3 use cases use sequencing, especially when carrying IP? >>>>>>=20 >>>>>> Cheers, >>>>>> Andy >>>>>>=20 >>>>>> On Wed, Jun 9, 2021 at 6:32 PM Mark Townsley > wrote: >>>>>> Hi folks, >>>>>>=20 >>>>>> In addition to the DSL arena, L2TP is still in use with = host-based VPN clients as it is embedded in Apple, Android, and Windows = based operating systems (new and old). Despite most VPN solutions = preferring their own client software that must be installed on hosts to = operate, there are still admins that appreciate not having to ask their = employees to download an app for the VPN to work - in which case PPTP = and L2TP with transport-mode IPsec are your most widely available = options.=20 >>>>>>=20 >>>>>> Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. = L2TPv3 generalized L2TP to support other L2 (including MPLS, but I = don=E2=80=99t want to argue what layer MPLS operates within here). There = was never a strong push to replace L2TPv2 used in DSL, Dialup and host = VPN software with L2TPv3 (there was one use case for an important L2TP = operator that wanted to carry PPPoE over L2TPv3 in DSL, but that was = overcome by RFC3817 which achieved the same goal without altering the = dataplane). Ironically, I would expect to see very little PPP over = L2TPv3 in the wild, though obviously it is possible. >>>>>>=20 >>>>>> In the cable broadband world, the DOCSIS DEPI =E2=80=9CRemote = PHY=E2=80=9D specification (similar I suppose to the split BNG spec Joel = is referring to) standardized on L2TPv3 and is in active use. >>>>>>=20 >>>>>> I also know of at least one vendor that uses Ethernet over L2TPv3 = for some wifi backhaul use cases.=20 >>>>>>=20 >>>>>> There could be more, this is just what I am personally aware of = off the top of my head. Even I am surprised to see how much L2TP is = still out there once you start really looking around ;-) >>>>>>=20 >>>>>> Best Regards, >>>>>>=20 >>>>>> - Mark >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >=20 --Apple-Mail=_6D6EF28F-6744-4F53-8EA5-B2C71AFEF20C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Re-sending trimmed to 40k

On 29 = Jun 2021, at 17:16, Giles Heron <giles@layerfree.net> wrote:

Hi Bob,

On 29 Jun 2021, at 16:55, Bob Briscoe <ietf@bobbriscoe.net>= wrote:

=20 =20
Giles,

On 29/06/2021 12:41, Giles Heron = wrote:
Hi Bob,

On 28 Jun 2021, at 00:23, Bob Briscoe <ietf@bobbriscoe.net> wrote:

Giles, Mark,

On 10/06/2021 13:22, Giles Heron wrote:
So AFAIK SP networks don=E2=80=99t = generally reorder packets in the steady state, but of course reordering can occur under rerouting.

[BB] The cases I'm concerned about are where the = operator
* deliberately reorders packets using a multi-queue scheduler at a node contrived to act as the bottleneck (the BNG)
* AND the node is within an L2TPv2/3 tunnel
* AND the tunnel needs sequencing at the egress for some other reason. 

If that=E2=80=99s the case then the node almost = certainly won=E2=80=99t re-order packets within the tunnel, even if it is deliberately reordering packets between clients.  As far as the node is concerned the L2TPv3 tunnel is one flow within one = subscriber=E2=80=99s traffic.   BNG reordering is generally between subscribers = (e.g. where subscribers get serviced round-robin to ensure fairness), or potentially within classes of service per subscriber (e.g. strict priority for on-net voice and IPTV over Internet traffic).

[BB] Not so. There are certainly cases where packets /are/ reordered within a per-customer tunnel. For instance, in the BT wholesale case, the BNG uses the BBF framework to schedule a set of QoS queues for each customer CVLAN. I know this intimately, because it was what I had been asked to simplify when we came up with L4S in the first place. Indeed, I was given permission to include a picture and description of it in this public report we did for the EU-funded project: https://riteproject.files.wordpress.com/2015/12/rite-de= liverable-3-3-public1.pdf#12

Yup - what I said.   BNGs may reorder classes of = service per sub.  But one L2TP tunnel where the endpoints are = either side of the BNG ought to map to a single CoS, right?  And if = it does then it won=E2=80=99t be reordered.

Also, there are probably many cases of accidental reordering too, e.g. due to channel bonding or multipath links that are left out of order rather than resequenced, or reroutes, including those at L7, when the traffic source moves to a CDN after a flow starts, etc. etc.

Channel bonding and multipath links are = generally set up very carefully NOT to reorder packets within one = flow.

I = covered rerouting in my original reply to you.

And I think we can safely ignore CDNs = in discussion of L2TP ;)

=20 Whatever, the question is the converse: where packets are /not/ deliberately re-ordered by the network operator today, might these operators be sequencing IP data emerging from an L2TP tunnel? If so, they would have to disable sequencing if they wanted to introduce deliberate reordering (to transition to L4S). But (based partly on the insights you've given already) I doubt there is much if any sequencing going on of IP data over tunnels.

Agreed.

Giles



In many cases, such a scheduler would be located prior to the tunnel ingress, so not a concern. I believe the DOCSIS rPHY case below falls into that category (both downstream and up).

Agreed


In contrast, where a BNG sits /within/ the span of an L2TP tunnel, I think it will often (or at least sometimes?) have been constructed as the bottleneck. Any operator having designed such a QoS arrangement would not want to support sequencing...

Yes, BNGs are often planned to be the bottleneck.  But as I = say that=E2=80=99s about fairness between subscribers and = potentially prioritising different traffic for each subscriber.

As noted by Derek I=E2=80=99m guessing = reordering is an issue for L2TPv2 if stateful PPP compression schemes are in play (which I suspect is unlikely to be the case given we usually have abundant bandwidth in the aggregation network, and given that compression can occur at other layers).  Though given that = BNGs inherently keep state per subscriber maybe the NPU scaling issues that Stewart mentioned are less of an issue in that use case than for MPLS PEs doing = PWE?

My concern was that 'keep it simple' operators that are using L2TPv2/3 and had not previously bothered with the complexities of QoS might want to support L4S, because it has the potential to cut out queue delay for /all/ traffic. Altho' L4S is eventually for all traffic, it still requires two queues at the bottleneck for transition - one for L4S and one for not-yet-L4S ('Classic') traffic flows, and therefore introduces reordering at the aggregate level...

Again I presume any single tunnel being passed = *through* a BNG would either be L4S or not-yet-L4S, and hence not subject to reordering?

[BB] Not so, I'm afraid. L4S is enabled on a per-host basis, and during the transition, some traffic in the IP aggregate to (or from) a customer site will be L4S, and some Classic (not-yet-L4S).

It's this reordering scenario that begged my original question - whether sequencing might be used anywhere for IP data over a tunnel.

Cheers



Bob


Giles


=46rom the replies so far, even if such 'keep it simple' operators were using compression, I can't see any reason why having to turn off compression and sequencing (in order to support L4S) would be a significant problem nowadays.

So, in conclusion, I don't think we even need to raise any concerns about L2TP sequencing in the L4S specs.

If anyone here thinks otherwise, pls speak now.

Thank you everyone who has contributed to this = discussion.

Cheers



Bob




=46rom a quick look at the DOCSIS rPHY = specs it seems they do require support for L2TPv3 sequence numbers.  Of course in that case the payload is = the DOCSIS MAC rather than IP (even though, of course, most DOCSIS frames ultimately carry an IP = payload).

Giles

On 10 Jun 2021, at 12:49, Andrew G. Malis <agmalis@gmail.com> wrote:

(resending with cc: = list trimmed to pass the too many recipients filter)
Mark,

The original question was, how many (if any) of these L2TPv2 and v3 use cases use sequencing, especially when carrying IP?

Cheers,
Andy

On Wed, = Jun 9, 2021 at 6:32 PM Mark Townsley <mark@townsley.net> wrote:
Hi = folks,

In addition to the DSL arena, L2TP is still in use with host-based VPN clients as it is embedded in Apple, Android, and Windows based operating systems (new and old). Despite most VPN solutions preferring their own client software that must be installed on hosts to operate, there are still admins that appreciate not having to ask their employees to download an app for the VPN to work - in which case PPTP and L2TP with transport-mode IPsec are your most widely available options.

Regarding L2TPv3 replacing L2TP: L2TPv2 (RFC 2661) was PPP only. L2TPv3 generalized L2TP to support other L2 (including MPLS, but I = don=E2=80=99t want to argue what layer MPLS operates within here). There was never a strong push to replace L2TPv2 used in DSL, Dialup and host VPN software with L2TPv3 (there was one use case for an important L2TP operator that wanted to carry PPPoE over L2TPv3 in DSL, but that was overcome by RFC3817 which achieved the same goal without altering the dataplane). Ironically, I would expect to see very little PPP over L2TPv3 in the wild, though obviously it is possible.

In the cable broadband world, the DOCSIS DEPI =E2=80=9CRemote PHY=E2=80=9D specification = (similar I suppose to the split BNG spec Joel is referring to) standardized on L2TPv3 and is in active = use.

I also know of at least one vendor that uses Ethernet over L2TPv3 for some wifi backhaul use cases.

There could be more, this is just what I am personally aware of off the top of my head. Even I am surprised to see how much L2TP is still out there once you start really looking around ;-)

Best Regards,

- Mark




=


= --Apple-Mail=_6D6EF28F-6744-4F53-8EA5-B2C71AFEF20C--