Re: [Int-area] Intarea review needed: short draft on ECN propagation IP-shim(s)-IP

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

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF9C126C2F; Tue, 30 May 2017 18:45:40 -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 G9voNmnD1nOW; Tue, 30 May 2017 18:45:37 -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 4C112129B36; Tue, 30 May 2017 18:45:37 -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=qIIOoEmEcLNHd6ZavkOg/XRHMnX7ByJAiRS2Zzwf/c0=; b=Ot8BBm3cBQofziM+EtPmRMRLtc /D+YVvT7C1x9PtfV5pXRc7gQReZk9bTvEtznV/XBhcMoEUFKLsS2DVaCAlmdOLx5+atczRWeYRgVY sCkS+0eCkd2Yi2mCMSEHIFWLE0fd2IRPxS8wn1J7IJQD+ZxXwxnPL32L/voga8uAm7gbXuFltSVjl 1iSuDtQLNy766vXL0FzDTpebtWGrZUGLTWl+chgefa43VDIfHgLU1Rmllgz9rnBLETRya9Bq1FO+y WnsQlnN+qDj89Onl1TWbnG5MgK+zSvf8KluwiBtRfDIkeSZnC7urHQg0WRV5ULLklNkLoMnW+FNbH wtXXPWlg==;
Received: from [31.185.135.175] (port=59888 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 1dFshb-0005r7-DV; Wed, 31 May 2017 02:45:35 +0100
To: Tom Herbert <tom@herbertland.com>
Cc: intarea IETF list <int-area@ietf.org>, "Black, David" <david.black@emc.com>, tsvwg IETF list <tsvwg@ietf.org>
References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com> <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net> <7850b9ae-7696-8f68-92fc-fd53c7529112@bobbriscoe.net> <CALx6S35dikUd++4LgEFt=ds2ZQFk87_o1esBOW7nPSLJHq3XWw@mail.gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <d425d132-a2aa-72a6-d80d-2f9e917c2d5c@bobbriscoe.net>
Date: Wed, 31 May 2017 02:45:34 +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: <CALx6S35dikUd++4LgEFt=ds2ZQFk87_o1esBOW7nPSLJHq3XWw@mail.gmail.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/int-area/PZlPVGtOcXLqRmgCewV20vOub5U>
Subject: Re: [Int-area] Intarea review needed: short draft on ECN propagation IP-shim(s)-IP
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2017 01:45:41 -0000

Tom,

On 31/05/17 00:51, Tom Herbert wrote:
> On Tue, May 30, 2017 at 4:08 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>> Intarea list,
>>
>> I presented this short draft just under a year ago in intarea. Since then it
>> has been adopted as a tsvwg work item.
>>
>> I have just added specific text to update those tunnel specs that are under
>> IETF change control (L2TP and GRE), as well as addressing non-IETF specs too
>> (VXLAN, GTP, NVGRE etc).
>>
> Hi Bob,
>
> On comment. GRE allows encapsulation of layer 2 (e.g. Ethernet, MPLS,
> etc.) and VXLAN only does encapsulation of Ethernet. I don't think
> these layer 2 headers could be considered shim headers per the draft,
> they are not removed in with the encapsulation headers and are
> routable in the layer 2 network. However, the layer 2 packet may
> contain an IP packet
You're right in all cases. After posting the draft, I also realized that 
is usually the case with L2TP as well.

One way to include all these cases in the scope of the draft is to say 
the tunnel endpoint SHOULD check the L2 payload for an IP header, even 
when the L2 header is not being added / removed. But that is rather an 
onerous requirement, don't you think? Especially given this would be 
asking the implementer to violate layering, we can only ask that it is 
done when feasible; it cannot be a hard requirement (e.g. L2 payload 
could be encrypted).

> and in at least once case (VXLAN) there is a
> recommendation to apply RFC6040 to an inner IP header.
What do you mean by "there is a recommendation"? I don't see it in RFC7348?

I am aware that the Linux code for VXLAN does ECN propagation per 
RFC6040. Perhaps that is what you're thinking of?
>
> Maybe the requirements for this scenario should be clarified? I think
> it's probably reasonable to say that ECN SHOULD be propagated in this
> case.
Yes, overnight I shall mull on how best to rephrase the scope of this, 
without too much mission creep.

Cheers


Bob
>
> Tom
>
>> I would appreciate review from someone in intarea who knows these specs
>> better than I do.
>>
>> If you know L2TP well, pls check the l2tpext list, where I have just posted
>> three L2TP-specific question.
>>
>>
>> Cheers
>>
>>
>> Bob
>>
>>
>> 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 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/