From nobody Fri Jun 4 08:07:28 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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 Wed Jun 9 03:23:12 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:04:18 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C1F3A0D43; Wed, 9 Jun 2021 04:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 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, HTTPS_HTTP_MISMATCH=0.1, PDS_BAD_THREAD_QP_64=0.998, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=rbbn.com header.b=HwtV/mHU; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com header.b=bCOjp5Bq 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 jqXUNkRcJsoi; Wed, 9 Jun 2021 04:04:11 -0700 (PDT) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.2]) (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 D66E33A0D3E; Wed, 9 Jun 2021 04:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=rbbnselector03122020; t=1623236648; i=@rbbn.com; bh=9PsgrkjKLxRjF5k7Arwa02SNesWvbNs/WpZnGvr+HVw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=HwtV/mHUA6nvIf/i77orzFJm3/X4+RCj+CP1C4QfNCL61lz3BaTMXcL76yDsYQrZW 1ex9wjTgjsNwu7/LpjWYPRNrY//VY/HMcZKif/d8ecrtK2UPTv2KGHzmQdKBxtZBl6 LZ+/n8o5l/Jq/b8DB7045YJZ+oq51IMsEzcGt6gQkjTQ+SEpG89ap7czU1rti2f38V JoQios19OiHmX3zgrDAZuczUvbfdfFuGZuIdyJB/tGfec8kkfi+SnykrjYFBujKcnD Plgh3wiihIwJpw+g+azIhxTKt1UW0+T9Dxj8AP6aGok9GP26tBzF2j1s5ytN4A2oWt eJJoh77ha4uVw== Received: from [100.112.193.7] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-west-1.aws.symcld.net id A1/F5-28327-820A0C06; Wed, 09 Jun 2021 11:04:08 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTf0wTZxjHee+ux+moOwuOB4YmKygb0I7qNIX J4rIBHRmDhSxuzgVK6dqyUkivhOJ+1bEfKjhYYqDrZC0CLqtFKVPBQRxQw/i1EatO0eD4tSmM gWAyYTiyu15x7p8nn+f9Pu/3/b6X9yhcVBsYTqnNJrXRoNSLybWE9ukUrSTa0ZkTX3EoTD5wq 5+UL8y2EfKqgc8x+eRlj0B+zTZMyKs7RzG5a+UkJu8fVe6iFEeW3QJFV888UpyzjQQqGhqWMM XIdS+m+LX6CyyT3CPQGXILzTkC7XLbHbzoBGMu+7Mds6AZ1SG0lkJ0Iw69A26cb3oIOHCinOQ bJ4KD9vuIawi6HYcySyc7toYS0XYMeg7KOEFE30Swv3I6kBNIOhGW5wYJjkPoD8A7u+KzwukK DNyWbsQJwbQOPjs9zgoUO5QPp6bi+PmtcLj1LMkxQUdB//2PBBwL6bdg7tAlAX/wBIKacinHa +gkmO6y+CwR/Rjc63dhHON0KFyftPsYaBoaOoZwnjfA1MSKgL/aAQS2i40kLzwBI2eqEM8bwW sv93M6eH53EDzHgKuyxc96aK39xH/AFhjaf9Xvswmch8f8MxEweq3Vd3mgO0j4x3sc4xs3AVP zLf5I8fD1XxfIKiS1PZScZwPc9N4lbb4vsB76vpwk+PU4cLQvkDzHwvG6P/BVHuycwB5ed6BA J5LnGnUaralAqdNLZPHxEplsq0SWsF0i2y6TKvdJlFJ1saREzZgkbFvCSJnSApU+T2pQm1oQ+ yLzijw1bahy5o60G4VRmHiDcNeHnTmidbmFeaVaJaPNNhbr1Uw3iqAoMQib7Ky23qjWqM1v6/ Tsu16VgQoShwif52QhU6QsYHQaXupHyVTVVO0xnJpdqmfrvLOBrfd8dXiOrSLCUGhQh4cKC7n NNLdZW2x4YL3613jRxvBgIQoICBAFFamNBTrT//VpFEohcbCwhnMJ0hlMDxJMs+EwLty281w4 k/I/KdyCZTv1V5rFhd/MZD1a/FsafjvKltHWFZkQPhSAUOZus8ZjTUq5O74l/bmy040lsc9Eh qXZLu/wxB7RHlUv1Ufqr1ZYA/CdF89nCL/d0zw6mWxI+cH0fVP1pz9bNZvdlsSYpTMf9xpeb6 grjXK4rE/2bc5/pPfss7FXYk792Nf207u76+ZaJAALL3/nOpea4BDtbE7LzJq8Vaxxf5UU8bc 4q3Vd+cBYsmuRnEi/vYgN73hcFV2eaFdlZ79gVkWnzFlforPe31f95uBTL1rJ8bEejXT+UjIx eiH15HuvhuTv/WXvjW2hqUvWjrQJZjjy2NFFhSfljbhXIpzvzDKqjO5NUU31r90QE4xWKYvBj YzyX+BhsvGwBAAA X-Env-Sender: Alexander.Vainshtein@rbbn.com X-Msg-Ref: server-3.tower-265.messagelabs.com!1623236646!282396!1 X-Originating-IP: [104.47.70.104] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.75.3; banners=rbbn.com,-,- X-VirusChecked: Checked Received: (qmail 26736 invoked from network); 9 Jun 2021 11:04:07 -0000 Received: from mail-bn7nam10lp2104.outbound.protection.outlook.com (HELO NAM10-BN7-obe.outbound.protection.outlook.com) (104.47.70.104) by server-3.tower-265.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 9 Jun 2021 11:04:07 -0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LzZiKabpyAMzyp8O0LuV3yK5klkef/HScZ3aiKziaiUjGntIfpsUhf0fGgulpm5wGO85QfwztPtRalfcu6pAfPNVDDFMjGqcEyywkX6aCZd6UVmAf24r2ZcuhfEVO+wWa393iNTxAZZ0S0NLg/KDFPG+sLcdUzuzSYqKLz+iP+9vzB84Ei1e8gkj6s/ioyq9/9cK01MAYk2BS3RZeinUAo+ov7+7kwbN8S736g1XaWxy9GavwZ8fUx+PhBGJZk/ShZZvlnVbiU3BM0hz0l1cMKaAavyHHb7KiCqfQJS2P6j/DnCPjj8RbiINRi4qEIZ/eM65ICdEdHyQJWI+N3GatQ== 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=+ej6c2mJtPNqTx8L36RtHVpxjBLGZbdtMjr3HfS0L0A=; b=nnEBYYlDQ3arVmcGgQJfeM2hFlw4IEhNEWhZs5h5B6aIgMOgh5Aeg5FUJITu3awBnVPBJtSKjvE1OyshUQVMOAk5Jm5Bf8CtC47lXL3NEHszFQr4Dx2Pnt+oYceZU5CXi/h0UR2vFtsXRrJP0VStOLhETPmd3cCMIan+3sn2oncB4tvNvt82pK+/dQ8wvpjeK+sPsw7alekyI/sIzB2DhSxCy+EzMt+Oj+Hoy6pZ5VKUnscd+X75yRon6TtnzITfacXbidgiwI3JCjtZAZ9+n8bghq6HATm3U/IyHNk3cwHsbZE1ReZ4vzsa9rTDNKin60BHqs4NULo2sGOHzN6mAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rbbn.com; dmarc=pass action=none header.from=rbbn.com; dkim=pass header.d=rbbn.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector2-SonusNetworks-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+ej6c2mJtPNqTx8L36RtHVpxjBLGZbdtMjr3HfS0L0A=; b=bCOjp5Bqvep9ddLrwk9jpjkm39Y/rpBxbXT9xWpIUTT/cTYEPQ04Gtn6o0dKyl1PPeWnvrcFaglBM/I28H+OlbGi+0aTCrbaz3QVGbxuYrCmWIUOlMwuG0K/UFWC5HhZl80VJjvC703cAQAKjoLf81aqHEpdp7qmSzXuOmZZpXc= Received: from SA1PR03MB6499.namprd03.prod.outlook.com (2603:10b6:806:1c6::8) by SA1PR03MB6531.namprd03.prod.outlook.com (2603:10b6:806:1c6::11) 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 11:04:04 +0000 Received: from SA1PR03MB6499.namprd03.prod.outlook.com ([fe80::e8ba:acac:1e72:675f]) by SA1PR03MB6499.namprd03.prod.outlook.com ([fe80::e8ba:acac:1e72:675f%3]) with mapi id 15.20.4219.021; Wed, 9 Jun 2021 11:04:04 +0000 From: Alexander Vainshtein To: Stewart Bryant , "Andrew G. Malis" , "mark@townsley.net" CC: "Carlos Pignataro (cpignata)" , Ignacio Goyret , intarea IETF list , Derek Fawcus , "pals@ietf.org" , Stewart Bryant Thread-Topic: [EXTERNAL] Re: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? Thread-Index: AQHXXRls0B91HqNHQEChrjCbolS3S6sLgegU Date: Wed, 9 Jun 2021 11:04:04 +0000 Message-ID: References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> , <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> In-Reply-To: <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.67.43.254] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ffbf029b-41b4-4951-b0fd-08d92b364b6a x-ms-traffictypediagnostic: SA1PR03MB6531: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Nj9vFAGgLrbP7DbM+ulpH/Y+PRiCtCk4iW2TKnodM6VC1ot7HJqlxwxThmf9OfCHN0T//R4m2jRMzAjTuMAxCkzuNm2jO4sTbOiGN4crOrrqqOFbMcNE7JBDV6NCga5gI9z6lS0aRAsDeHbdurJugPpUBb5fVXWT7lvWK9xnQqWzT8awS31uIp8d3Sr/wr4EMoSzQCgfljPjiN11xoETIlPsG+hV7Qwa7oQNe0ja2K3GCY65XWfwC1zj3xcfItWpf9dZVv5MJ12ipbgR62hX2blvEJeYVin0QCaEvY4Hn1eX5baKn6kUNYmLejKgiiVNDAvswSIAifJLoxajO70NlUijxYXmOeA3Ons9pPk0mO+29DSSrabFfXOA6JF1BviJZD96TdFGt/+SExyMqcw+07sKqmgdbgc2usUX2zdWKGZd8BdYVOdIbtNFAYY09Xl10o05aPEY0kLlYpcCxtE2e8JwgOSLiB9qGyyZSTkqMIIuYn27grNtTH2NYUURNNKB6ZyyfeDuMuoEKPUFiSPBN1wSA2VTh/EzzbeDWhV6tje843ImjwfaowJlsAmOFR11IBNTkTvZZge3jX7vBP1Z5mEYtRsX5zW4zl5/FGGz2H9j5/aCqmi0WxxtvUjBL+6TZN4iJpF3a5Ps/wIxxJLBJDU0qTypKvyxfAViCKqt2PUJYKJBmTt971bBNelFDa0Fn+fkhprkfgfK0ti9bICTgtbwlRADLrwTyOkIRbB04gd8iyY6rnAAPngXNWkyfruFlNgpZFVPTLVXHTzhMz86gA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA1PR03MB6499.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39850400004)(136003)(366004)(346002)(376002)(8676002)(186003)(4326008)(26005)(52536014)(66446008)(64756008)(8936002)(66946007)(45080400002)(91956017)(83380400001)(9686003)(66476007)(66556008)(76116006)(166002)(7696005)(54906003)(478600001)(71200400001)(966005)(38100700002)(55016002)(316002)(110136005)(5660300002)(86362001)(2906002)(33656002)(6506007)(53546011)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kl4sWqzfQu+r7V7g8mdsLtbHQLRw+pLpwfmKPoLncNJzFn10WOWNuGAjF4VT?= =?us-ascii?Q?Ufz/IRKasANCAbkOnsshdnzkiPEr43lFljwe/8UUKjf3S5mzXPQnVZhD65DB?= =?us-ascii?Q?8h1+e80i/OsDbw/k/cR0pJpYYUME4QUtTBNxpmb6GMAdINJqTvMwcu68bKXc?= =?us-ascii?Q?V6dZzYdZrBthClQ0Y6kDkA0Bf68BnxLpYNuJwyBtJwvXvQy0OW7yNjSEJqb9?= =?us-ascii?Q?zSZWwOIIKKgb/Tm0Z5ZC9QsU2cxyZcONCD9pmWr2Bb3xUINeyttqBB0p9NoE?= =?us-ascii?Q?GL4/eRwX20hBjnypbsK7MuzRyM2yDsN05z29HC7jR2gKmQBKhJ5rWAkUY86P?= =?us-ascii?Q?H8LHQeF/e9QQQynBjOMM4UNG8QCrR5M6+52K26acici/IyPs7maOiR1AHYtq?= =?us-ascii?Q?aQsxJ9Knl1dH9eb7Y6pRSDzkz52KrDBWTdUbSQF2+exxwGhXKDu8dFvdMbuR?= =?us-ascii?Q?8tSQUJmr57rlOx9lKRoNgOvZfDK4ZJuFKdbO/t7v8dXMznK0M6iDNZelwCba?= =?us-ascii?Q?0+KDY7+HBGzBXmeR41fAfFyfyF7EkLPwi8BZdzgO2scvctWFG3H+SH8uMNG/?= =?us-ascii?Q?fBnx3S9HaWfrO76UgYIvDR/3yDxOGKBtGq53BlE3+cMb+QGoqkwmE9TrZMgX?= =?us-ascii?Q?P6nyXHpdaW2FHQrMq3nuje76J7OlCaXPPkbmtgX4urDTosxK9lCGNaMZf1wq?= =?us-ascii?Q?XsP6VP1C3wSIKuueDiN5d2r2arDjCPUBmFKQk1tLcTVNmdjgRLXWG/71eFY7?= =?us-ascii?Q?2VN6A88atczxesOyIgOUGp07lnS4dC0foBpFZxk5SywyuIS6QDk/Y3Oh3Yvy?= =?us-ascii?Q?1bboUGb/PlRGuhpNmGBy9Vx8ZrE84FEZyerUwoaFAU0S8xXt+EvImMumIwf5?= =?us-ascii?Q?+kO0AvIsv/1LKmu88hyNE1U8sPHZefMcclOUpGMpoQ9Op2nzMhgZUmhSIkkb?= =?us-ascii?Q?NnEtwE5bURha31co7zLDG05Qpwn1Kzy7WYMLHmoFp3VrfI8TCkrvcg85peOM?= =?us-ascii?Q?Zcw6cNtH7ePHsOdu+1sTjrCzR2Bbp8i3DCuyqwrurYejs50hlICiBqWeSqBD?= =?us-ascii?Q?vXMKI7Aq605FMbZxy/Yo2myoTKU0xfn5AiNSMVcEUM0z667saIowwHHFf7FE?= =?us-ascii?Q?TmWCpxu4w2q5Eb/c8m3pLJ8qO0mj5I6etSCl5dU1ssaB3opeHM+cO2dKfeYG?= =?us-ascii?Q?eKBCgWtc9Oy/JQ33N35aHv64qteUsE6wrbNZB52c9ZusENjrEzwBhnUaSr95?= =?us-ascii?Q?kon/JUywb1SIC4Iko6gqYBQ/ihTEUmh0v2yNkh3ycs9CraF7AHWtHA31yxxF?= =?us-ascii?Q?yZmOlyPz3kekR3u8RZ+81rgOALXHooGNxDH6HsKc6htVeg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA1PR03MB649903FB333E04FCE26EDE09F6369SA1PR03MB6499namp_" MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA1PR03MB6499.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ffbf029b-41b4-4951-b0fd-08d92b364b6a X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2021 11:04:04.1873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aRyZa+h9OWJdMAQbJGWhJRWOPadWiPowXZwbelShp5yBQc+5iIexfQIewH0dnVbaL5Q7LEOsFx5fiwRmXJ7gEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR03MB6531 Archived-At: Subject: Re: [Pals] [EXTERNAL] Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 11:04:17 -0000 --_000_SA1PR03MB649903FB333E04FCE26EDE09F6369SA1PR03MB6499namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I mainly concur with Stewart's comments about sequence number checking. However, there are two domains (not sure if they could bd called niches ir= not) where it is always pesent and critically imporrant: 1. One such domain is TDM PWs where srquence numbers are used to detect= lost PW packets and generate correct smount if "replacement" bits at egre= ss.AFAIK they are still widely deployed 2. Another (and relatively new one) domain is Detnet where sequence num= bers are used by the Packet/Frame Replication Elimination Function (PREF/F= REF). AFAIK in both cases dedicated HW is required. My 2c Get Outlook for Android ________________________________ From: Pals on behalf of Stewart Bryant Sent: Wednesday, June 9, 2021, 13:23 To: Andrew G. Malis; mark@townsley.net Cc: Carlos Pignataro (cpignata); Ignacio Goyret; intarea IETF list; Derek = Fawcus; pals@ietf.org; Stewart Bryant Subject: [EXTERNAL] Re: [Pals] [Int-area] L2TP sequencing: Commonly disabl= ed for IP data? Or always? Sequence number checking in the forwarder is always a problem because it i= s stateful so I doubt that many high-scale or high-speed forwarders ever d= id this. I think there is an undisclosed assumption that go up enough levels and it= s IP so sequence number checking in the transport network (as opposed to t= he 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 int= ended 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 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 pse= udowire data, such as Ethernet frames (see RFC 4719 for example). Even tho= ugh 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 specif= ically mentioned IP data. But it is a case where you would probably see se= quencing in use. Back in the day, Sprint made good use of Ethernet over L2TPv3, as they wer= e 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=20requires 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://clicktime.symantec.com/3TrwYm64nkihRWfK7Da9QhH6H2?u=3Dhttps%3A%2F%= 2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area Notice: This e-mail together with any attachments may contain information = of Ribbon Communications Inc. and its Affiliates that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, dis= closure, reliance or distribution by others or forwarding without express = permission is strictly prohibited. If you are not the intended recipient, = please notify the sender immediately and then delete all copies, including= any attachments. Notice: This e-mail together with any attachments may contain information = of Ribbon Communications Inc. and its Affiliates that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, dis= closure, reliance or distribution by others or forwarding without express = permission is strictly prohibited. If you are not the intended recipient, = please notify the sender immediately and then delete all copies, including= any attachments. --_000_SA1PR03MB649903FB333E04FCE26EDE09F6369SA1PR03MB6499namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
I mainly concur with Stewart's comments about sequence number checking.
However, there are two domains (not sure if they could bd called niches ir= not) where it is always pesent and critically imporrant:
  1. One such domain is TDM PWs where srquence numbers are used to detect l= ost PW packets and generate correct smount if "replacement" bits= at egress.AFAIK they are still widely deployed
  2. Another (and relat= ively new one) domain is Detnet where sequence numbers are used by the Pac= ket/Frame Replication Elimination Function (PREF/FREF).
AFAIK in both cases dedicated HW is required.

My 2c




From: Pals <pals-bounces@iet= f.org> on behalf of Stewart Bryant <stewart.bryant@gmail.com>
= Sent: Wednesday, June 9, 2021, 13:23
To: Andrew G. Malis; mark@townsley.net
Cc: Carlos Pignataro (cpignata); Ignacio Goyret; intarea = IETF list; Derek Fawcus; pals@ietf.org; Stewart Bryant
Subject: [EXTERNAL] Re: [Pals] [Int-area] L2TP sequencing= : Commonly disabled for IP data? Or always?

Sequence number checking in the forwarder is always a problem because it i= s stateful so I doubt that many high-scale or high-speed forwarders ever d= id 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 became niche w= ith, as Andy says, operators who did not want MPLS. Much of what L2TPv3 wa= s 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 c= all.
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 47= 19 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 ment= ioned IP data. But it is a case where you would probably see sequenci= ng in use.

Back in the= day, Sprint made good use of Ethernet over L2TPv3, as they were in the an= ti-MPLS camp at the time. But that's water over the bridge, and I really d= on't know if this solution continues to be in active use. Mark Townsley mi= ght know.

Cheers,
Andy=


On Sat, Jun 5, 2021 at 10:07 AM Dere= k 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? <= br class=3D""> > Also, are you aware of any other types of tunnel that might try to ke= ep
> 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:

 =20"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 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://clicktime.symantec.com/3TrwYm64nkihRWfK7Da9QhH6H2?u=3Dhttps%3A%2F%= 2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-area


Notice: This e-mail together with any attachments may contain information = of Ribbon Communications Inc. and its Affiliates that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, dis= closure, reliance or distribution by others or forwarding without express permission is strictly prohibited. I= f you are not the intended recipient, please notify the sender immediately= and then delete all copies, including any attachments.


Notice: This e-mail together with any attachments may contain information = of Ribbon Communications Inc. and its Affiliates that is confidential and/= or proprietary for the sole use of the intended recipient. Any review, dis= closure, reliance or distribution by others or forwarding without express = permission is strictly prohibited. If you are not the intended recipient, = please notify the sender immediately and then delete all copies, including= any attachments.
--_000_SA1PR03MB649903FB333E04FCE26EDE09F6369SA1PR03MB6499namp_-- From nobody Wed Jun 9 04:20:00 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:42:59 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6813A1080; Wed, 9 Jun 2021 04:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 892AqTmR7fHX; Wed, 9 Jun 2021 04:42:52 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82773A107E; Wed, 9 Jun 2021 04:42:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4G0QG43Jzwz6GB7J; Wed, 9 Jun 2021 04:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1623238972; bh=VftsKc3ItP1EwHOgjyaDqP9zjvmgecQUu7w6j6Q6csQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=d8gVDWZnyXdD03G4TvZkM5zc2YV9rUcpbUl6Mqn3b/724pGNei8xkD7yokByLceH/ XBzgAFUGSAGe5wcKQ4sL3IJZWpkJDQ/I4KJcwwDH1Chy7V7EZnUJW0SQi1wF0q3fS5 5LbUyX1iEpxw/0wYOAfuVZrB9xPwDz7fD8SpJB0M= X-Quarantine-ID: 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:38 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 11:48:33 -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:12 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:48 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [EXTERNAL] Re: [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 11:53:46 -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:23 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:31 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:22 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:10 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:14 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8543A1FD3; Wed, 9 Jun 2021 10:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIOkWsK6-Fbg; Wed, 9 Jun 2021 10:40:55 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2078.outbound.protection.outlook.com [40.107.92.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E06E3A1FCE; Wed, 9 Jun 2021 10:40:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NUX1zRYc5TBdPcBCDAwlhLeN+g+wWKmErf8229mqVlHiztS3RS+4e32HJVXoyvjp4xM696NWv+YYj+llB5XfsMF+ZAe69Zk9hMl+urrbQ86RmzmMe/dyxOV7fCEArcmgeXQiSrk5BHasS1vaeSxcneTPjXV/Qjmrp7s82wUGWncvykW1Q1a8iweibXXssIQekPqBGzR0r9AO3dmsFj7CFylgTe2dmCGqhVJO4aLMpx2f63fXZe7qjiq7WB7kFKof6c55uffNIijolAtb7BY6AoeMguvJtGXPApoNKZkgVKkoClfOZgZiWA9ueO4Dbnk2/7wH6kQ82OgUQovgRsVG4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E6h6GyGUgIJpC3gFdNcBkllNvZsGHM9ydHc2CjUpvA0=; b=dWFYcsth4rmy5+SOyiT346u9YmBAGaapeTNuR4Znj7Wtg9uFjA7jvsQub0ecYTdb+wQWjTU2a5uc/reSBK4KDSUkmJERh/IWROoSsPe7iKeCsepd5j+mcy3tXPvB8ovC7+J70ojZcmRfPrTGCGNjM7/L3dm92kJhVMCUfBx+JHqLLYZh6UVrbq7cNjwkfQZCfKcNb5vqWEGBXNjE4fGLZDbawBxkwgTKnm0VCPiQwcZ2k2wnp7kd+DlttjhZsG8yr9F/4DglWT7oirWBwIYWRY/7psfHQycS9IS952GxM0NCCxVQ+R6FLPLMsqKXwqDPqoh3tkmAwhG4DweHUuyByQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E6h6GyGUgIJpC3gFdNcBkllNvZsGHM9ydHc2CjUpvA0=; b=aE+xoh2YpDOWW7s5vOaIlbYXfwoxzQVHNhDx8FjIJuXulI9sUWmS3wjzpmuDxwgNezd2Mk5kXWYmunzASRTFdyAOcxmV10lM493/t2xSY1SPezuojQA/kcj0xU9ScUWaurCu7nsJW7NvWdp2OH7FppucJuDmZibhf+PWcUQzgmM= Received: from MW4PR15MB4474.namprd15.prod.outlook.com (2603:10b6:303:103::8) by MWHPR15MB1630.namprd15.prod.outlook.com (2603:10b6:300:11b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21; Wed, 9 Jun 2021 17:40:53 +0000 Received: from MW4PR15MB4474.namprd15.prod.outlook.com ([fe80::f12b:6996:419b:e084]) by MW4PR15MB4474.namprd15.prod.outlook.com ([fe80::f12b:6996:419b:e084%6]) with mapi id 15.20.4195.030; Wed, 9 Jun 2021 17:40:53 +0000 From: David Allan I 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:42 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324083A28D7 for ; Wed, 9 Jun 2021 15:32:36 -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=unavailable 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 6I2B43o6db0S for ; Wed, 9 Jun 2021 15:32:29 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 5A7E53A28D2 for ; Wed, 9 Jun 2021 15:32:29 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id go18-20020a17090b03d2b029016e4ae973f7so1479999pjb.0 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=PIihTh241UY6NJO6DmFv67igyn7SSb0dpfDfZh7+yj4MR2lDKiB5nnT0ooqMqRNLD8 lRVokCl6upmKQyA9DzN0WSgH6ggO6yel2KmTe9hltdu+P5xIfgRmx5ICaUOyOLEH3Z7T +cObwpKsIPivo5dLOlLu2D87irciuHmQZYi/I7+Kzy+Qb8//EaGVeGATy3ESz1dt0xCd NFrRZWa8v5HjaMttQbsA/dz4Rg8B2yRfOvZChdsVTNy1Vs3LExVJgeQvUvrsRf0Xt4/t MheTuQ8gCc2YP8fMAk96ZmH2R0Np90PibkqAm6nZ204/kPXP2NPLyYsmXdhT524vqm7j vcfA== X-Gm-Message-State: AOAM533QpiohK2/IrDdTjncfAj7v9YJOmokcjpNJEf49oJ41j4ez+1+o /eeX79Eks/29oG4lH2SKQazg2A== 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 22:32:36 -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:42:05 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B697E3A0D3E; Thu, 10 Jun 2021 04:42:02 -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 juvEEiN7QsVh; Thu, 10 Jun 2021 04:41:58 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 3B6EC3A0D3F; Thu, 10 Jun 2021 04:41:58 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id o20so5265393qtr.8; Thu, 10 Jun 2021 04:41:58 -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=h9q4xIcReW5LAHjpSlJbB8FdCP1Ss3FKvMiS0wd/WTc=; b=vHZUCcrJYw4E6UhUsLFpOqgPWaXiISXZznKEnKJe5Jxs3J9MkR/qdZfaWbmI50Xmhi Jc82QoX0kfF60Of8klV2ufEsRoZnCRS5dTKMwYRs35ZuB0DYyM0xzaYP6Ajm5XdbnMrl h1XKW0SD89sqFofOhTVKCP/WobeyqLdkYZXEWxpnA7dN2z1rUoJhtJmqhBql68946MHt 7FEOSreJ5NmYyylBNPLge50tWNO+UVMbWr6sjwE85v3YKnzOMRAqLjHA28y0UK/W4vxM okVbfhNtqg6SvJvVa/iAVOkMEiQJA+HmGCE758n/P5y9jgisLj2vIo24W7N43QgIEBDp Gj/A== 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=h9q4xIcReW5LAHjpSlJbB8FdCP1Ss3FKvMiS0wd/WTc=; b=XvN0ly9UU1fZdCQmFJwsoqBzNdSUU4AoID0lJWM+Txloceht0MLHZ5clYc+/2qkq7x fXGzTE3KncBJVAtktq0oKfbJeASh3icz6wKxS7E/EsHMxKcNvFkVgLtPlyv7mdF/q6v0 /yNMrA9nRjbzmZtI7QjQ5y1VwCfurR+cBw8EVq0WDPjFCOA1dbG/DNh82TG7mgtHwr67 SnZ2MSp1VPyWCJ5GMTJLmjmRw8lWNNrnLco7wUXZkLvHoxevGl1m0dpqAKHG9GxP/ql8 5Gi27ePasCtjkT/SiCs4sp0JqoCWCAUROBTWX4IP7aCJ02m9CO3OD8Y4C/wUxnGE1IS2 ug/w== X-Gm-Message-State: AOAM531mC8dOMikbky2SEtBO77HQzq2mmMMqjavebCpFfP0bjCxFgBRK Rk6erNUsyBi0ZMCLhUObMzYCRwSO+K6bp3U0CG0= X-Google-Smtp-Source: ABdhPJxEZz5lgMMF6nWXKs3Cp6sSH3HuOlZCSVsdpsmz2X7Oyk7zcw+9SAxX02qXLPeqy5T1BlxFAc54bZJ2U+PZiec= X-Received: by 2002:a05:622a:40b:: with SMTP id n11mr4594222qtx.60.1623325316163; Thu, 10 Jun 2021 04:41:56 -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:41:40 -0400 Message-ID: To: Mark Townsley Cc: Stewart Bryant , Joel Halpern , Carlos Pignataro , Ignacio Goyret , intarea IETF list , Derek Fawcus , pals@ietf.org, Joel Halpern Direct , Bob Briscoe Content-Type: multipart/alternative; boundary="000000000000d32a2805c467e07e" Archived-At: Subject: Re: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 11:42:03 -0000 --000000000000d32a2805c467e07e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 > > --000000000000d32a2805c467e07e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mark,

The original question was, how ma= ny (if any) of these L2TPv2 and v3 use cases use sequencing, especially whe= n 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 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

--000000000000d32a2805c467e07e-- From nobody Thu Jun 10 04:49:45 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:46 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:11 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 12:23:06 -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 Sun Jun 27 14:22:25 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:51 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:54 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:54 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:30 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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 11:46:24 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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 03:02:24 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:13 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:31 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 11:41:25 -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:55:59 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: Subject: Re: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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:17:11 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F413A3921; Tue, 29 Jun 2021 09:17:08 -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 UAXgC66X3g3u; Tue, 29 Jun 2021 09:17:03 -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 CD6273A391E; Tue, 29 Jun 2021 09:17:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)); envelope-from=173.38.220.34; From: Giles Heron Message-Id: <519F0CB1-C9CF-4EA6-95A9-7D58078A386C@layerfree.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_F370DD9E-3954-459A-8EDE-5A607D53DDD5" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 29 Jun 2021 17:16:53 +0100 In-Reply-To: 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> 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=2, out=0, spam=0 ip=HiddenIP Archived-At: Subject: Re: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 16:17:09 -0000 --Apple-Mail=_F370DD9E-3954-459A-8EDE-5A607D53DDD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bob, > 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=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 > [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 = 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 ;) > 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 >>=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 >>>>> > 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/ = >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ = --Apple-Mail=_F370DD9E-3954-459A-8EDE-5A607D53DDD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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




> 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


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


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

= --Apple-Mail=_F370DD9E-3954-459A-8EDE-5A607D53DDD5-- From nobody Tue Jun 29 09:23:35 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always? X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." 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-- From nobody Wed Jun 30 11:23:31 2021 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82093A258A; Wed, 30 Jun 2021 11:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, 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 Ichj8A1ueZhV; Wed, 30 Jun 2021 11:23:16 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 DAC943A2588; Wed, 30 Jun 2021 11:23:15 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id a18so6796189lfs.10; Wed, 30 Jun 2021 11:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=LA78EC1KGWiQkY3IPUkCXDXx2pVw2m0rDTkDTOih2W4=; b=r8zotyN4STYREmfH236hH/s1+kKObCSeIcEAtuRd91MH5pTAvdgZ6B2tji/MZaOEhl zKtHADXzsaNtcPMB8j5StLwp4yEwa2K17LAI7a1ZwtE4yTQOZXFXstCspQYvL2YXCyGt GzCQzY3nzkmRNxeYKkdOND8oavk12Rmt7VDgSqt8Sk5yWpm8VnYn2md/6XvlU1IBmW/I H0Yx8XQzQZhOofuZe8YgUoAhlusewLFPD296pLbiu0SSbhFpCwM5MaXnDvmAoPINBL5h FwoHzDZg/IpeeHU67vrYG6lKzHMvepezsvV3hTR4L1oozW5LyyAoDmt15igaFEmLF2aE 7v4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=LA78EC1KGWiQkY3IPUkCXDXx2pVw2m0rDTkDTOih2W4=; b=MmQkqnsctgUEmrn5AwdVP7ikw0BHxFAbqwBVyKmyOf9IMe9C0mqMQplnjrs9Q4oGjy rIIVEbOLCEHk+hLRXmZL4QMJKDUFIK7ooDVeL1/+uhCxqaHHMxDIuuYKzSmGiPT+1pop ujZIw+drdENflQQ1Eh2X1Di0TF0CcVDM+9DGO5bFtTgNie5swtr9jQ4Apxqcr2l+a5ka zC1MrLNZAMSvh3944QcUgg3LnJrtJ89cnbI1Kiua/qIFrKdJsCouNnWDhF1mjRyWjTHM 0UXFGwd3Tv4kHUc7qj3YbMY4KU6QoLY2ZoSM6eeEieOizF+w2Ef1r+IUOS7xOjTQD7vk 7MyQ== X-Gm-Message-State: AOAM531BPKK4staRhHVKsfagkH6fipo8RXLq5+t7C2pVWHWDpPSg8Zds ZiQGi8Gj0J4ztnW3ggJCyOEcxpeu9o3a6PTxqUlucGIEI+AtPQ== X-Google-Smtp-Source: ABdhPJxBrvKJ7J1r8LRwyRB6TI0IKiUP2urkuP9Vg2ic79bmY3ZvjzrR/sQA2gVG+pQCijK7Yst/SOkTFgXzr2jIsrY= X-Received: by 2002:a19:f51a:: with SMTP id j26mr29266026lfb.390.1625077392800; Wed, 30 Jun 2021 11:23:12 -0700 (PDT) MIME-Version: 1.0 Reply-To: david.sinicrope@gmail.com From: David Sinicrope Date: Wed, 30 Jun 2021 14:23:01 -0400 Message-ID: To: pals@ietf.org, mpls@ietf.org, detnet@ietf.org Content-Type: multipart/alternative; boundary="000000000000baff9605c5ffd0af" Archived-At: Subject: [Pals] IETF 111 PALS, MPLS, DETNET Joint Session - Slot Request X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2021 18:23:21 -0000 --000000000000baff9605c5ffd0af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, The draft agenda for IETF111 has been posted - https://datatracker.ietf.org/meeting/111/agenda PALS has a joint session with the MPLS and DetNet WGs, focusing on cross-gr= oup MPLS issues: TUESDAY, July 27, 2021 Session III Start: 16:00 PDT/19:00 EDT/23:00 UTC Room 6 RTG pals Pseudowire And LDP-enabled Services WG - Joint PALS/MPLS/DetNet The PALS chairs and I(PALS Secretary)are coordinating the agenda for this session. This will be a fully remote meeting. Our plan is to focus on summarizing progress from the Open MPLS Design Team, updates and progress on the cross-group MPLS issues. Please send slot requests via *reply to this email* (i.e., to david.sinicrope@gmail.com) *with the Subject intact* before the end of the day Sunday, July 11 (any TZ). Please include the following in your request= : 1. Topic: (e.g., =E2=80=9CPW Control Word Stitching=E2=80=9D) 2. URL to your draft on Datatracker: you only need to provide the file name to the example URL (e.g., =E2=80=9C http://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth-oam-iwk/=E2=80=9D)= : 3. Brief statement of objectives and issues to be discussed and resolved via the presentation during the meeting: (e.g., =E2=80=9CGather interest from the WG to work on this solution=E2=80=9D) 4. Requested duration: (norm/default is 10 min): =E2=80=9C20 min=E2=80=9D 5. Speaker name: (e.g., =E2=80=9CDave SINICROPE=E2=80=9D): Thank you! Dave Sinicrope PALS Secretary david.sinicrope@gmail.com --000000000000baff9605c5ffd0af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi All,


The draft agenda for IETF111 has been posted -

https://datatracke= r.ietf.org/meeting/111/agenda


PALS has a joint session with the M= PLS and DetNet WGs, focusing on cross-group MPLS issues:


TUESDAY, July 27, 2= 021 Session III=C2=A0

Start: 16:00 PDT/19:00 = EDT/23:00 UTC

Room 6=C2=A0 RTG pals=C2=A0 Pseudowire And LDP-enabled Service= s WG - Joint PALS/MPLS/DetNet


The PALS chairs and I(PALS Secretary)ar= e coordinating the agenda for this session.


This will be a fully remo= te meeting.=C2=A0 Our plan is to focus on summarizing progress from the Ope= n MPLS Design Team, updates and progress on the cross-group MPLS issues.


Please send slot requests via reply to this email (i.e., to david.sinicrope@gmail.com) = with the Subject intact before the end of the day Sunday, July 11 (any TZ).=C2= =A0 Please include the following in your request:


1. Topic: (e.g., =E2=80=9CPW= Control Word Stitching=E2=80=9D)

=C2=A0

2. URL to your draft on Data= tracker: you only need to provide the file name to the example URL (e.g., = =E2=80=9Chttp://datatracker.ietf.org/doc/draft-ietf-pwe3-mpls-eth-oam-iw= k/=E2=80=9D):=C2=A0=C2=A0=C2=A0


3. Brief statement of objectives = and issues to be discussed and resolved via the presentation during the mee= ting:=C2=A0 (e.g.,

=E2=80=9CGather interest from the WG to work on this s= olution=E2=80=9D)

=C2=A0

4. Requested duration: (norm/default is 10 min= ): =E2=80=9C20 min=E2=80=9D

=C2=A0

5. Speaker name: <Given-name FAMI= LY-NAME-IN-ALL-CAPS> (e.g., =E2=80=9CDave SINICROPE=E2=80=9D):=C2=A0=C2= =A0


Thank you!

Dave Sinicrope

PALS Secretary

--000000000000baff9605c5ffd0af--