Re: [L2tpext] Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN

Bob Briscoe <ietf@bobbriscoe.net> Wed, 31 May 2017 02:48 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: l2tpext@ietfa.amsl.com
Delivered-To: l2tpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2AD126DC2 for <l2tpext@ietfa.amsl.com>; Tue, 30 May 2017 19:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 p579cD4jRcf0 for <l2tpext@ietfa.amsl.com>; Tue, 30 May 2017 19:48:00 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 4B91E126BF6 for <l2tpext@ietf.org>; Tue, 30 May 2017 19:48:00 -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:Cc:To:Subject:Sender :Reply-To: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=C8XX+x1XiT773FnceDh0g6+PfK4hEIgicXGKjhEwdNI=; b=xajiSpGuJkWGyZhKLzGHzeTcaI B2szpRKLNAjhenNhygj7faBy/ER96SzXa1JeNQobWjkcmRzdFDsvHfjp0JBToD4l9MMz7GX1vO1iI eVfnn0njtWLq+ABJA6BSohxMWRzaQCWBywUDuCIeulBtCh30ZfXgJ07ogOhvWckbAgThh2ltD6V/H hUZIMiwClLg/XiRjhk3DH9ll8SqwKzekbVuTRoUgkLyUBda+jqkIteKkDhbqCYlpIAje3FRMH0c7E V6y6gKu3P7RkidOvFN411sduqMNUkTtgKUapreyiA1YJCUtywdQh4FZGMqlW3epreU8xCqVQbpmcG qLbNVAxg==;
Received: from [31.185.135.175] (port=60178 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <ietf@bobbriscoe.net>) id 1dFtfy-0001Kw-Gk; Wed, 31 May 2017 03:47:58 +0100
To: Ignacio Goyret <ignacio.goyret@nokia.com>
Cc: l2tp IETF list <l2tpext@ietf.org>, "Black, David" <david.black@emc.com>
References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com> <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net> <e4c97c52-36c9-3091-b005-06ef82ec58e3@bobbriscoe.net> <201705310154.v4V1sYQH013223@cliff.eng.ascend.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <67456091-a3e0-2db1-5f8a-5210a1f870f1@bobbriscoe.net>
Date: Wed, 31 May 2017 03:47:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <201705310154.v4V1sYQH013223@cliff.eng.ascend.com>
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 - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2tpext/PpM64rKy7-PfobFzQEzMUiYxaUY>
Subject: Re: [L2tpext] Propagating IP/ECN field when L2TP sits between IP as both L2 payload and PSN
X-BeenThere: l2tpext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Layer Two Tunneling Protocol Extensions <l2tpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2tpext/>
List-Post: <mailto:l2tpext@ietf.org>
List-Help: <mailto:l2tpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2tpext>, <mailto:l2tpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2017 02:48:03 -0000

Ignacio,

Thanks for your rapid response.

On 31/05/17 02:51, Ignacio Goyret wrote:
> I am a little confused by the double negative in "non-optional".
> Do you mean "mandatory"? If so, why not just say that?
Yes, mandatory.
That language was not in the draft; only in my email.
>
> The lack of a capabilities AVP that you were looking for is mainly
> because it hasn't been needed so far. You are welcome to submit a
> draft with something like that. Generally speaking, adding a simple
> binary AVP is easy and simpler to handle.
Good.
>
> I have no problem with the new suggested AVP, but can you explain
> why is it important to know if the remote supports or not this
> extension? Can't a tunnel end deduce this information by observing
> the IP header received?
I'm afraid not. It is critical for the ingress (in each direction) to 
check that the egress decap will correctly propagate the outer ECN field 
into the forwarded payload protocol. Otherwise explicit congestion 
signals added by a node within the tunnel could just get stripped at 
decap. With congestion feedback black-holed, the load would continue to 
increase until overload and tail drop.

BTW, the forwarded ECN field after decap has to be a combination of the 
ECN fields in the outer and inner IP headers (RFC6040 gives a 4x4 matrix 
of all the combinations of the two 2-bit ECN codepoints). So I am 
interested to know whether this might present problems for L2TP 
implementations (ECN propagation on decap has been implemented OK in 
Linux for similar structures like VXLAN).

>
> Regarding the extension vs update question: if it is an update,
> then why negotiate support? Wouldn't ECN propagation be mandated
> by this update?
Unfortunately, a mandatory update still has to cope with the above 
incremental deployment problem.
>
> There is no section for L2TPv2 (RFC2661) or any further suggestion
> on how to handle it. I'm not saying that it is necessary, but since
> it is mentioned earlier in the document, you may want to add a few
> words. Note that things are a bit more complicated in v2 because
> it transports PPP packets, which may include IP packets (or portions
> of PPP packets if using Multilink). I have no issue punting on L2TPv2
> details.
* Given you say L2TPv2 is more complicated cos it transports PPP 
packets, that seems to imply that L2TPv3 does not transport PPP, which 
doesn't sound right?

I don't fully understand the relationship between L2TPv2 & v3 (I have 
come across L2TP a lot in an operational context, but never really 
studied it as a protocol until now).

* Is there still a lot of L2TPv2 around?

* Would it be believable that a L2TPv2 implementation might be updated 
for ECN support but not updated to L2TPv3?

Cheers


Bob

>
> -Ignacio
>
>
> At 15:49 5/30/2017, Bob Briscoe wrote:
>
>> Hi l2tpext list,
>> [repeating previous post, but with self-explanatory subject line]
>>
>> This is a plea for help on a short subsection of a short draft that updates L2TP (amongst other tunnel protocols).
>>
>> In the Transport Area WG (tsvwg) we have been working on defining propagation of the ECN field between IP headers separated by shim header(s):
>>     draft-ietf-tsvwg-rfc6040update-shim
>>
>> L2TP is one such protocol (when the payload of the L2 protocol is IP, and the outer PSN is IP). This is particularly relevant at the moment, because of the low latency (L4S) work based on ECN and because deployment of ECN has finally taken off {Note 1}.
>>
>> I presented this tunnelling work in intarea just under a year ago. Since then tsvwg has adopted the draft and asked that we include specific update text for each affected tunnel protocol. I just posted my first attempt at L2TP update text:
>>     <https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01>draft-ietf-tsvwg-rfc6040update-shim-01
>>
>> Specific questions:
>>
>> Prize for the best answer to all 3 questions: you get to become a co-author (if you want :)
>>
>> Q1. L2TP is meant for all sorts of outers and inners, so it is not clear where to define behaviour for the special (but very common) case of IP as the L2 payload and IP and as the PSN. That is:
>>      IP    :    [UDP]    :    L2TP    :    L2-specific-sublayer    :    L2    :    IP
>>
>> I decided on updating <Specific%20questions:>S.4.5 of RFC3931, but suggestions for a better place are welcome.
>>
>> Q2. L2TP is usually extended not updated. However, in this case, compliance with RFC6040 is non-optional, so I think update rather than extension is appropriate. Reason: Although RFC6040 is non-optional it includes a compatibility mode that defines what has to happen when a tunnel endpoint doesn't support ECN propagation.
>>
>> Pls read the (short) draft and, if you disagree, suggest how an extension can be non-optional.
>>
>> Q3. The tunnel initiator needs to check that the other end supports ECN propagation. I have proposed an Attribute Value Pair (AVP) for this that is effectively just a boolean choice from each end (Yes or silence). I expected to find an AVP with per-control-connection flags for tunnel endpoint capabilities that I could just extend with one more flag, but there doesn't seem to be such a thing already in L2TP. Did I miss it?
>>
>>
>> Cheers
>>
>>
>> Bob
>>
>> {Note 1}: ~70% of Web servers, ~50% of Apple client devices on fixed or WiFi access, and now increasing router deployment of ECN is appearing.

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