Re: [Int-area] draft-bonica-intarea-gre-mtu and ECN

Bob Briscoe <bob.briscoe@bt.com> Wed, 07 August 2013 17:42 UTC

Return-Path: <bob.briscoe@bt.com>
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 25C8411E8160 for <int-area@ietfa.amsl.com>; Wed, 7 Aug 2013 10:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.15
X-Spam-Level:
X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEMQnUTz8epG for <int-area@ietfa.amsl.com>; Wed, 7 Aug 2013 10:42:13 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id EADB111E80E2 for <int-area@ietf.org>; Wed, 7 Aug 2013 10:42:12 -0700 (PDT)
Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 7 Aug 2013 18:42:10 +0100
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 7 Aug 2013 18:42:09 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Wed, 7 Aug 2013 18:42:08 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.215.131.145]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r77Hg7l1020044; Wed, 7 Aug 2013 18:42:07 +0100
Message-ID: <201308071742.r77Hg7l1020044@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 07 Aug 2013 18:41:58 +0100
To: "Eggert, Lars" <lars@netapp.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <95E904E2-35A2-4715-AD95-2CFCDA2ECB0F@netapp.com>
References: <a4ede686715c4365b2ab88a90d43df38@BL2PR05MB243.namprd05.prod.outlook.com> <95E904E2-35A2-4715-AD95-2CFCDA2ECB0F@netapp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: Ronald Bonica <rbonica@juniper.net>, Internet Area <int-area@ietf.org>
Subject: Re: [Int-area] draft-bonica-intarea-gre-mtu and ECN
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 07 Aug 2013 17:42:21 -0000

Lars, Ron,

At 15:20 07/08/2013, Eggert, Lars wrote:
>Hi,
>
>On Aug 6, 2013, at 19:34, Ronald Bonica <rbonica@juniper.net> wrote:
> > Section 5.3 of RFC 3168 specifies procedures for handling the ECN 
> bit when reassembling fragmented packets. These rules must be 
> observed by any device that reassembles fragmented packets, 
> including tunnel egress routers. It would be reasonable to make 
> note of this in draft-bonica-intarea-gre-mtu.
>
>agreed.

+1

>You should also talk about what happens with the DSCP.

It is possible that different fragments of a packet will get 
different DSCPs (e.g. if some packets are re-marked due to being out 
of contract in a DS policer). However, RFC2474, RFC2983 (Diffserv & 
Tunnels) and RFC2597 (Diffserv AF) all fail to mention anything about 
what to do on re-assembly.

So I wouldn't open this can of worms, given no-one else has. It 
probably doesn't matter greatly which of the DSCPs on the fragments 
ends up being used for the reassembled packet, but I guess most 
implementations will use the DSCP on the first fragment, even if they 
haven't consciously thought about it.

It wouldn't take much to update 2474 to just say that - if someone 
has some spare clock cycles to waste.



> > Section 9.1 of RFC 3168 as well as RFC 6040, specify procedures 
> for propagating ECN bits between the tunnel payload and delivery 
> header. These rules apply to all tunneled packets, regardless of 
> whether they are fragmented. Because the scope of 
> draft-bonica-intarea-gre-mtu is limited to MTU and fragmentation 
> issues, a discussion of these rules seems to be beyond the scope of 
> draft-bonica-intarea-gre-mtu.
>
>Agreed.

+1

>However, given that the GRE spec predates the ECN spec, what are GRE 
>implementations actually doing with the ECN/DSCP fields? 
>Unfortunately, 3168 did not update 2784, although GRE can also 
>provide an IP-in-IP tunnel type.

Yes, I would be interested in an answer to that. Particularly given 
recent ideas on using GRE tunnels in data centres to turn on ECN 
edge-to-edge. See draft-briscoe-conex-data-centre-01 or 
<http://www.ietf.org/proceedings/87/slides/slides-87-conex-4.pdf>

PS. We also have an individual draft that clarifies that the RFC6040 
propagation of ECN should be used by all the different tunnelling 
protocols, including GRE: 
<http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines-02>


Bob


>Lars
>
>PS: CC'ing Bob, who also commented.
>

________________________________________________________________
Bob Briscoe,                                                  BT