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

Bob Briscoe <ietf@bobbriscoe.net> Tue, 30 May 2017 22:49 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 24B9F120726 for <l2tpext@ietfa.amsl.com>; Tue, 30 May 2017 15:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.874
X-Spam-Level:
X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 cpktBXkQby1p for <l2tpext@ietfa.amsl.com>; Tue, 30 May 2017 15:49:53 -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 E152B1200CF for <l2tpext@ietf.org>; Tue, 30 May 2017 15:49:52 -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:References:Cc:To:Subject:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4w0gVFG5UNdP8adFY4rj56tZdiJgmd7cib/WaU793co=; b=3N2XbOugA9J2PmUiy47VMf5Pv C4St2BMcox/sZ+2TXqqAxxHzKTQWq0jAy0i/SncuMcZg8lTv0MHY97zkQscxUkZTcE3W8jv423l6G 8cKCzKC+cj0hjR+IcfMjcpMpuo30WLTNkuRctNmSfm6jp+nOPrthtc8fg0bINp9fyPjVBIc7jC2Wc QTXIzMM/SxEGPrBU6Hhj+zQoy1frJYcA/fMfX4MaK1Qhzko5Y4oE1EUlzc/fcoHuHbNbZmz2JEUK0 BDp9rJ9bXWTtynITW4Zp9smtGsTwVb1tcEYlfn+22PGPgaiQebdGhvkLjJeBNSz4suULl3Lfe5W6C woZGQm4Hg==;
Received: from 197.74.9.51.dyn.plus.net ([51.9.74.197]:58346 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 1dFpxX-0003K0-7V; Tue, 30 May 2017 23:49:51 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: l2tp IETF list <l2tpext@ietf.org>
Cc: "Black, David" <david.black@emc.com>
References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com> <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net>
Message-ID: <e4c97c52-36c9-3091-b005-06ef82ec58e3@bobbriscoe.net>
Date: Tue, 30 May 2017 23:49:50 +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: <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net>
Content-Type: multipart/alternative; boundary="------------DED98231FE9FC0CE0323F37C"
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/GnT7Q7tILSffolUNOF299iohvZ8>
Subject: [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: Tue, 30 May 2017 22:49:55 -0000

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:
draft-ietf-tsvwg-rfc6040update-shim-01 
<https://tools.ietf.org/html/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 S.4.5 of RFC3931 <Specific%20questions:>, 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.



On 30/05/17 22:49, Bob Briscoe wrote:
> David (as doc shepherd) and the tsvwg list,
>
> As requested, I have added specific text that updates the other 
> relevant RFCs under IETF change control (GRE and L2TP). I have also 
> explained the position in each case for specs not under IETF change 
> control.
>
> I will now go to the relevant WGs (intarea and lt2pext) and ask them 
> to improve my first attempt.
>
> I'll cc you and this list as appropriate.
>
> Cheers
>
>
>
> Bob
>
> PS. I have also said
>
>    the rules in [RFC6040] for
>    propagating the ECN field MUST be applied
>
> whereas before it said "SHOULD". And added an explanation for why 
> "MUST" is appropriate:
>
>    The above is written as a 'MUST' because RFC 6040 allows
>    a compatibility mode for the encapsulator in cases where the
>    decapsulator does not (or cannot) support ECN propagation.
>
>
>
>
>
>
> On 30/05/17 22:36, internet-drafts@ietf.org wrote:
>> A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-01.txt
>> has been successfully submitted by Bob Briscoe and posted to the
>> IETF repository.
>>
>> Name:        draft-ietf-tsvwg-rfc6040update-shim
>> Revision:    01
>> Title:        Propagating Explicit Congestion Notification Across IP 
>> Tunnel Headers Separated by a Shim
>> Document date:    2017-05-30
>> Group:        tsvwg
>> Pages:        10
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>> Htmlized: 
>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01
>> Diff: 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01
>>
>> Abstract:
>>     RFC 6040 on "Tunnelling of Explicit Congestion Notification" made 
>> the
>>     rules for propagation of ECN consistent for all forms of IP in IP
>>     tunnel.  This specification extends the scope of RFC 6040 to include
>>     tunnels where two IP headers are separated by at least one shim
>>     header that is not sufficient on its own for packet forwarding.
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/