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

Bob Briscoe <ietf@bobbriscoe.net> Sun, 27 June 2021 23:23 UTC

Return-Path: <ietf@bobbriscoe.net>
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 <ietf@bobbriscoe.net>) id 1lxe7l-0003Du-1B; Mon, 28 Jun 2021 00:23:36 +0100
To: Giles Heron <giles@layerfree.net>, Mark Townsley <mark@townsley.net>
Cc: Carlos Pignataro <cpignata@cisco.com>, intarea IETF list <int-area@ietf.org>, pals@ietf.org, "Andrew G. Malis" <agmalis@gmail.com>
References: <5c60cc79-1552-3f52-641f-e508780227ae@bobbriscoe.net> <YLuFLq7k9akVVHWS@clarinet.employees.org> <CAA=duU2o9YKF5Sfu6VTr5+bUr1JVgaGZh=X4+BQRbMu63FqVsg@mail.gmail.com> <5E252602-F635-4DF0-8FAE-C80CF88293D9@gmail.com> <aea7a88e-cca8-b3d5-ecf4-d162471e971d@joelhalpern.com> <58F4227E-4F55-4618-9A56-E067BD31FA95@gmail.com> <190d8248-1b0a-15ad-88a1-fe6b551de640@joelhalpern.com> <50ADB293-A7EC-4574-9430-43E68073A6D1@townsley.net> <CAA=duU2g4L2ckiOjhcv8vOB1Ng6o8SnbQofVtU0JNk738eGzmg@mail.gmail.com> <4AC24C92-DD6C-4D5E-B113-0123DFD842A5@layerfree.net>
From: Bob Briscoe <ietf@bobbriscoe.net>
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: <https://mailarchive.ietf.org/arch/msg/pals/aDtKZK9llchsielp6l8OchG25SM>
Subject: Re: [Pals] [Int-area] L2TP sequencing: Commonly disabled for IP data? Or always?
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Jun 2021 23:23:45 -0000

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 
>> <mailto: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 
>> <mailto: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 <mailto: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
>>     <mailto: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> <mailto: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>
>>     <mailto:dfawcus%2Blists-int-area@employees.org
>>     <mailto:dfawcus%252Blists-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>
>>     <mailto: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>
>>     >>>>>    <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>
>>     <mailto: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
>>     <https://www.ietf.org/mailman/listinfo/int-area>
>>
>> _______________________________________________
>> Pals mailing list
>> Pals@ietf.org <mailto:Pals@ietf.org>
>> https://www.ietf.org/mailman/listinfo/pals
>

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