Which applications still use it Joel? Stewart
> On 9 Jun 2021, at 12:42, Joel M. Halpern <[email protected]> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> <[email protected] >>> <mailto:dfawcus%[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/int-area >>> <https://www.ietf.org/mailman/listinfo/int-area> >>> >>> _______________________________________________ >>> Int-area mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/int-area >> _______________________________________________ >> Int-area mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
