From nobody Thu Jun 1 00:54:58 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AD812E051 for ; Thu, 1 Jun 2017 00:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 xWOzNxY1USLb for ; Thu, 1 Jun 2017 00:54:53 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 7E4CE12AF77 for ; Thu, 1 Jun 2017 00:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1496303692; x=1527839692; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aFv6WSGZgx9a/MMu3vR43XgFzt8YHeezw+s9w6BM4tE=; b=d2L8v7u5KkdYonEh2l0Tui1Aj/OoCQQip1cA+2bXRpR+eUnWJFy9+PN7 q35z+dj7hsjz2LZIZ9fkzR/GnPdTVgsNewhcU2PFx3w/Ye79mPAkQdb9N a4dSJUZ9OUUHtSsX6ZRICxwuWKr2Y0lCj/DMCqpqxCSrlnBqqs8UuP/TN eKKvlo2PC0CYerJe5gIPYD2/HcrUQ7DdjoYligV62cip2mJOrCHggifDu cXi5z+08/OQvVGK1XZDRAgQcLebmMS1oSSXkHHSVjw+QG3UgBB4MMZ+Mu DQ4k8T8Yjn+dGvo7Lbh1NzeqBWGgKdIdo/gTxvZs6fC83eneLa/Hj2ExG Q==; Received: from q4de8ssaz61.gppng.telekom.de ([10.206.166.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2017 09:54:49 +0200 X-IronPort-AV: E=Sophos;i="5.39,278,1493676000"; d="scan'208";a="1191722276" Received: from he101655.emea1.cds.t-internal.com ([10.134.226.17]) by q4de8ssazdv.gppng.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2017 09:54:49 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101655.emea1.cds.t-internal.com (10.134.226.17) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 1 Jun 2017 09:54:18 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Thu, 1 Jun 2017 09:54:18 +0200 From: To: CC: , , Thread-Topic: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules Thread-Index: AQHS19ndA9nRN9ENAk2sUdkqCSvAFqILaAUAgAQhC8CAAA3+IA== Date: Thu, 1 Jun 2017 07:54:18 +0000 Message-ID: <47d9988a7fd34f73a0765fe221d4c233@HE101653.emea1.cds.t-internal.com> References: <5923F086.8030804@erg.abdn.ac.uk> <5d3c37a54bfb4cfab699613e34b32a5f@XCH-RCD-010.cisco.com> <592A83D6.6080501@erg.abdn.ac.uk> <592B0BF4.2030204@erg.abdn.ac.uk> <80ee670f49a54acdbc923ace2917c75a@XCH-RCD-010.cisco.com> In-Reply-To: <80ee670f49a54acdbc923ace2917c75a@XCH-RCD-010.cisco.com> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.165.104] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 07:54:57 -0000 Hi Tim, then I try to elaborate. You responded to Fred [TS] The context is very clearly limited to WiFi networks where the AP represent= s the edge of the network, and not WiFi networks in general. The scope could express that more clearly and section 1 and 1.3 are not ver= y clearly stating that. I further read into section 4, which specifies behavior for traffic from a = fixed network to a wireless access. To me that means, that IP layer/Diffser= v policy control is within the fixed network. CS6/CS7 marked IP traffic wen= t through that policy control. Section 4.1.1 of draft..ieee-802 reads "Before discussing a mapping recommendation for Network Control traffic marked CS6 DSCP, it is interesting to note a relevant recommendation from [RFC4594] pertaining to traffic marked CS7 DSCP: in [RFC4594] Section 3.1 it is RECOMMENDED that packets marked CS7 DSCP (a codepoint that SHOULD be reserved for future use) be dropped or remarked at the edge of the Diffserv domain." I quoute from RFC 4594 "o Drop or remark CS7 packets at ingress to DiffServ network domain." ^^^^^^^^^ I think section 4 of draft..ieee-802 discusses "egress". Further, RFC4594 says: "CS7 DSCP value SHOULD be reserved for future use, potentially for future routing or control protocols. Network administrators MAY use a Local/Experimental DSCP; therefore, they may use a locally defined service class within their network to further differentiate their routing and control traffic." Drop or even remark at an egress isn't applicable in that case, I think. Operational aspects may be considered at the network egress too: - I prefer "remark unknown DSCP" to default. A misconfiguration of the=20 provider may cause packets to be marked by an unexpected DSCP. If that=20 traffic is dropped, the customer may not have been doing anything wrong,= =20 but his traffic is dropped by the AP. "Be liberal in what you accept" seems to be the better guidance for the A= P. - consider a case of a HW supporting only 4 queues. One shares CS6 and=20 CS7 and a simple implementation may enforce CS6 and CS7 to use that=20 queue. If your recommendations are implemented and CS6 _and_ CS7 can't=20 be used, the entire queue is wasted. Related to a WiFi network edge / demarcation router as a minimum,=20 I'd suggest "SHOULD remark unexpected markings to default and MAY drop" in= =20 section 4, if unexpected markings are concerned. Further I think,=20 "CS7 MAY be allowed for experimental local use", to me for whatever=20 service. Section 4.1.1 was not the only one Gorry was concerned about. For=20 the time being I prefer to limit my comments to this section. Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: Tim Szigeti (szigeti) [mailto:szigeti@cisco.com]=20 Gesendet: Donnerstag, 1. Juni 2017 08:15 An: Geib, R=FCdiger; gorry@erg.abdn.ac.uk Cc: Jerome Henry (jerhenry); tsvwg@ietf.org; fredbakersba@gmail.com Betreff: RE: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text = on conditioning rules Hi Ruediger, Good to hear from you.=20 Some comments/questions inline, > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of=20 > Ruediger.Geib@telekom.de > Sent: Monday, May 29, 2017 2:57 AM > To: gorry@erg.abdn.ac.uk > Cc: Jerome Henry (jerhenry); tsvwg@ietf.org; fredbakersba@gmail.com > Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about=20 > text on conditioning rules >=20 > Hi Gorry, >=20 > you suggest to limit the scope of draft-ietf-tsvwg-ieee-802-11 to=20 > specify a default Diffserv mapping behavior for a commodity piece of=20 > Hardware [TS] OK - but keep in mind that a single Diffserv mapping behavior for a commodi= ty piece of hardware, regardless of how it's used, can present some signifi= cant security vulnerabilities. Are we sure that this is what we want to rec= ommend in a PS? . Any > IP related policies to be deployed if that piece of Hardware is used=20 > in a specific deployment should be separated and become part of a=20 > document in its own. [TS] Won't that cause even more confusion? In this PS, there is a relatively min= or part that addresses the exception use-case where APs are used to extend = the infrastructure (and specifically relate to control plane markings only)= . Other than that, the mapping behavior is a universal recommendation.=20 Would really a separate draft/PS be warranted for this minor use-case? That= in all other respects would be the same overall recommendations? Please elaborate/clarify. TIA. -tim >=20 > I'm not a Wifi expert, but to me there's a point in your proposal. >=20 > Regards, >=20 > Ruediger >=20 > PS: I also thought about comparing the separation of mapping and=20 > policy to Diffserv-Intercon, which covers both. There we had some=20 > policy related discussions, about bleaching, for example. The latter=20 > is scoped for a specific deployment however. >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Gorry=20 > Fairhurst > Gesendet: Sonntag, 28. Mai 2017 19:42 > An: tsvwg@ietf.org > Cc: gorry@erg.abdn.ac.uk; Jerome Henry (jerhenry);=20 > fredbakersba@gmail.com > Betreff: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text=20 > on conditioning rules >=20 > This email describes a number of concerns with the inclusion of=20 > conditioning rules in the 802-11 draft. >=20 > The title and abstract of the draft describe a mapping function. > However, the changes in rev -02 give me serious doubts about the=20 > remarking and drop recommendations, which I consider for a diffserv edge. >=20 > Point 1: I think the WG need to be very clear about the context of=20 > recommendations. I'd expect the class mappings to PHBs to be applied=20 > in all equipment that adheres to IETF standards. This should I think=20 > be the default for all APs - and I'd hope most vendors would start paying= attention. >=20 > Point 2: My concern is that the draft now recommends diffserv edge=20 > mechanisms that I think are inappropriate for a mapping draft. I=20 > suggest the conditioning rules apply to specific deployment scenarios.=20 > I also suggest this does not apply to all equipment - any=20 > recommendations need to be certain about context for deployment. I=20 > think there is quite an opportunity for the present text on remarking=20 > and drop in the current revision to be wrongly interpreted. I=20 > seriously fear the inclusion of remarking and drop recommendations can=20 > make this become an impediment to sender marking of DSCP across IP paths = that happen to include 802.11 equipment. >=20 > Point 3: The specific conditioning rules argue for pervasive remarking=20 > of all "unknown" codepoints - this position is a very specific view.=20 > If stated in a PS for 802.11 this would have serious implications on=20 > the usefulness of diffserv, and I think the IETF really has to=20 > consider these in detail before it takes this approach for 802.11. >=20 > ------------ >=20 > So, starting with Point 1: I noted previously that I do see real=20 > benefit in recommendations on how to map DSCPs using 802.11 and I=20 > suspect, if done correctly, this can greatly ease the consistent use of D= SCP. >=20 > It may be that the security considerations need to discuss the trust=20 > of markings and the possible need to remark or drop to protect the AP=20 > resources. I can also see how CS6 and CS7 may need to be discussed and=20 > text may have to say things about these when the AP is forms the edge=20 > of a network. >=20 > TEXT: > Traffic marked CS7 DSCP > SHOULD be dropped or remarked at this edge (as it is typically unused,=20 > as CS7 SHOULD be reserved for future use). > - section 4.1.1. recommends drop or remark, and I struggle here to=20 > know that this is the correct statement to make in general for 802.11 usa= ge. > Is it strictly necessary to drop CS6 traffic at an AP, that seems=20 > plausible in managed (e.g. enterprise) deployment, or on the upstream=20 > to an ISP in a home deployment (maybe in some places the operator own the= AP?). > Between IP networks in my house this seems like the wrong thing to do.=20 > It may be used by a routing protocol (e.g. RPL as > noted) could use this DSCP, why can I not use a layer 2 technology to=20 > move these packets between parts of my IP network with the DSCP that=20 > has been assigned? >=20 > So, really I question if the current phrasing is the correct=20 > recommendation. I think the WG needs to choose appropriate words here=20 > but that needs I think to be balanced by explaining that these=20 > codepoints may be used within a house or whatever for routing and=20 > functions. - They are not just for the upstream ISP! >=20 > Point 2: As you noted, there is a wide variety of 802.11 equipment and=20 > uses and you highlight two distinct deployment models. 802.11 uses are=20 > really diverse - they include managed environments in Enterprises,=20 > public wifi access, home networks, use as layer infrastructure in a=20 > very general sense, bridging to other layer 2 infrastructure (zigbee, etc= ). >=20 > There now follows concerns about the new text, which largely stems=20 > from the above context (i.e., in a different document with a different=20 > purpose the comments would be different). >=20 > I am not sure this text is helpful: > " In most commonly-deployed WLAN models, the wireless access point=20 > represents not only the edge of the Diffserv domain, but also the edge=20 > of the network infrastructure itself. > As such, only client > devices (and no infrastructure devices) are downstream from the access=20 > points in these deployment models. > " > - Again, there are many cases where this also not the same as well. I=20 > have a number of APs in my house, and for that matter a zigbee bridge=20 > that connects IoT devices. For many flows the AP is one hop to the DSL=20 > modem, but flows also exist between endpoints in the house - e.g. to=20 > deliver TV content across my home network, or to turn on/off lights or=20 > simply access the house computer from my laptop. >=20 > On Point 3: I think it may be wrong to recommend this: > TEXT: > " > In such deployment models, > it is RECOMMENDED that all packets marked to Diffserv Codepoints not=20 > in use over the wireless network be dropped or remarked at the edge of=20 > the Diffserv domain, as will be discussed in detail in Section 4.1.1." > - I would really hope APs do not do this, except if they within the=20 > control network of an upstream service provider that has configured=20 > consistent rules at the Apps for the service they offer. >=20 > I see the next para effectively implies SHOULD NOT remark or drop, in=20 > some other case - but even though I suspect you are hoping for the=20 > correct thing I do not see this clearly enough to feel confident that=20 > others will always understand what to do. >=20 > - It also suggests drop and remark are equal, they are not - the there=20 > behaviour i) (carry as DF (ii) Remark to DF (iii) Drop have quite=20 > different implications to those trying to write apps that wish to use dif= fserv. > --- > TEXT: > " > Thus the QoS treatment of packets at the access point will depend on=20 > the position of the AP in the network infrastructure and on the WLAN=20 > deployment model." > - Oh indeed, but the more I read, the more I'd really rather see how=20 > to handle edge treatment as a separate document that clearly explains=20 > that at a diffserv edge you do conditioning and what are the=20 > implications of the different approaches. > --- > TEXT: > It is NOT RECOMMENDED to trust DSCP markings from devices that are not=20 > authenticated and authorized; these are considered untrusted sources. > - Question: What is the intent here? Are you encouraging DSCP=20 > remarking (I hope not), or are you saying that the UP marking is=20 > assigned using a local policy rather than from the DSCP? >=20 > - I suspect the context here is not about mapping it is about managed=20 > use of an AP network. That varies, and I really think this is not the=20 > document to discuss that. The security considerations could note this=20 > - but quite honestly, if you expect my light bulbs and TV sets to=20 > start authenticating with the AP, then I'm going to argue. Do these=20 > devices benefit from using DSCPs - very very likely. >=20 > - Of course, if you were offering infrastucture to a range of=20 > customers then you may need to consider these issues. Saying SHOULD=20 > NOT trust seems to suggest you threaten to remark? or just to carry as=20 > best-effort within this network? > (Back to point 2: We all know that public radio networks need to=20 > consider resource models, but this is not a PHB mapping question.) > --- > TEXT: > "Alternatively, if a network device is configured to operate in an=20 > untrusted manner, then it would remark packets as these entered the=20 > device, typically to DF (or to a different marking value at the=20 > network administrator's preference). Note: > The terms "trusted" and "untrusted" are used extensively in RFC 4594." > - This is NOT what I want from an out-of-the-box AP configuration, and=20 > I think this muddies the deployment context. > --- >=20 > More on point 3: I really do not agree with the text in section 5.4: > TEXT: > 5.4. Upstream DSCP Marking at the Wireless Access Point >=20 > An alternative option to mapping is for the administrator to treat the=20 > wireless edge as the edge of the Diffserv domain and explicitly set=20 > (or reset) DSCP markings in the upstream direction according to=20 > administrative policy. This option is RECOMMENDED over mapping, as=20 > this typically is the most secure solution, as the network=20 > administrator directly enforces the Diffserv policy across the IP=20 > network (versus an application developer and/or the wireless endpoint=20 > device operating system developer, who may be functioning completely inde= pendently of the network administrator). >=20 > - Comment. I see the alternative and realise that the edge of a DS=20 > domain can condition traffic, but it would be truly dismal if every=20 > home router tried to reset all the DSCPs I use. > - I strongly dislike an approach that drops packets with DSCPs (=20 > except for admitted services). I think drop and even remark is a=20 > direct hurdle for apps to become able to use Diffserv across other=20 > network paths. If this is approach is taken by a wireless AP - then=20 > the network to which it connects is now deprived of application-chosen=20 > DSCPs. APs are used in many ways, e.g., as bridges to other=20 > infrastructure in IOT applications this recommendation would come in=20 > the way of assigning DSCPs for control applications in this case. It=20 > also produces a different DSCP behaviour when I use wifi AP to when I=20 > use a wired network segment. I therefore do not support this as the recom= mended approach, what do others think? > --- > TEXT: > "it is RECOMMENDED that all packets marked to Diffserv Codepoints not=20 > in use over the wireless network be dropped or remarked" > I strongly disagree with the following recommendation, which was=20 > formally in the network control section and I had not understood that thi= s "all packets" > actually was intended as a general recommendation to reset all DSCPs. >=20 > It becomes very difficult to use diffserv at all if each layer 2=20 > network has different remark/drop policies. At the moment many=20 > networks neither remark nor drop - which I actually think is correct,=20 > they are layer 2 devices and they have not been configured with any=20 > information about the Diffserv capabilities of the networks they talk to. > --- > TEXT: > "Section 4.1.1 RECOMMENDED that all packets marked to Diffserv=20 > Codepoints not in use over the wireless network be dropped or remarked=20 > at the edge of the Diffserv domain. This recommendation may help=20 > mitigate a Denial-of-Service attack vector that exists at=20 > wired-to-wireless edges in the downstream direction. For example,=20 > consider a malicious user flooding traffic marked CS7 or CS6 DSCP=20 > toward the WLAN. These codepoints would map by default to UP 7 and UP=20 > 6 (respectively), both of which would be assigned to the Voice Access=20 > Category (AC_VO). Such a flood could cause a Denial- of- Service to wirel= ess voice applications." >=20 > I think it is useful case to describe, but I do not agree with the=20 > recommendation for this document. > --- > TEXT: > "Section 5.3 made it clear that it is NOT RECOMMENDED to trust DSCP=20 > markings from devices that are not authenticated and authorized, as=20 > these are considered untrusted sources. This is especially relevant=20 > for IoT, as billions of devices are being connected to IP networks,=20 > many of which have little or no security." >=20 > I share the concern here, and I think it is useful case to describe,=20 > but I do not agree with the recommendation for this document: > - In my home network? >=20 > I don't agree with the current text in section 5.3, which begins: > "It is NOT RECOMMENDED to trust DSCP markings from devices that are=20 > not authenticated and authorized; these are considered untrusted sources.= " >=20 > --- >=20 > I do not agree with this: > Section 5.4 RECOMMENDED that the administrator treat the wireless edge=20 > as the edge of the Diffserv domain and explicitly set (or > reset) DSCP markings in the upstream direction according to=20 > administrative policy. > - the discussion goes on to talk about an example with CS6 and CS7,=20 > there may be a case for admission control to this class - or at least=20 > this PHB - but the general comment of requesting rewriting of all=20 > codepoints goes against current practice as far as I can see, and also is= most unhelpful. >=20 > --- > TEXT > Suffice it to say that > the security of the devices and networks implementing QoS, including=20 > QoS mapping between wired and wireless networks, SHOULD be considered=20 > in actual deployments. > - I agree that you must protect operator infrastructure, and all=20 > people who use APs need to make decisions about which traffic to admit=20 > to the network at a particular QoS level. That does not mean I agree=20 > with thinking a device need to remark all my traffic because it is not=20 > what you think is best to cross a wireless/wired boundary." >=20 > ------------------- >=20 > I look forward to learning more what others think on this, >=20 > best wishes, >=20 > Gorry Fairhurst >=20 >=20 >=20 From nobody Thu Jun 1 06:15:29 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20BA12EBA8 for ; Thu, 1 Jun 2017 06:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 XLmbH7R-m_Ht for ; Thu, 1 Jun 2017 06:15:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C95012EBA5 for ; Thu, 1 Jun 2017 06:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=663; q=dns/txt; s=iport; t=1496322926; x=1497532526; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4WKQeDDJoeSGBPESvsFvChuSWqxMEDvVRPgoppHbLa0=; b=kwVD5K9H9JS4EP4zcne0MJ71jVutZXeadwkgpQ4kD11q3i2P2u2YXAJY +aQQysYsooLKIyBUv+hWUt3o/pMlQeBwAYDuk36U6XwJaSoifdUIXIYg0 kTXn1EY2hXx+ozj2zIjfYiMmq7/dwUHKDJk+eIqgqGXvglSjtL15Akm95 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAAC7EjBZ/49dJa1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNXgXaOBadtgg+GJAKCcz8YAQIBAQEBAQEBayiFGQY6PxACAQg?= =?us-ascii?q?2EDIlAgQBDQ2KIq8mi1MBAQEBAQEBAQEBAQEBAQEBAQEBAQEdi2CKWwWWfYcsA?= =?us-ascii?q?ZMhgg+FPIo3lFYBHziBCnQVhw49iViBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,279,1493683200"; d="scan'208";a="34360837" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2017 13:15:25 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v51DFPDo023896 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2017 13:15:25 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Jun 2017 08:15:24 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Thu, 1 Jun 2017 08:15:24 -0500 From: "Tim Szigeti (szigeti)" To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" CC: "Jerome Henry (jerhenry)" , "fredbakersba@gmail.com" Thread-Topic: draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules Thread-Index: AQHS19nRqhAGXzeKJkuxsecs67EcPKIPaZwQgACXU7A= Date: Thu, 1 Jun 2017 13:15:24 +0000 Message-ID: <040cd45440394cef9256b1768e486825@XCH-RCD-010.cisco.com> References: <5923F086.8030804@erg.abdn.ac.uk> <5d3c37a54bfb4cfab699613e34b32a5f@XCH-RCD-010.cisco.com> <592A83D6.6080501@erg.abdn.ac.uk> <592B0BF4.2030204@erg.abdn.ac.uk> <33c57ede33d64b2eb6fcb0019e777373@XCH-RCD-010.cisco.com> In-Reply-To: <33c57ede33d64b2eb6fcb0019e777373@XCH-RCD-010.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.22.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 13:15:27 -0000 Hi Gorry and All. Would this proposal work? A complete removal of all recommendations to remark or drop DSCP from the P= S. Instead, making the following *mapping only* recommendations: - on wireless edges where the AP represents the edge of the IP network, CS6= and CS7 be mapped to UP 0 (thus meeting the security concern of mitigating= this DoS attack vector, but without altering the DSCP in the process) - on all wired/wireless edges, codepoints not in use be recommended to be m= apped to UP 0 (for the same reasons) Would this meet with your and TSVWG approval? Please advise and we'll make = the changes accordingly. TIA. -tim From nobody Thu Jun 1 08:35:39 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A7F129BCC for ; Thu, 1 Jun 2017 08:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 L1vveEoKxNBI for ; Thu, 1 Jun 2017 08:35:37 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 9F9BB129BE8 for ; Thu, 1 Jun 2017 08:35:36 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-3c-593034460b36 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2E.F7.03383.64430395; Thu, 1 Jun 2017 17:35:34 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.339.0; Thu, 1 Jun 2017 17:30:16 +0200 To: , References: <592B239D.3030802@erg.abdn.ac.uk> From: Magnus Westerlund Message-ID: <71f5de51-0484-1187-fba2-33e8696b11bd@ericsson.com> Date: Thu, 1 Jun 2017 17:30:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <592B239D.3030802@erg.abdn.ac.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM2K7iq6biUGkwb9HZhav22YzWhx7c5fN gcmj5/MLJo8lS34yBTBFcdmkpOZklqUW6dslcGXMuDmRueADR8XKQw1MDYwN7F2MnBwSAiYS N9fvZe1i5OIQEjjCKPFjTwMbhLOMUWLxtQ/MIFXCAuESz54eAbNFBHQkOrd+YwKxhQR0JT63 PGEFsdkELCRu/mhkA7F5Bewltr57zgJiswioSPQ0fwPrFRWIkXi04SwTRI2gxMmZT8BqOAX0 JPr+/AOaw8HBDNT7YGsZSJhZQFzi1pP5TBC2vETz1tnMEGu1JRqaOlgnMArMQjJpFkL3LCTd s5B0L2BkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGKwHt/zW3cG4+rXjIUYBDkYlHl5u bYNIIdbEsuLK3EOMEhzMSiK8RzSBQrwpiZVVqUX58UWlOanFhxilOViUxHkd9l2IEBJITyxJ zU5NLUgtgskycXBKNTAuPXr3dRNDf1vSivBX6z+x3d/2depCBufPrJ5vDktvnKvI4JJw9foh noMdQd/DklwaIn7MPb9yhtcyXu3LqfmWGxbuEnh3YcGfH0kCnLMWlOW/dFq2cIuo0bFjam2f 6jLuNX0zseRd73HeXfnwxXn3pm4+k9p8exa34f5pJd+z3Nwabn5IeBbro8RSnJFoqMVcVJwI AIOGgFJSAgAA Archived-At: Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata to conclude 12th June 2017. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 15:35:38 -0000 Hi, I have reviewed the changes since -08 and that my comments on -08 has been resolved satisfactory. I have no further comments and think this document is ready for publication. Cheers Magnus Den 2017-05-28 kl. 21:23, skrev Gorry Fairhurst: > This email notes the start of a WGLC for draft-ietf-tsvwg-sctp-ndata. > > Please send notes to this list or the WG Chairs, if you support > publication of this draft or have any comments on the current revision > of this document. The intended status (if the document completes the > WGLC) is PS. > > The WGLC will conclude 12th June 2017. > > Best wishes, > > Gorry, David and Wes. > > -- Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jun 2 01:16:10 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD0C1314E0 for ; Fri, 2 Jun 2017 01:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jRG_Kax3r8eg for ; Fri, 2 Jun 2017 01:16:06 -0700 (PDT) Received: from mail.mera.ru (mail.mera.ru [195.98.57.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0DD1314D8 for ; Fri, 2 Jun 2017 01:15:59 -0700 (PDT) Received: from cmail.merann.ru ([192.168.50.122]) by mail.mera.ru with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1dGhju-0001LX-MW; Fri, 02 Jun 2017 11:15:22 +0300 Received: from e16srv01.merann.ru (192.168.50.31) by cmail.merann.ru (192.168.50.122) with Microsoft SMTP Server (TLS) id 14.3.351.0; Fri, 2 Jun 2017 11:15:47 +0300 Received: from e16srv03.merann.ru (192.168.50.33) by e16srv01.merann.ru (192.168.50.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Fri, 2 Jun 2017 11:15:46 +0300 Received: from e16srv03.merann.ru ([fe80::38b3:8b2:2b76:7a66]) by e16srv03.merann.ru ([fe80::38b3:8b2:2b76:7a66%12]) with mapi id 15.01.0845.034; Fri, 2 Jun 2017 11:15:46 +0300 From: "Proshin, Maksim" To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata to conclude 12th June 2017. Thread-Index: AQHS220nNYzg/mbxAE2hwR8TyZ71sqIROS8w Date: Fri, 2 Jun 2017 08:15:46 +0000 Message-ID: <8df0fe29e66f4f0c9e2842b9045832be@mera.ru> References: <592B239D.3030802@erg.abdn.ac.uk> <71f5de51-0484-1187-fba2-33e8696b11bd@ericsson.com> In-Reply-To: Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.201.113] x-inside-org: True Content-Type: multipart/alternative; boundary="_000_8df0fe29e66f4f0c9e2842b9045832bemeraru_" MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata to conclude 12th June 2017. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 08:16:09 -0000 --_000_8df0fe29e66f4f0c9e2842b9045832bemeraru_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZG9u4oCZdCBoYXZlIGFueSBmdXJ0aGVyIGNvbW1lbnRzIGVpdGhlciBhbmQgc3Vw cG9ydCBwdWJsaWNhdGlvbiBvZiBpdC4NCg0KQlIsIE1heGltDQoNCg0KLS0tLS0tLS0tLSBGb3J3 YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20+Pg0KRGF0ZTogVGh1LCBKdW4gMSwgMjAxNyBhdCA2OjMwIFBNDQpTdWJqZWN0OiBSZTog W3RzdndnXSBXR0xDIGZvciBkcmFmdC1pZXRmLXRzdndnLXNjdHAtbmRhdGEgdG8gY29uY2x1ZGUg MTJ0aCBKdW5lIDIwMTcuDQpUbzogZ29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVy Zy5hYmRuLmFjLnVrPiwgdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KDQoN CkhpLA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhlIGNoYW5nZXMgc2luY2UgLTA4IGFuZCB0aGF0IG15 IGNvbW1lbnRzIG9uIC0wOCBoYXMgYmVlbiByZXNvbHZlZCBzYXRpc2ZhY3RvcnkuIEkgaGF2ZSBu byBmdXJ0aGVyIGNvbW1lbnRzIGFuZCB0aGluayB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBw dWJsaWNhdGlvbi4NCg0KQ2hlZXJzDQoNCk1hZ251cw0KDQoNCkRlbiAyMDE3LTA1LTI4IGtsLiAy MToyMywgc2tyZXYgR29ycnkgRmFpcmh1cnN0Og0KVGhpcyBlbWFpbCBub3RlcyB0aGUgc3RhcnQg b2YgYSBXR0xDIGZvciBkcmFmdC1pZXRmLXRzdndnLXNjdHAtbmRhdGEuDQoNClBsZWFzZSBzZW5k IG5vdGVzIHRvIHRoaXMgbGlzdCBvciB0aGUgV0cgQ2hhaXJzLCBpZiB5b3Ugc3VwcG9ydCBwdWJs aWNhdGlvbiBvZiB0aGlzIGRyYWZ0IG9yIGhhdmUgYW55IGNvbW1lbnRzIG9uIHRoZSBjdXJyZW50 IHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQuIFRoZSBpbnRlbmRlZCBzdGF0dXMgKGlmIHRoZSBk b2N1bWVudCBjb21wbGV0ZXMgdGhlIFdHTEMpIGlzIFBTLg0KDQpUaGUgV0dMQyB3aWxsIGNvbmNs dWRlIDEydGggSnVuZSAyMDE3Lg0KDQpCZXN0IHdpc2hlcywNCg0KR29ycnksIERhdmlkIGFuZCBX ZXMuDQoNCg0KLS0NCg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTWVkaWEg VGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24g QUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQpGw6Ryw7ZnYXRhbiA2 ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0IDgwIFN0b2Nr aG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208bWFp bHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --_000_8df0fe29e66f4f0c9e2842b9045832bemeraru_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjU2LjdwdCA0Mi41cHQgNTYuN3B0IDg1 LjA1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SSBkb27igJl0IGhhdmUgYW55IGZ1cnRoZXIgY29tbWVudHMgZWl0aGVyIGFuZCBz dXBwb3J0IHB1YmxpY2F0aW9uIG9mIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+QlIsIE1heGltPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0t LS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTogPGI+TWFnbnVz IFdlc3Rlcmx1bmQ8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tIj5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCkRh dGU6IFRodSwgSnVuIDEsIDIwMTcgYXQgNjozMCBQTTxicj4NClN1YmplY3Q6IFJlOiBbdHN2d2dd IFdHTEMgZm9yIGRyYWZ0LWlldGYtdHN2d2ctc2N0cC1uZGF0YSB0byBjb25jbHVkZSAxMnRoIEp1 bmUgMjAxNy48YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIj5n b3JyeUBlcmcuYWJkbi5hYy51azwvYT4sIDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+ DQp0c3Z3Z0BpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQo8YnI+DQpIaSw8YnI+DQo8YnI+DQpJIGhh dmUgcmV2aWV3ZWQgdGhlIGNoYW5nZXMgc2luY2UgLTA4IGFuZCB0aGF0IG15IGNvbW1lbnRzIG9u IC0wOCBoYXMgYmVlbiByZXNvbHZlZCBzYXRpc2ZhY3RvcnkuIEkgaGF2ZSBubyBmdXJ0aGVyIGNv bW1lbnRzIGFuZCB0aGluayB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi48 YnI+DQo8YnI+DQpDaGVlcnM8YnI+DQo8YnI+DQpNYWdudXM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KRGVuIDIwMTctMDUtMjgg a2wuIDIxOjIzLCBza3JldiBHb3JyeSBGYWlyaHVyc3Q6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5U aGlzIGVtYWlsIG5vdGVzIHRoZSBzdGFydCBvZiBhIFdHTEMgZm9yIGRyYWZ0LWlldGYtdHN2d2ct c2N0cC1uZGF0YS48YnI+DQo8YnI+DQpQbGVhc2Ugc2VuZCBub3RlcyB0byB0aGlzIGxpc3Qgb3Ig dGhlIFdHIENoYWlycywgaWYgeW91IHN1cHBvcnQgcHVibGljYXRpb24gb2YgdGhpcyBkcmFmdCBv ciBoYXZlIGFueSBjb21tZW50cyBvbiB0aGUgY3VycmVudCByZXZpc2lvbiBvZiB0aGlzIGRvY3Vt ZW50LiBUaGUgaW50ZW5kZWQgc3RhdHVzIChpZiB0aGUgZG9jdW1lbnQgY29tcGxldGVzIHRoZSBX R0xDKSBpcyBQUy48YnI+DQo8YnI+DQpUaGUgV0dMQyB3aWxsIGNvbmNsdWRlIDEydGggSnVuZSAy MDE3Ljxicj4NCjxicj4NCkJlc3Qgd2lzaGVzLDxicj4NCjxicj4NCkdvcnJ5LCBEYXZpZCBhbmQg V2VzLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGNsYXNzPSJob2VuemIiPjxzcGFuIHN0eWxlPSJjb2xvcjoj ODg4ODg4Ij4tLQ0KPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJy Pg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+TWFnbnVzIFdlc3Rlcmx1bmQ8L3NwYW4+PGJy Pg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48YnI+DQo8 c3BhbiBjbGFzcz0iaG9lbnpiIj5NZWRpYSBUZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNo PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+RXJpY3Nzb24gQUImbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgUGhvbmUmbmJzcDsgJiM0 Mzs0NiAxMCA3MTQ4Mjg3PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkbDpHLDtmdh dGFuIDYmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wgTW9iaWxlICYjNDM7NDYgNzMgMDk0OTA3OTwvc3Bhbj48YnI+DQo8c3BhbiBj bGFzcz0iaG9lbnpiIj5TRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IDxhIGhy ZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5r Ij4NCm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTwvYT48L3NwYW4+PGJyPg0KPHNwYW4g Y2xhc3M9ImhvZW56YiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8df0fe29e66f4f0c9e2842b9045832bemeraru_-- From nobody Thu Jun 8 09:46:42 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7678129426 for ; Thu, 8 Jun 2017 09:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 A1UcgTU8appG for ; Thu, 8 Jun 2017 09:46:38 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20104.outbound.protection.outlook.com [40.107.2.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF5512946C for ; Thu, 8 Jun 2017 09:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=roulGjlxmK7eX8IX6H7y8KMdH1ZnOqfDDXLsyQEo9lA=; b=blcI8OF6nTlqwhgvEDE90cqIuf8Y+37aOrkFXQx4jzosrlQ1oWuRPovibYDvG1omxtoAlMN/snYIj4sr8O9TO17OuCyv/KnN3nLyE1jneAOIVrMeGbm1cPb1Bn0rUoZX0XB5CkwbMPyky4MzTD5Wm73dxcb2z3Aour0kgKFpVwI= Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com (10.169.137.7) by VI1PR0701MB2013.eurprd07.prod.outlook.com (10.167.209.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Thu, 8 Jun 2017 16:46:35 +0000 Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::e1b3:e2c9:79b8:d9f]) by VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::e1b3:e2c9:79b8:d9f%18]) with mapi id 15.01.1157.012; Thu, 8 Jun 2017 16:46:35 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to conclude 12th June 2017 Thread-Index: AQHS1+gr7FEhpcyUwEWkVlVjUHHnoqIbNagA Date: Thu, 8 Jun 2017 16:46:35 +0000 Message-ID: References: <592B2416.9030003@erg.abdn.ac.uk> In-Reply-To: <592B2416.9030003@erg.abdn.ac.uk> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: erg.abdn.ac.uk; dkim=none (message not signed) header.d=none;erg.abdn.ac.uk; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [213.49.104.236] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2013; 7:EorZtK5wcfPQBX3JcGCH24gtKZ32OpfXpKRK2khhaya5js8WZwweu09KhwYS/nfMNEBZZKEdseYH0Cj2PZ/5vwTKYvNdKqy0sWMG9XB1b02ML123FQtfET0mwbPRMHWv2R6obmArVQNx7wC4U/6Sr+jHOdDpnvlKFme1UWrpYV3rPLFA9qFZdR8TE7/XXsO4Dm870tZgsX2vZTasn3LFq/U7v9HMlOaV2AHv3Qg1Su/jwnn6fNX9BkEECfYaSwFLEuz1Z5rCd9tHcVoK44fflqHKlizJMYNYDWElSRw1WqLwpDe2HlIGC7m9iKzOk4zrznVLACgt1ra0Vk53TURsxw== x-ms-traffictypediagnostic: VI1PR0701MB2013: x-ms-office365-filtering-correlation-id: d1edea7d-0b19-4a61-5170-08d4ae8decf8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR0701MB2013; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB2013; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB2013; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39840400002)(39850400002)(39410400002)(39400400002)(13464003)(6436002)(38730400002)(2906002)(6246003)(3280700002)(2900100001)(5660300001)(54356999)(50986999)(3846002)(76176999)(6506006)(102836003)(9686003)(5250100002)(2501003)(3660700001)(53936002)(55016002)(99286003)(74316002)(2950100002)(14454004)(33656002)(230783001)(25786009)(189998001)(86362001)(8936002)(53546009)(305945005)(7736002)(229853002)(66066001)(478600001)(8676002)(7696004)(81166006)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2013; H:VI1PR0701MB2126.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 16:46:35.3994 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2013 Archived-At: Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to conclude 12th June 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 16:46:41 -0000 > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: zondag 28 mei 2017 21:25 > To: tsvwg@ietf.org > Subject: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to conclud= e > 12th June 2017 >=20 > This email notes the start of a WGLC for > draft-ietf-tsvwg-ecn-experimentation. >=20 > Please send notes to this list or the WG Chairs, if you support > publication of this draft or have any comments on the current revision > of this document. The intended status (if the document completes the > WGLC) is PS. >=20 > The WGLC will conclude 12th June 2017. >=20 > Best wishes, >=20 > Gorry, David (author of this ID) and Wes. >=20 Hi, No further comments for WGLC from my side. All are already covered by other= 's comments. Regards, Koen. From nobody Thu Jun 8 10:21:08 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39065129553 for ; Thu, 8 Jun 2017 10:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 7JE7WyirECoP for ; Thu, 8 Jun 2017 10:21:04 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1A24F12952E for ; Thu, 8 Jun 2017 10:21:04 -0700 (PDT) Received: from dhcp-207-152.erg.abdn.ac.uk (dhcp-207-152.erg.abdn.ac.uk [139.133.207.152]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 73BFD1B012F8 for ; Thu, 8 Jun 2017 20:15:37 +0100 (BST) Reply-To: gorry@erg.abdn.ac.uk References: To: tsvwg WG From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. X-Forwarded-Message-Id: Message-ID: Date: Thu, 8 Jun 2017 18:21:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] TSVWG of draft-touch-tsvwg-udp-options-09 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 17:21:07 -0000 The above draft is approved as a WG document, there seems to be support for this work, although there are issues to be addressed by the group, please discuss these on the list - 5 people noted support on the list during the adoption call (some of these were different people). The WG Chairs will now consult with the AD to set an appropriate milestone. Gorry, Wes and David From nobody Thu Jun 8 10:36:46 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C91128D19; Thu, 8 Jun 2017 10:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 rWscPSqzPDgV; Thu, 8 Jun 2017 10:36:41 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id EB53512EB18; Thu, 8 Jun 2017 10:36:34 -0700 (PDT) Received: from dhcp-207-152.erg.abdn.ac.uk (dhcp-207-152.erg.abdn.ac.uk [139.133.207.152]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 45BA61B012F1; Thu, 8 Jun 2017 20:31:09 +0100 (BST) Reply-To: gorry@erg.abdn.ac.uk To: tsvwg WG References: <592C24A3.3010108@abdn.ac.uk> Cc: tsvwg-chairs@ietf.org From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Thu, 8 Jun 2017 18:36:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <592C24A3.3010108@abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [tsvwg] TSVWG Detailed Status - June 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 17:36:45 -0000 The Status From time-to-time we send the long-form status report for activities in TSVWG. The list below shows the status of the working group documents as we see it. Please check below and comment on drafts using the list. Please do send any corrections/omissions to the chairs. Gorry, Wes, & David (TSVWG Chairs) June 2017 ------------------------------------------------------------------- IDs in RFC Editor Queue (http://www.rfc-editor.org/queue.html) : --- draft-ietf-tsvwg-sctp-dtls-encaps - PS - Document Shepherd: Gorry RFC Editor: MISSREF - waiting for draft-ietf-tsvwg-ndata --- draft-ietf-tsvwg-rtcweb-qos - PS - Document Shepherd: David Approved, announcement 8th August 2016 RFC Editor: MISSREF - part of large rtcweb drafts hairball/tarball (C238) ---------------------------------------------------------- RFC-Ed ACTIONS: --- - None ---------------------------------------------------------- IDs in IESG Evaluation ---- - None ------------------------------------------------------------------- WG Drafts with Chairs: ---- - None ------------------------------------------------------------------- Completed WGLC: ---- draft-ietf-tsvwg-tunnel-congestion-feedback - Document Shepherd: David Replaces: draft-wei-tsvwg-tunnel-congestion-feedback - Thought to fall within TSVWG charter, comments welcome on tsvwg list. - IETF 91: Authors will work w/Bob Briscoe, who has a related individual draft for conex, on feedback mechanisms. Goal is concrete action taken based on detected problems that can be used from other drafts by reference. Also have to deal with possibility of dropped packets within tunnel. *** NOTE: 2 IPR declarations relate to the work of this draft *** November 2016: Completed WGLC, but not enough reviews. Two reviewers were found in Seoul (Bob Briscoe, Jake Holland) - need reviews from them before submitting publication request. ------------------------------------------------------------------- In WGLC: --- draft-ietf-tsvwg-sctp-ndata - PS - Document Shepherd: Gorry Replaces: draft-stewart-tsvwg-sctp-ndata-03 Nov 2013 Adopted, intended for publication as a PS RFC Mar 2014, 5-6 people had read. Name was changed (proposed at IETF-90), Interleaved data Header was made smaller. Work needed: • Describe how it works! (Possible Errata to fix RFC 4960) • Describe Stream Schedulers – Address comments received on the mailing list. • Clarification of use-case. • Make clear what also applies when regular DATA chunks are used. ++ Magnus Westerlund will review (review requested May 2017) ++ Karen Neilson will review (review requested May 2017) ++ Randal Jessup will review (review requested May 2017) July 6th Revised ID IPR: status : R. Stewart = ?; M. Tuexen = OK; S. Loreto =OK; R. Seggelmann =? Shepherd review: GF: Document reviewed with questions and proposed corrections. IETF-97 (Seoul) presented Draft -08 which reflected updates after Shepherd review. Reviews from IR; IETF-98, next rev ready for WGLC. Awaiting end of WGLC 12th June by GF - WGLC comments (GF) DUE: Comment on List (Shepherd writeup due) --- draft-ietf-tsvwg-ecn-experimentation - Document Shepherd: Gorry Replaces: draft-black-tsvwg-ecn-experimentation Presented Soul IETF (Nov 2016) and had been discussed in WG Author requested WG Adoption (Seoul) IETF-97 (Seoul), presented and discussed. WG Adoption call on rev -04 - ended 912th Dec 2016 (6 people noted on list) 7 people in WG noted support on list (GF+DB+MW+KN+JH+IJ+KdeS) IETF-98, next rev ready for WGLC. Awaiting end of WGLC 12th June by GF IPR: status : D. Black = ? - WGLC comments (GF) DUE: Comment on List (Shepherd writeup also due) --- WG Drafts --- draft-ietf-tsvwg-ieee-802-11 - PS - Document Shepherd: David Replaces: draft-szigeti-tsvwg-ieee-802-11 - Initial presentation at Prague IETF (Summer 2014) - Presentation at IETF Nov 2015. Thought to fall within TSVWG charter - No call issued for adoption at this time. Chair Note: Does this need to reference RC4594 or an update to that spec.? There's some background work that's likely to surface as proposed 4594bis and 5127bis drafts. Working Group call for adoption to end 25th June 2016. Adopted 28-June-2016 WG proposed status was updated to PS - notified WG on 8th August 2016, concluded. Name changed to remove "Guidelines" in the title, and target made PS IETF-97 (Seoul) presented. WGLC feedback, returned to WG for more discussion IPR: status : T. Szigeti = OK; F. Baker =OK - Comments by DB - incorporated in rev -02. - Comments by GF, FB on conditioning statements May 2017 DUE: Major Post-WGLC updates, will need a second WGLC --- draft-ietf-tsvwg-ecn-encap-guidelines - BCP - Document Shepherd: David Replaces: draft-briscoe-tsvwg-ecn-encap-guidelines -00 Presented in Prague, IETF-80. - comments at IETF-80 (see minutes) New ID presented in Atlanta, IETF-85. ID presented in IETF-88,89 - forward an appropriate message (perhaps your note to the mailing list for approval to adopt) to ieee-ietf-coord@ietf.org) ++ Reviewers: Andrew McGregor, Dirk Kutscher, (Richard Sheffnegger), Brian Trammell, Gorry. Mar 2014, WG Call for adoption started, to end 4th March 2014 19 for, 1 against. 8 echoed on the list Adoption call concluded and document adopted. - ecn-encap-guidelines and AQM are the main new things they need to know about. on IEEE802.1Q) Liaison sent to IEEE 802 (Nov 24, 2014). Liaison sent to 3GPP (August 2015) Oct 2015 - Draft updated for Yokohama meetings. Not sure about INT Area presentation. Need some more soak time for 3GPP Liaison. 3GPP liaison statement People who volunteered to review: * Andrew McGregor, Google * Dirk Kutscher, NEC * (I've also just asked Ingemar Johansson to volunteer) Support on list * Matt Mathis, Google * Richard Scheffenegger, NetApp * Michael Welzl, Uni Oslo * Wei Xin Peng, Huawei * Rong Pan, Cisco * Michael Menth, Tubingen Uni * Zhu Lei, Huawei * Piers O'Hanlon, UCL * Philip Eardley, BT * Suresh Krishnan * An Nguyen, DHS/OEC * Vinay Bannai, Paypal * Mirja Kuehlewind, Stuttgart Uni * Ruediger Geib, DT * Ingemar Johansson, Ericsson (? unclear whether support, or just a comment) Non-supportive of a doc solely about ECN. * Joe Touch, ISI IETF-98 (Chicago) Chairs will talk to TRILL chairs and try to get both into WGLC. DUE: Next version to be presented to IETF INT Area. DUE: Please comment on TSVWG list. --- draft-ietf-tsvwg-rfc6040update-shim-00 - PS - Document Shepherd: David Replaces: draft-briscoe-tsvwg-rfc6040bis Replaces: draft-ietf-tsvwg-rfc6040-update Topic thought to fall within TSVWG charter Support for this work noted (Berlin IETF, 2016) - to be published as a pair with ecn encaps. An adoption call was started on list by the Chairs until 22nd August 2016, concluded and adopted. Adopted, intended for publication as a PS RFC) WG work item - new-revision submitted ++ Randal Stewart will review ++ Randal Jessup will review IETF-97 (Seoul) presented Renamed as draft-ietf-tsvwg-rfc6040update-shim - 15th Nov 2016. DUE: Please discuss on the TSVWG list. --- draft-ietf-tsvwg-natsupp - Document Shepherd: Gorry Replaces: draft-stewart-natsupp-tsvwg Dependency from BEHAVE WG (no longer applicable). Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg Authors restructured draft (-03) Added support for single and multi-homed support. IETF-86: 3 people in meeting had read -04 or -05. Feb 2014, Authors please update following comments and align to related draft on SCTP NAT (conflicts found in language) Authors expected to produce a single document to replace both. ++ Dan Wing has committed to review this. ++ Fred Baker has committed to review this. Separated the simpler case for single-homed use - this separation should be clear. March 2015 document restructured and merged with draft-ietf-tsvwg-sctpnat March 2015, initial review by Gorry - need to consider helping NAT vendors access the recommendations. Gorry, Karen: Minor NiTs, Scope of IPv4 NAT discussed in Prague IETF and still thought within Charter. DUE: Revised ID-needed. Currently expired. --- draft-ietf-tsvwg-rfc4960-errata - Info - Document Shepherd: Gorry Replaces: draft-tuexen-tsvwg-rfc4960-errata Topic thought to fall within TSVWG charter Support for this work noted in Prague (Aug 2015). Expected to be used as the basis for an update to SCTP base specification. Authors have requested adoption IETF-95 - sense of the meeting room to proceed. IETF-96 - sense of the meeting room to proceed Adopted (22nd August 2016) DUE: Draft being developed, Please comment on the TSVWG list. --- draft-ietf-tsvwg-le-phb - Document Shepherd: David Replaces: draft-bless-tsvwg-le-phb A Lower Effort Per-Hop Behavior (LE PHB) Topic thought to fall within TSVWG charter Support for this work noted (Berlin IETF, 2016). An adoption call was started on list by the Chairs until 22nd August 2016, concluded and adopted. Adopted Nov 2016. New rev as a WG item. (Targeting publication as an EXP RFC) IETF-97 (Seoul), presented. IETF-98 (Chicago) discussed choice of code point - awaiting more data, expected decision by Sept 2017 DUE: Please comment on the TSVWG list. --- draft-ietf-tsvwg-l4s-arch - Document Shepherd: TBD replaces draft-briscoe-tsvwg-l4s-arch IETF-96, Previous version discussed at L4S BoF IETF-97 (Seoul), presented. IETF-98 (Chicago) 10 people had red the draft, clear support for adoption. Adopted. DUE: Please discuss on the TSVWG list. --- draft-ietf-tsvwg-ecn-l4s-id - Document Shepherd: Wes replaces draft-briscoe-tsvwg-ecn-l4s-id New draft Nov-2914: Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay IETF-96, Previous version discussed at L4S BoF IETF-97 (Seoul), presented. IETF-98 (Chicago) 10 people had read the draft, clear support for adoption. Adopted by tsvwg DUE: Please discuss on the TSVWG list. --- draft-ietf-tsvwg-dualq-coupled - Document Shepherd: Wes replaces: draft-briscoe-aqm-dualq-coupled Currently individual draft, TSVWG will consider this. - requires update to base ECN RFC - see separate draft. *** IPR related to this draft was submitted: September 16, 2015 (Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee) *** Updated -01 March 2016, discussed on the AQM WG list. IETF-97 (Seoul), presented, new research results (Nov 2016) IETF-98 (Chicago) 10 people had red the draft, clear support for adoption. Adopted by tsvwg DUE: Please discuss on the TSVWG list. --- draft-ietf-tsvwg-udp-options - Document Shepherd: Gorry replaces: draft-touch-tsvwg-udp-options Transport Options for UDP - Presentation at IETF Nov 2015. Topic thought to fall within TSVWG charter Discussed IETF-96 (Berlin) IETF-97 (Seoul) presented - no comments. IETF-98 (Chicago) 5 + 1 from jabber interested in this topic, 1 thought we shouldn't Comments on security model and discussed on list Adoption call until 31st May 2017 - Closed Tom Jones - supports adoption (will try an implementation) Tom Herbert - supports adoption (will review) Mike Heard - supports adoption (will review) D Fawcus - supports adoption (will review) DUE: Chairs discuss status and intended date for milestone DUE: Please discuss on the TSVWG list. ------------------------------------------------------------------- Adoption Call in Progress: --- None. ------------------------------------------------------------------- Drafts under consideration by WG for adoption: --- draft-roca-tsvwg-fecframev2 - Document Shepherd: TBD Currently individual draft, TSVWG will consider this. IETF-97 (Seoul), presented - could this be an update rather than bis? Adoption call requested by authors IETF-98 10 people had interest in work on this topic. DUE: Please discuss on the TSVWG list. ----------------------------------- Other drafts and work items linked to TSVWG: --- draft-tuexen-tsvwg-sctp-udp-encaps-cons - Document Shepherd: TBD Thought to fall within TSVWG charter Presented to TSVWG in Buenos Aires (April 2016) Update at Soul IETF (Nov 2016) DUE: Please discuss on the TSVWG list. ---- draft-fairhurst-tsvwg-transport-encrypt DUE: Please discuss on the TSVWG list. --- Liaisons: ITU-T Study Group 12 Liaison on QoS Classes & markings for interconnection IEEE liaison to support L2/L3 work on ECN marking 3GPP liaison to support L2/L3 work on ECN marking ================================================================== From nobody Fri Jun 9 00:16:57 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFE0128CDB; Fri, 9 Jun 2017 00:16:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149699260973.2922.143731052095138520@ietfa.amsl.com> Date: Fri, 09 Jun 2017 00:16:49 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 07:16:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Transport Options for UDP Author : Joe Touch Filename : draft-ietf-tsvwg-udp-options-00.txt Pages : 27 Date : 2017-06-08 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-00 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 9 00:17:04 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B434F1294E6; Fri, 9 Jun 2017 00:16:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149699261170.2972.10690516027389360215@ietfa.amsl.com> Date: Fri, 09 Jun 2017 00:16:51 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 07:16:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Transport Options for UDP Author : Joe Touch Filename : draft-ietf-tsvwg-udp-options-00.txt Pages : 27 Date : 2017-06-08 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-00 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 9 09:24:53 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADDB1292FC for ; Fri, 9 Jun 2017 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7R3E0pjxO8YP for ; Fri, 9 Jun 2017 09:24:50 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF76128DE5 for ; Fri, 9 Jun 2017 09:24:50 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v59GOIlr020450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Jun 2017 09:24:19 -0700 (PDT) References: <149699261170.2972.10690516027389360215@ietfa.amsl.com> To: tsvwg@ietf.org From: Joe Touch Message-ID: Date: Fri, 9 Jun 2017 09:24:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149699261170.2972.10690516027389360215@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 16:24:52 -0000 Hi, all, This is an update to change from an individual to a WG doc. There are no other changes at this time. Joe On 6/9/2017 12:16 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group of the IETF. > > Title : Transport Options for UDP > Author : Joe Touch > Filename : draft-ietf-tsvwg-udp-options-00.txt > Pages : 27 > Date : 2017-06-08 > > Abstract: > Transport protocols are extended through the use of transport header > options. This document experimentally extends UDP by indicating the > location, syntax, and semantics for UDP transport layer options. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-00 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-00 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 11 04:21:10 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDC4124D85 for ; Sun, 11 Jun 2017 04:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 e7XcgUeCYbGq for ; Sun, 11 Jun 2017 04:21:07 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3391294CC for ; Sun, 11 Jun 2017 04:21:04 -0700 (PDT) Received: from [192.168.1.204] (p57BB5D0A.dip0.t-ipconnect.de [87.187.93.10]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id CFA1F721E280D; Sun, 11 Jun 2017 13:21:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Tuexen In-Reply-To: <592B2400.7080407@erg.abdn.ac.uk> Date: Sun, 11 Jun 2017 13:20:57 +0200 Cc: tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <592B239D.3030802@erg.abdn.ac.uk> <592B2400.7080407@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata to conclude 12th June 2017. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 11:21:09 -0000 > On 28. May 2017, at 21:24, Gorry Fairhurst = wrote: >=20 > On 28/05/2017, 20:23, Gorry Fairhurst wrote: >> This email notes the start of a WGLC for draft-ietf-tsvwg-sctp-ndata. >>=20 >> Please send notes to this list or the WG Chairs, if you support = publication of this draft or have any comments on the current revision = of this document. The intended status (if the document completes the = WGLC) is PS. >>=20 >> The WGLC will conclude 12th June 2017. >>=20 >> Best wishes, >>=20 >> Gorry, David and Wes. >>=20 > I have the read above document during the WGLC and I would like to add = the following comments to the WGLC for this draft. Hi Gorry, thank you very much for reviewing the document. Please see my comments = including a single question in-line. Best regards Michael >=20 > Best wishes, >=20 > Gorry >=20 > ---- > OLD: > allowing to have up to > NEW: > allowing up to > - may be better English? Sure: Taken. > --- > OLD: > Therefore it is impossible for the sender to > NEW: > This document allows an SCTP sender to > - The impossibility cited was the case before this document is = approved. I think > the alternative wording avoids this. Taken. > --- > OLD: > complaint implementation not supporting > NEW: > complaint implementation that does not support > --- Taken (using compliant instead of complaint). >=20 > OLD: > which has been omitted from the I-DATA chunk > NEW: > (The I-Data chunk omits a TSN.) > - Slightly confusing wording. Taken by using (The I-DATA chunk omits a SSN.) > --- > Figure 2 > I understood Figure 2 perfectly when I last read it, now some time has = passed I found it a little harder. I think this would be much easier to = understand if the text explained that this shows a scheduler with two = queues of messages. Queue 1 has three messages, queue 2 has one larger = message that is interleaved by dividing ... etc and explain 0...8 etc. The meaning of the different numbers is given in the figures, but I = added to clarifying text. > --- > Section 3.2, 3.3 etc contain the word =E2=80=9Cscheduler=E2=80=9D in = the title, but section 3.1 did not, but the text still refers to this as = a scheduler, so please update the section 3.1 title to include the word = =E2=80=9Cscheduler=E2=80=9D to be consistent. Done. > --- > Section 3.3 > - insert comma before /which/. Done. > --- > Section 3.6 > - Speaks of bandwidth (twice), whereas I think it would be clearer to = use the word =E2=80=9Ccapacity=E2=80=9D since this is about sharing = network capacity. Replaced. But there are three occurrences of bandwidth, not three. So I = replaced all three. Doesn't the same argument apply to section 3.5? Three occurrences = there... > --- > Section 4.1 > OLD: > Exposition > NEW: > Exposure > - Wrong word! Taken. > --- > Section 4.1 > - For avoidance of doubt, please use the title of the section in = RFC6458 with each entry, i.e., =E2=80=9CSCTP Header Information = Structure=E2=80=9D and =E2=80=9CExtended SCTP Header Information = Structure=E2=80=9D and =E2=80=9CSCTP Receive Information Structure=E2=80=9D= . Done. > --- >=20 From nobody Mon Jun 12 10:52:54 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE98129564 for ; Mon, 12 Jun 2017 10:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 lmb5uFwX_Yth for ; Mon, 12 Jun 2017 10:52:49 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 551C5129568 for ; Mon, 12 Jun 2017 10:52:48 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3As6usrhZzprcceDLDbEvu86j/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZoMq5bnLW6fgltlLVR4KTs6sC0LuJ9fi4EUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRp?= =?us-ascii?q?OOv1BpTSj8Oq3Oyu5pHfeQtFiT6/bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+?= =?us-ascii?q?RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPC?= =?us-ascii?q?TQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhz?= =?us-ascii?q?sGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7WYNEUSndbXstJWSJPAp2y?= =?us-ascii?q?YYgSAeUOIelWoI7zp0cVoBuiHAmjGP/jxyVUinL026AxzuQvERvB3AwlB98Avm?= =?us-ascii?q?7Uo8/6NKcVUeK+0bHGzTTfYPNL3Tfy9pPIfQw8ofqRWr9/bNDRxlMgFwPClVWc?= =?us-ascii?q?s4rlPzKJ2eQQt2iU8fFgWv6yi2M8tw5xuSKjxt8xiobSnI4V0FfE+Dx/zY0oJt?= =?us-ascii?q?O4UFZ2bcOrHZdNrS2XNIt7Ttk8T212uis20LMLtJimdyYQ0psn3QTQa/mffoiN?= =?us-ascii?q?5RLsSfieLC9jhHJgZLK/nxGy8VW8yuHkVsm7zlJKri1dn9nSs3ACzR3T6sydRv?= =?us-ascii?q?Rh5Uetwy6P1x3I5e1eO0A0krLXK58nwrEuipoeqVnPEyDrlEnsj6Kbdl8o9va2?= =?us-ascii?q?5+nleLnrqIeQN4puhQH/NqQulNa/AeM9MgUWQmeb4/6z1LLk/U3iWrlKiPw2nb?= =?us-ascii?q?XEsJDeO8sbvbK2AxJO34k/8BazFS+m0MkDknUdNlJFfwqLj5L1NFHWPPD4EfC/?= =?us-ascii?q?jkywkDdw2fDHMLLhD47MLnfdjLfhc6xx60lGyAo8nphj4MdIEa8eL9ryV1P/8t?= =?us-ascii?q?vCAUwXKQuxlsr9Adp6NMs4WGmSBqKCO76a5VOS7+0oOK+KZYQIvDvmIOUN7OWo?= =?us-ascii?q?lWIz30UaK/r6laALYWy1S6w1a36SZmDh15JYST8H?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BWCgCa0z5Z/wPjVY1cHgYMGQYMgwCGE?= =?us-ascii?q?IsLkFuYNYYkg0sBAQEBAQEBAQIBaihCAQQJgWMkAYJqVhIBIgINGQJbikewOoI?= =?us-ascii?q?mjAGBC4dshz5igkaCYQWROgGNBKVPlGoCV4EKUYU8DAGCSIJigk2FIgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2BWCgCa0z5Z/wPjVY1cHgYMGQYMgwCGEIsLkFuYNYYkg0s?= =?us-ascii?q?BAQEBAQEBAQIBaihCAQQJgWMkAYJqVhIBIgINGQJbikewOoImjAGBC4dshz5ig?= =?us-ascii?q?kaCYQWROgGNBKVPlGoCV4EKUYU8DAGCSIJigk2FIgEBAQ?= X-IronPort-AV: E=Sophos;i="5.39,334,1493672400"; d="scan'208";a="823136" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 12 Jun 2017 20:52:46 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id EE8721A60122; Mon, 12 Jun 2017 20:52:45 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id DZ_FLMS-BN06; Mon, 12 Jun 2017 20:52:45 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id D38411A6013E; Mon, 12 Jun 2017 20:52:45 +0300 (EEST) Received: from vmail.cs.pub.ro (vmail.cs.pub.ro [141.85.227.3]) by vmail.cs.pub.ro (Postfix) with ESMTP id D093C1A60122; Mon, 12 Jun 2017 20:52:45 +0300 (EEST) Date: Mon, 12 Jun 2017 20:52:45 +0300 (EEST) From: =?utf-8?Q?Drago=C8=99?= Niculescu To: tsvwg@ietf.org Cc: Vladimir Olteanu Message-ID: <102859809.3449894.1497289965806.JavaMail.zimbra@cs.pub.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC55 (Linux)/8.6.0_GA_1194) Thread-Topic: SOCKSv6 Thread-Index: 1qx9rokzZ2v9tJSVc2kNrG8UAktbaw== Archived-At: Subject: [tsvwg] SOCKSv6 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 17:52:52 -0000 Hello,=20 At University Politehnica of Bucharest we have a project building a TCP pro= xy protocol that is meant as an upgrade to SOCKS to leverage some benefits = at the transport layer that came after SOCKSv5 such as TCP fastopen, and mu= ltipath TCP. The current design targets the following advantages:=20 1. Reduced RTTs compared to SOCKSv5;=20 2. Can leverage TFO on the client-proxy and/or proxy-server leg; 3. Enhances MPTCP proxy assisted deployment, can achieve 0-RTT authenticati= on; =20 Our prototype is coming along nicely and will hopefully be deployed at Oran= ge Romania next year, but we are interested in standardizing it too. Is TSVWG the right venue to discuss this?=20 Any suggestion is appreciated.=20 --=20 Drago=C8=99 From nobody Mon Jun 12 22:39:53 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0119A129B41; Mon, 12 Jun 2017 22:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hsSaTxfOSv6n; Mon, 12 Jun 2017 22:39:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE7C129B39; Mon, 12 Jun 2017 22:39:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F0BFDB80D78; Mon, 12 Jun 2017 22:39:39 -0700 (PDT) To: d3e3e3@gmail.com, lucy.yong@huawei.com, edward.crabbe@gmail.com, xuxiaohu@huawei.com, tom@herbertland.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170613053939.F0BFDB80D78@rfc-editor.org> Date: Mon, 12 Jun 2017 22:39:39 -0700 (PDT) Archived-At: Subject: [tsvwg] [Errata Verified] RFC8086 (5006) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 05:39:52 -0000 The following errata report has been verified for RFC8086, "GRE-in-UDP Encapsulation". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5006 -------------------------------------- Status: Verified Type: Editorial Reported by: Donald Eastlake Date Reported: 2017-04-28 Verified by: RFC Editor Section: 8 Original Text ------------- Section 3.1.9 of [RFC8085] discusses the congestion considerations for design and use of UDP tunnels; Corrected Text -------------- Section 3.1.11 of [RFC8085] discusses the congestion considerations for design and use of UDP tunnels; Notes ----- There appears to be an incorrect reference to 3.1.9 that should refer to 3.1.11. -------------------------------------- RFC8086 (draft-ietf-tsvwg-gre-in-udp-encap-19) -------------------------------------- Title : GRE-in-UDP Encapsulation Publication Date : March 2017 Author(s) : L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF From nobody Fri Jun 16 07:14:47 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3C0129C0C; Fri, 16 Jun 2017 07:14:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149762248601.523.13916013376547313268@ietfa.amsl.com> Date: Fri, 16 Jun 2017 07:14:46 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc6040update-shim-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 14:14:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim Author : Bob Briscoe Filename : draft-ietf-tsvwg-rfc6040update-shim-02.txt Pages : 15 Date : 2017-06-16 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. It surveys widely deployed IP tunnelling protocols separated by a shim and updates the specifications of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE and Teredo). The specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-02 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 16 07:54:03 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810141300F0 for ; Fri, 16 Jun 2017 07:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 pXdygeO9gakT for ; Fri, 16 Jun 2017 07:53:59 -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 4EC13131933 for ; Fri, 16 Jun 2017 07:48:01 -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:From:Cc:To:References:Subject: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=3+wZkvfKs9fb9+uDAn1DLdzfdWolRZg3kDox76ACNaI=; b=11WmQRg7cVgNiddke+Eyt3+eu NVqDMzjYIqhsnuBpwPuzgwFb6Ae8E6S7soYJDZ74NsczWB86969czKWce1b3yLLgJHwl15Vyp2xrU FofPTg8OYsZc3IhULPAhGEaVz9wkko1Wpr0wUBExACm240aN+iqU0KboQV8C5mR1EAPADpX904s7U Q1I2i9zjU6uUSQdT0CZV2nferCTBWCg+H8Q3WBMnG4CXjY9R1CsLrGcT/uWx0U4MB6iRiHgYoE5jr PZ7ovGkKdqYcTabnLeE0jg0zFVBuEyB6CJxwHjMmWSqPQ4G7CesqJ6S4SdwtXajuy3cNrfQiJ1RGR MH5JX7C5Q==; Received: from 167.6.208.46.dyn.plus.net ([46.208.6.167]:57660 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dLsXX-0001R4-Gg; Fri, 16 Jun 2017 15:47:59 +0100 References: <149762248621.523.6078795399785182097.idtracker@ietfa.amsl.com> To: "Black, David" Cc: tsvwg IETF list From: Bob Briscoe X-Forwarded-Message-Id: <149762248621.523.6078795399785182097.idtracker@ietfa.amsl.com> Message-ID: Date: Fri, 16 Jun 2017 15:47:58 +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: <149762248621.523.6078795399785182097.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------9C0AF392360957E1845C626A" 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: Subject: [tsvwg] New Version draft-ietf-tsvwg-rfc6040update-shim-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 14:54:01 -0000 This is a multi-part message in MIME format. --------------9C0AF392360957E1845C626A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit David, as doc shepherd. I have just posted a major revision to draft-ietf-tsvwg-rfc6040update-shim Please also take this as a request to give a 10min presentation in tsvwg. As requested, I included specific text necessary to update certain shim tunnel protocols that didn't mention ECN at all (L2TPv2, L2TPv3, GRE). There are two others to do: * Teredo: I'll do this once I hear from the original author, Christian Huitema * VXLAN-GPE: This is a draft currently going through NVO3 on the standards track. AFAIK the Linux implementation already supports ECN via RFC6040, but the authors will need to add ECN text to the spec, so there is something for other implementations to follow. I have contacted them - they should do this, not me. I have also added more protocols to the list (e.g. CAPWAP, LISP), but these already supported ECN. As you have seen, I have been in conversation with people on the l2tpext list, and on opsawg (for CAPWAP). I haven't found anyone specific to talk to regarding GRE yet, but I have notified int-area and I gave a heads-up at a recent IETF. BTW, your plan was to last call draft-ietf-tsvwg-rfc6040update-shim along with ecn-encap-guidelines, deadline Sep 2017. I should point out that draft-ietf-trill-ecn-support is in WGLC in trill, and it depends normatively on ecn-encap-guidelines opsawg would like to last call draft-ietf-tsvwg-rfc6040update-shim as well (altho I have now realized that no update to CAPWAP is needed, but opsawg is now working on alternative tunnelling protocols to CAPWAP: draft-ietf-opsawg-capwap-alt-tunnel ). I guess int-area might want to last call draft-ietf-tsvwg-rfc6040update-shim too. Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-tsvwg-rfc6040update-shim-02.txt Date: Fri, 16 Jun 2017 07:14:46 -0700 From: internet-drafts@ietf.org To: Bob Briscoe A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-02.txt has been successfully submitted by Bob Briscoe and posted to the IETF repository. Name: draft-ietf-tsvwg-rfc6040update-shim Revision: 02 Title: Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim Document date: 2017-06-16 Group: tsvwg Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ Htmlized: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-02 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. It surveys widely deployed IP tunnelling protocols separated by a shim and updates the specifications of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE and Teredo). The specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. 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 --------------9C0AF392360957E1845C626A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit David, as doc shepherd.

I have just posted a major revision to draft-ietf-tsvwg-rfc6040update-shim

Please also take this as a request to give a 10min presentation in tsvwg.

As requested, I included specific text necessary to update certain shim tunnel protocols that didn't mention ECN at all (L2TPv2, L2TPv3, GRE).
There are two others to do:
* Teredo: I'll do this once I hear from the original author, Christian Huitema
* VXLAN-GPE: This is a draft currently going through NVO3 on the standards track. AFAIK the Linux implementation already supports ECN via RFC6040, but the authors will need to add ECN text to the spec, so there is something for other implementations to follow. I have contacted them - they should do this, not me.

I have also added more protocols to the list (e.g. CAPWAP, LISP), but these already supported ECN.

As you have seen, I have been in conversation with people on the l2tpext list, and on opsawg (for CAPWAP). I haven't found anyone specific to talk to regarding GRE yet, but I have notified int-area and I gave a heads-up at a recent IETF.


BTW, your plan was to last call draft-ietf-tsvwg-rfc6040update-shim along with ecn-encap-guidelines, deadline Sep 2017.
I should point out that draft-ietf-trill-ecn-support is in WGLC in trill, and it depends normatively on ecn-encap-guidelines

opsawg would like to last call draft-ietf-tsvwg-rfc6040update-shim as well (altho I have now realized that no update to CAPWAP is needed, but opsawg is now working on alternative tunnelling protocols to CAPWAP: draft-ietf-opsawg-capwap-alt-tunnel ). I guess int-area might want to last call draft-ietf-tsvwg-rfc6040update-shim too.



Bob


-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-tsvwg-rfc6040update-shim-02.txt
Date: Fri, 16 Jun 2017 07:14:46 -0700
From: internet-drafts@ietf.org
To: Bob Briscoe <ietf@bobbriscoe.net> 


A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-02.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name:		draft-ietf-tsvwg-rfc6040update-shim
Revision:	02
Title:		Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
Document date:	2017-06-16
Group:		tsvwg
Pages:		15
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-02

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.  It
   surveys widely deployed IP tunnelling protocols separated by a shim
   and updates the specifications of those that do not mention ECN
   propagation (L2TPv2, L2TPv3, GRE and Teredo).  The specification also
   updates RFC 6040 with configuration requirements needed to make any
   legacy tunnel ingress safe.

                                                                                  


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
--------------9C0AF392360957E1845C626A-- From nobody Mon Jun 19 04:38:09 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FCA12E91F; Mon, 19 Jun 2017 04:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 S8rJ19LjFQbm; Mon, 19 Jun 2017 04:37:57 -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 D6D8812EAB4; Mon, 19 Jun 2017 04:37:37 -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:From:References:Cc:To:Subject: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=hcAXDESNWADKYaxvYuHwG7U1Uutc7jxLWgUa3rDxo6I=; b=Mg7bms9wsWzyGHXUWF/1J2ByS LWMlxnfICWaH30HlgaB0HoQV+rlD0MKKeah8woPVFOJ2K0++NLTL2EQfpg+ZzsCXsLllJZ8mDmyZQ clfz3rOZ0NP3gUtagpHgsM4TQKzr1r7Jfih8Bu9ZivceLhy6lBobmkqmwgM+pOKeEuAoFRGqxAaUO IZqHyjgusXY8ULXt+mj7CrVaYoKzFxdjfJFSZSRLlQ7Jz0b9Mh4mh5JzbWABMvbsrl+R8fTIoEFhX GKlg3940/VTNwnIuQn9Cvt+zYNjgvLWn4tYAqq4FnjkjiDf9FIJs+K2zHCdZ87LlLIDcrXwZHCbSy aIlosbAWQ==; Received: from 167.6.208.46.dyn.plus.net ([46.208.6.167]:60444 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dMuzu-0003rt-Rj; Mon, 19 Jun 2017 12:37:35 +0100 To: Joe Touch Cc: tsvwg IETF list , "nvo3@ietf.org" References: <0fe496f1-f177-e08d-44a2-3e83849c8458@bobbriscoe.net> <5d2d437f-0c93-e28f-a77c-ba0c5e4a562c@isi.edu> From: Bob Briscoe Message-ID: Date: Mon, 19 Jun 2017 12:37: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: <5d2d437f-0c93-e28f-a77c-ba0c5e4a562c@isi.edu> Content-Type: multipart/alternative; boundary="------------F8356FF6DC113BA9DE833CD9" 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: Subject: Re: [tsvwg] [nvo3] VXLAN-GPE Support for ECN propagation between IP headers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 11:38:00 -0000 This is a multi-part message in MIME format. --------------F8356FF6DC113BA9DE833CD9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Joe, [Cutting the distr to nvo3 and adding tsvwg.] On 16/06/17 20:38, Joe Touch wrote: > > Hi, Bob, > > This approach seems to assume an integrated implementation of multiple > protocol layers. > > There are other cases where the "shim" is added indirectly, as a > packet is "tunneled" independently over multiple protocols. > So what aspect of the following para (in S.3.1) does not include the case(s) you are thinking of: In some cases a tunnel adds an outer IP header and a tightly coupled shim header to an inner header that is not an IP header, but that in turn encapsulates an IP header (or might encapsulate an IP header). For instance an inner Ethernet (or other link layer) header might encapsulate an inner IP header as its payload. We call this a tightly coupled shim over an encapsulating header. Can you be more specific? Or perhaps give an example? Or suggest an edit to the above text? > I scanned the draft and didn't see this addressed explicitly (maybe I > missed it). It's implied throughout 3.2 but never stated as a MAY, > e.g., systems MAY support ECN across shim layers but are NOT REQUIRED > to do so. Can that sort of explicit caveat be included? This case > might be added as a final bullet in the list at the end of section 3.2. > Section 3.2 solely gives the cases where ECN is not or cannot be supported, so any ECN field in an outer IP header will have to be zeroed (typically by configuration because the implementation will not include any ECN logic). If none of the cases listed in S.3.2 applies, then you would be in the territory of section 3.1 (i.e. supporting ECN would already be covered by RFC6040). S.3.2 is solely there to plug an important hole that was left in RFC6040. RFC6040 said what implementers have to do to support RFC6040, but it did not include what /network operators/ have to do if they have an implementation that does not support any ECN tunnelling spec (RFC6040, RFC4301 or full functionality mode of RFC3168). Have I misunderstood your point? Could I have made the text clearer? I only realized S.3.2 was needed when I discovered that there is still equipment being built that is copying the 8-bit ToS byte from inner to outer as if the Internet Protocol is still as it was before Diffserv was standardized 19 years ago (Dec 1998). I suspect lazy implementers search for "Internet Protocol header" and follow the many outdated articles you can find on the Web, rather than checking the RFCs. For instance, the 2nd hit from Google (ranked just below Wikipedia) erroneously tells us that the 8-bit ToS field contains 3 precedence bits (that are ignored), 4 ToS bits and 1 currently unused bit. I am not going to cite the link here, which will just reinforce its ranking. Bob > Joe > > > On 6/16/2017 7:25 AM, Bob Briscoe wrote: >> Fabio, Larry, Uri, >> >> I notice VXLAN-GPE is on the IETF standards track. >> It will need to specify support for propagation of the ECN field >> between inner and outer for cases when there is (or might be) an IP >> header (v4 or v6) within the L2 encapsulation, and when the outer is >> IP (v4 or v6). >> >> I believe ECN propagation between inner and outer is already in the >> Linux code for VXLAN, but it's not specified in RFC7348, so other >> implementations might overlook it. Given that ECN is heavily used in >> DCs (e.g. for DCTCP), this is a significant omission. >> >> Please refer to draft-ietf-tsvwg-rfc6040update-shim >> and >> RFC6040. >> >> I will warn you that, unless you believe that all existing VXLAN >> implementations already support ECN, this will not be just a >> straightforward case of referencing the appropriate RFCs. If there >> might be non-ECN VXLAN decapsulators out there, the tunnel ingress >> will have to know (by config or capability negotiation) whether the >> egress supports ECN propagation, and if not, switch to 'compatibility >> mode' (zeroing the outer ECN field). That could require definition of >> a capability parameter during tunnel set-up (unless you envisage >> tunnel set up will always be by administrative config). >> >> Cheers >> >> >> >> Bob >> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------F8356FF6DC113BA9DE833CD9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Joe,

[Cutting the distr to nvo3 and adding tsvwg.]

On 16/06/17 20:38, Joe Touch wrote:

Hi, Bob,

This approach seems to assume an integrated implementation of multiple protocol layers.

There are other cases where the "shim" is added indirectly, as a packet is "tunneled" independently over multiple protocols.


So what aspect of the following para (in S.3.1) does not include the case(s) you are thinking of:
   In some cases a tunnel adds an outer IP header and a tightly coupled
   shim header to an inner header that is not an IP header, but that in
   turn encapsulates an IP header (or might encapsulate an IP header).
   For instance an inner Ethernet (or other link layer) header might
   encapsulate an inner IP header as its payload.  We call this a
   tightly coupled shim over an encapsulating header.
Can you be more specific? Or perhaps give an example? Or suggest an edit to the above text?

I scanned the draft and didn't see this addressed explicitly (maybe I missed it). It's implied throughout  3.2 but never stated as a MAY, e.g., systems MAY support ECN across shim layers but are NOT REQUIRED to do so. Can that sort of explicit caveat be included? This case might be added as a final bullet in the list at the end of section 3.2.

Section 3.2 solely gives the cases where ECN is not or cannot be supported, so any ECN field in an outer IP header will have to be zeroed (typically by configuration because the implementation will not include any ECN logic).

If none of the cases listed in S.3.2 applies, then you would be in the territory of section 3.1 (i.e. supporting ECN would already be covered by RFC6040).

S.3.2 is solely there to plug an important hole that was left in RFC6040. RFC6040 said what implementers have to do to support RFC6040, but it did not include what /network operators/ have to do if they have an implementation that does not support any ECN tunnelling spec (RFC6040, RFC4301 or full functionality mode of RFC3168).

Have I misunderstood your point? Could I have made the text clearer?

I only realized S.3.2 was needed when I discovered that there is still equipment being built that is copying the 8-bit ToS byte from inner to outer as if the Internet Protocol is still as it was before Diffserv was standardized 19 years ago (Dec 1998).

I suspect lazy implementers search for "Internet Protocol header" and follow the many outdated articles you can find on the Web, rather than checking the RFCs. For instance, the 2nd hit from Google (ranked just below Wikipedia) erroneously tells us that the 8-bit ToS field contains 3 precedence bits (that are ignored), 4 ToS bits and 1 currently unused bit. I am not going to cite the link here, which will just reinforce its ranking.


Bob

Joe


On 6/16/2017 7:25 AM, Bob Briscoe wrote:
Fabio, Larry, Uri,

I notice VXLAN-GPE is on the IETF standards track.
It will need to specify support for propagation of the ECN field between inner and outer for cases when there is (or might be) an IP header (v4 or v6) within the L2 encapsulation, and when the outer is IP (v4 or v6).

I believe ECN propagation between inner and outer is already in the Linux code for VXLAN, but it's not specified in RFC7348, so other implementations might overlook it. Given that ECN is heavily used in DCs (e.g. for DCTCP), this is a significant omission.

Please refer to draft-ietf-tsvwg-rfc6040update-shim and RFC6040.

I will warn you that, unless you believe that all existing VXLAN implementations already support ECN,  this will not be just a straightforward case of referencing the appropriate RFCs. If there might be non-ECN VXLAN decapsulators out there, the tunnel ingress will have to know (by config or capability negotiation) whether the egress supports ECN propagation, and if not, switch to 'compatibility mode' (zeroing the outer ECN field). That could require definition of a capability parameter during tunnel set-up (unless you envisage tunnel set up will always be by administrative config).

Cheers



Bob


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


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3




_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------F8356FF6DC113BA9DE833CD9-- From nobody Mon Jun 19 05:46:51 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A053312EC60; Mon, 19 Jun 2017 05:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 lRDPs1MpyyJM; Mon, 19 Jun 2017 05:46:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BD912EC03; Mon, 19 Jun 2017 05:46:42 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v5JCjNs8008865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 19 Jun 2017 05:45:33 -0700 (PDT) To: Bob Briscoe Cc: tsvwg IETF list , "nvo3@ietf.org" References: <0fe496f1-f177-e08d-44a2-3e83849c8458@bobbriscoe.net> <5d2d437f-0c93-e28f-a77c-ba0c5e4a562c@isi.edu> From: Joe Touch Message-ID: <1e58ef8a-b996-5b47-e3c7-91761663c9e8@isi.edu> Date: Mon, 19 Jun 2017 05:45:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7BA6786F556CA86C54D75B80" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] [nvo3] VXLAN-GPE Support for ECN propagation between IP headers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 12:46:45 -0000 This is a multi-part message in MIME format. --------------7BA6786F556CA86C54D75B80 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Bob, On 6/19/2017 4:37 AM, Bob Briscoe wrote: > Joe, > > [Cutting the distr to nvo3 and adding tsvwg.] > > On 16/06/17 20:38, Joe Touch wrote: >> >> Hi, Bob, >> >> This approach seems to assume an integrated implementation of >> multiple protocol layers. >> >> There are other cases where the "shim" is added indirectly, as a >> packet is "tunneled" independently over multiple protocols. >> > > So what aspect of the following para (in S.3.1) does not include the > case(s) you are thinking of: > In some cases a tunnel adds an outer IP header and a tightly coupled > shim header to an inner header that is not an IP header, but that in > turn encapsulates an IP header (or might encapsulate an IP header). > For instance an inner Ethernet (or other link layer) header might > encapsulate an inner IP header as its payload. We call this a > tightly coupled shim over an encapsulating header. > Can you be more specific? Or perhaps give an example? Or suggest an > edit to the above text? The issue is that the paragraph defines "tightly coupled" in terms of "tightly coupled". AFAICT, "tightly coupled" depends on whether the layers are added all in the same software context or some "peeking" occurs after the shim layer is added but before the final IP. > >> I scanned the draft and didn't see this addressed explicitly (maybe I >> missed it). It's implied throughout 3.2 but never stated as a MAY, >> e.g., systems MAY support ECN across shim layers but are NOT REQUIRED >> to do so. Can that sort of explicit caveat be included? This case >> might be added as a final bullet in the list at the end of section 3.2. >> > Section 3.2 solely gives the cases where ECN is not or cannot be > supported, so any ECN field in an outer IP header will have to be > zeroed (typically by configuration because the implementation will not > include any ECN logic). > > If none of the cases listed in S.3.2 applies, then you would be in the > territory of section 3.1 (i.e. supporting ECN would already be covered > by RFC6040). > > S.3.2 is solely there to plug an important hole that was left in > RFC6040. RFC6040 said what implementers have to do to support RFC6040, > but it did not include what /network operators/ have to do if they > have an implementation that does not support any ECN tunnelling spec > (RFC6040, RFC4301 or full functionality mode of RFC3168). > > Have I misunderstood your point? Could I have made the text clearer? My point is that the propagation of ECN across shim layers needs to be more clearly explained as optional (even, IMO, for "tightly coupled" cases). Right now, it reads more like "OK, so if you're layering has failed to support ECN propagation, here's how to at least make it safe". > > I only realized S.3.2 was needed when I discovered that there is still > equipment being built that is copying the 8-bit ToS byte from inner to > outer as if the Internet Protocol is still as it was before Diffserv > was standardized 19 years ago (Dec 1998). > > I suspect lazy implementers search for "Internet Protocol header" and > follow the many outdated articles you can find on the Web, rather than > checking the RFCs. For instance, the 2nd hit from Google (ranked just > below Wikipedia) erroneously tells us that the 8-bit ToS field > contains 3 precedence bits (that are ignored), 4 ToS bits and 1 > currently unused bit. I am not going to cite the link here, which will > just reinforce its ranking. Agreed, but again you're implying that there's something wrong with code that can't propagate ECN, rather than saying that ECN operates at the IP layer in which it is inserted by routers. Expecting ECN to propagate to tunnels is an optimization that in one sense is useful when it works, but in another is the antithesis of the point of tunneling. Joe --------------7BA6786F556CA86C54D75B80 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, Bob,

On 6/19/2017 4:37 AM, Bob Briscoe wrote:
Joe,

[Cutting the distr to nvo3 and adding tsvwg.]

On 16/06/17 20:38, Joe Touch wrote:

Hi, Bob,

This approach seems to assume an integrated implementation of multiple protocol layers.

There are other cases where the "shim" is added indirectly, as a packet is "tunneled" independently over multiple protocols.


So what aspect of the following para (in S.3.1) does not include the case(s) you are thinking of:
   In some cases a tunnel adds an outer IP header and a tightly coupled
   shim header to an inner header that is not an IP header, but that in
   turn encapsulates an IP header (or might encapsulate an IP header).
   For instance an inner Ethernet (or other link layer) header might
   encapsulate an inner IP header as its payload.  We call this a
   tightly coupled shim over an encapsulating header.
Can you be more specific? Or perhaps give an example? Or suggest an edit to the above text?

The issue is that the paragraph defines "tightly coupled" in terms of "tightly coupled".

AFAICT, "tightly coupled" depends on whether the layers are added all in the same software context or some "peeking" occurs after the shim layer is added but before the final IP.


I scanned the draft and didn't see this addressed explicitly (maybe I missed it). It's implied throughout  3.2 but never stated as a MAY, e.g., systems MAY support ECN across shim layers but are NOT REQUIRED to do so. Can that sort of explicit caveat be included? This case might be added as a final bullet in the list at the end of section 3.2.

Section 3.2 solely gives the cases where ECN is not or cannot be supported, so any ECN field in an outer IP header will have to be zeroed (typically by configuration because the implementation will not include any ECN logic).

If none of the cases listed in S.3.2 applies, then you would be in the territory of section 3.1 (i.e. supporting ECN would already be covered by RFC6040).

S.3.2 is solely there to plug an important hole that was left in RFC6040. RFC6040 said what implementers have to do to support RFC6040, but it did not include what /network operators/ have to do if they have an implementation that does not support any ECN tunnelling spec (RFC6040, RFC4301 or full functionality mode of RFC3168).

Have I misunderstood your point? Could I have made the text clearer?

My point is that the propagation of ECN across shim layers needs to be more clearly explained as optional (even, IMO, for "tightly coupled" cases). Right now, it reads more like "OK, so if you're layering has failed to support ECN propagation, here's how to at least make it safe".


I only realized S.3.2 was needed when I discovered that there is still equipment being built that is copying the 8-bit ToS byte from inner to outer as if the Internet Protocol is still as it was before Diffserv was standardized 19 years ago (Dec 1998).

I suspect lazy implementers search for "Internet Protocol header" and follow the many outdated articles you can find on the Web, rather than checking the RFCs. For instance, the 2nd hit from Google (ranked just below Wikipedia) erroneously tells us that the 8-bit ToS field contains 3 precedence bits (that are ignored), 4 ToS bits and 1 currently unused bit. I am not going to cite the link here, which will just reinforce its ranking.
Agreed, but again you're implying that there's something wrong with code that can't propagate ECN, rather than saying that ECN operates at the IP layer in which it is inserted by routers. Expecting ECN to propagate to tunnels is an optimization that in one sense is useful when it works, but in another is the antithesis of the point of tunneling.

Joe
--------------7BA6786F556CA86C54D75B80-- From nobody Mon Jun 19 09:15:58 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A0113155B for ; Mon, 19 Jun 2017 09:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 cQ5gQWdz4eDo for ; Mon, 19 Jun 2017 09:15:54 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 87F19131553 for ; Mon, 19 Jun 2017 09:15:51 -0700 (PDT) Received: from MacBook-2.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id DD8381B00050 for ; Mon, 19 Jun 2017 19:10:13 +0100 (BST) Message-ID: <5947F8B6.2030408@erg.abdn.ac.uk> Date: Mon, 19 Jun 2017 17:15:50 +0100 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] IETF-99 TSVWG working group in Prague. X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:15:57 -0000 This email asks for people to send agenda requests for the IETF Prague meeting. Presenters will normally discuss items on the list and have published a draft before a request will be accepted. Please send any requests to the WG Chairs, together with the name of the draft, expected issues/requests and estimate of time required. Best wishes, Gorry, Wes and David. Currently requested slots: Vincent Rocca - FecFrame From nobody Mon Jun 19 10:41:51 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B6B131724; Mon, 19 Jun 2017 10:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Z0AAYCAIaFUm; Mon, 19 Jun 2017 10:41:47 -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 9641D131718; Mon, 19 Jun 2017 10:41:46 -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:From:References:Cc:To:Subject: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=FD391m+ZTQ8HPWdBjWS1oW/RO1Eb21eSkTT1whLsi30=; b=Hj4HL3MuQVwwdMAXkCuBM+zf5 jCpRqMAq0YOFH3VnkUii7iGu2BTDTUWWtEzSV1B2zkKmRvdV5iYMmH+f8sJchLpPXK5Z89Ymhozhv boM1U35DmHdTvr2RtGxGfODJoQ0Pd/0exCsAbMtuqrhKSweWoeQ8hsk4KMaiyh0OiFaJsvdkJrN2J 5vlrM8yP/XfTQMx4noItGVhkWyHz3nv5lnX9M9TxYKUAEYeah/MHM6fHwAhbgYKtjLUGsBwh0D2m9 0D2vAPO0f/IYaLPwFmvTcGPvtN6xv9BRDOpT6zX2bwioffXre4Wa6AL7qBgT8LHwSC21wq84R5sOP wnTDjzN9A==; Received: from 167.6.208.46.dyn.plus.net ([46.208.6.167]:35244 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dN0gK-0003zk-Np; Mon, 19 Jun 2017 18:41:45 +0100 To: Joe Touch Cc: tsvwg IETF list , "nvo3@ietf.org" References: <0fe496f1-f177-e08d-44a2-3e83849c8458@bobbriscoe.net> <5d2d437f-0c93-e28f-a77c-ba0c5e4a562c@isi.edu> <1e58ef8a-b996-5b47-e3c7-91761663c9e8@isi.edu> From: Bob Briscoe Message-ID: Date: Mon, 19 Jun 2017 18:41:43 +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: <1e58ef8a-b996-5b47-e3c7-91761663c9e8@isi.edu> Content-Type: multipart/alternative; boundary="------------0422CFA2BED0051959A35AB5" 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: Subject: Re: [tsvwg] [nvo3] VXLAN-GPE Support for ECN propagation between IP headers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 17:41:50 -0000 This is a multi-part message in MIME format. --------------0422CFA2BED0051959A35AB5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Joe, On 19/06/17 13:45, Joe Touch wrote: > > Hi, Bob, > > On 6/19/2017 4:37 AM, Bob Briscoe wrote: >> Joe, >> >> [Cutting the distr to nvo3 and adding tsvwg.] >> >> On 16/06/17 20:38, Joe Touch wrote: >>> >>> Hi, Bob, >>> >>> This approach seems to assume an integrated implementation of >>> multiple protocol layers. >>> >>> There are other cases where the "shim" is added indirectly, as a >>> packet is "tunneled" independently over multiple protocols. >>> >> >> So what aspect of the following para (in S.3.1) does not include the >> case(s) you are thinking of: >> In some cases a tunnel adds an outer IP header and a tightly coupled >> shim header to an inner header that is not an IP header, but that in >> turn encapsulates an IP header (or might encapsulate an IP header). >> For instance an inner Ethernet (or other link layer) header might >> encapsulate an inner IP header as its payload. We call this a >> tightly coupled shim over an encapsulating header. >> Can you be more specific? Or perhaps give an example? Or suggest an >> edit to the above text? > > The issue is that the paragraph defines "tightly coupled" in terms of > "tightly coupled". > > AFAICT, "tightly coupled" depends on whether the layers are added all > in the same software context or some "peeking" occurs after the shim > layer is added but before the final IP. So I think you are not objecting to the para I quoted above, but to something in the previous para, quoted here: In many cases the shim header(s) and the outer IP header are always added (or removed) as part of the same process. We call this a tightly coupled shim header. Processing the shim and outer together is often necessary because the shim(s) are not sufficient for packet forwarding in their own right; not unless complemented by an outer header. Is the phrase "as part of the same process" the one you are objecting to? If so, I have no objection to using an alternative to the word 'process' to avoid the implication that this means specifically one 'process' as defined for the OS in question. It wasn't intended to use the word 'process' so strictly. The more general meaning of 'procedure' or 'routine' was intended. The main point was that the definition of a shim is something that cannot be used alone to forward a packet to another network address, unless it is complemented by an outer PSN header. Whatever, these paragraphs only give context to the subsequent normative text, which (deliberately) doesn't actually rely on these definitions anyway. > >> >>> I scanned the draft and didn't see this addressed explicitly (maybe >>> I missed it). It's implied throughout 3.2 but never stated as a >>> MAY, e.g., systems MAY support ECN across shim layers but are NOT >>> REQUIRED to do so. Can that sort of explicit caveat be included? >>> This case might be added as a final bullet in the list at the end of >>> section 3.2. >>> >> Section 3.2 solely gives the cases where ECN is not or cannot be >> supported, so any ECN field in an outer IP header will have to be >> zeroed (typically by configuration because the implementation will >> not include any ECN logic). >> >> If none of the cases listed in S.3.2 applies, then you would be in >> the territory of section 3.1 (i.e. supporting ECN would already be >> covered by RFC6040). >> >> S.3.2 is solely there to plug an important hole that was left in >> RFC6040. RFC6040 said what implementers have to do to support >> RFC6040, but it did not include what /network operators/ have to do >> if they have an implementation that does not support any ECN >> tunnelling spec (RFC6040, RFC4301 or full functionality mode of RFC3168). >> >> Have I misunderstood your point? Could I have made the text clearer? > > My point is that the propagation of ECN across shim layers needs to be > more clearly explained as optional (even, IMO, for "tightly coupled" > cases). Right now, it reads more like "OK, so if you're layering has > failed to support ECN propagation, here's how to at least make it safe". > >> >> I only realized S.3.2 was needed when I discovered that there is >> still equipment being built that is copying the 8-bit ToS byte from >> inner to outer as if the Internet Protocol is still as it was before >> Diffserv was standardized 19 years ago (Dec 1998). >> >> I suspect lazy implementers search for "Internet Protocol header" and >> follow the many outdated articles you can find on the Web, rather >> than checking the RFCs. For instance, the 2nd hit from Google (ranked >> just below Wikipedia) erroneously tells us that the 8-bit ToS field >> contains 3 precedence bits (that are ignored), 4 ToS bits and 1 >> currently unused bit. I am not going to cite the link here, which >> will just reinforce its ranking. > Agreed, but again you're implying that there's something wrong with > code that can't propagate ECN, rather than saying that ECN operates at > the IP layer in which it is inserted by routers. Expecting ECN to > propagate to tunnels is an optimization that in one sense is useful > when it works, but in another is the antithesis of the point of tunneling. The difficulty being addressed in this section is that blindly copying an inner ECN field to an outer is unsafe (whether or not you want to support ECN). There is so much text in S.3.2 that says ECN is optional that I'm not sure how I can say it any more times without making the reader die of boredom. S.3.2. starts with Even when ECN propagation is not implemented or is not being used, and the proposed new normative text starts: When the implementation of a tunnel ingress does not support [RFC6040 ] or one of its compatible predecessors ([RFC4301 ] or the full functionality mode of [RFC3168 ]) and when the outer tunnel header is IP (v4 or v6), And the section ends with all this: Permanently zeroing the outer ECN field is safe, but it is not sufficient to claim compliance withRFC 6040 because it does not meet the aim of introducing ECN support to tunnels (seeSection 4.3 of [RFC6040] ). Developers and network operators are encouraged to implement and deploy tunnel endpoints compliant withRFC 6040 (as updated by the present specification) in order to provide the benefits of wider ECN deployment [RFC8087 ]. Nonetheless, propagation of ECN between IP headers, whether separated by shim headers or not, has to be OPTIONAL to implement and to use, because: o Legacy implementations of tunnels without any ECN support already exist o A network might be designed so that there is usually no bottleneck within the tunnel o If the tunnel endpoints would have to search within an L2 header to find an encapsulated IP header, it might not be worth the potential performance hit What more do you want me to say, to emphasize that ECN is optional? Preferably, please suggest specific edits. Cheers Bob > > Joe -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------0422CFA2BED0051959A35AB5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Joe,

On 19/06/17 13:45, Joe Touch wrote:

Hi, Bob,

On 6/19/2017 4:37 AM, Bob Briscoe wrote:
Joe,

[Cutting the distr to nvo3 and adding tsvwg.]

On 16/06/17 20:38, Joe Touch wrote:

Hi, Bob,

This approach seems to assume an integrated implementation of multiple protocol layers.

There are other cases where the "shim" is added indirectly, as a packet is "tunneled" independently over multiple protocols.


So what aspect of the following para (in S.3.1) does not include the case(s) you are thinking of:
   In some cases a tunnel adds an outer IP header and a tightly coupled
   shim header to an inner header that is not an IP header, but that in
   turn encapsulates an IP header (or might encapsulate an IP header).
   For instance an inner Ethernet (or other link layer) header might
   encapsulate an inner IP header as its payload.  We call this a
   tightly coupled shim over an encapsulating header.
Can you be more specific? Or perhaps give an example? Or suggest an edit to the above text?

The issue is that the paragraph defines "tightly coupled" in terms of "tightly coupled".

AFAICT, "tightly coupled" depends on whether the layers are added all in the same software context or some "peeking" occurs after the shim layer is added but before the final IP.
So I think you are not objecting to the para I quoted above, but to something in the previous para, quoted here:
   In many cases the shim header(s) and the outer IP header are always
   added (or removed) as part of the same process.  We call this a
   tightly coupled shim header.  Processing the shim and outer together
   is often necessary because the shim(s) are not sufficient for packet
   forwarding in their own right; not unless complemented by an outer
   header.
Is the phrase "as part of the same process" the one you are objecting to?

If so, I have no objection to using an alternative to the word 'process' to avoid the implication that this means specifically one 'process' as defined for the OS in question. It wasn't intended to use the word 'process' so strictly. The more general meaning of 'procedure' or 'routine' was intended.

The main point was that the definition of a shim is something that cannot be used alone to forward a packet to another network address, unless it is complemented by an outer PSN header.

Whatever, these paragraphs only give context to the subsequent normative text, which (deliberately) doesn't actually rely on these definitions anyway.



I scanned the draft and didn't see this addressed explicitly (maybe I missed it). It's implied throughout  3.2 but never stated as a MAY, e.g., systems MAY support ECN across shim layers but are NOT REQUIRED to do so. Can that sort of explicit caveat be included? This case might be added as a final bullet in the list at the end of section 3.2.

Section 3.2 solely gives the cases where ECN is not or cannot be supported, so any ECN field in an outer IP header will have to be zeroed (typically by configuration because the implementation will not include any ECN logic).

If none of the cases listed in S.3.2 applies, then you would be in the territory of section 3.1 (i.e. supporting ECN would already be covered by RFC6040).

S.3.2 is solely there to plug an important hole that was left in RFC6040. RFC6040 said what implementers have to do to support RFC6040, but it did not include what /network operators/ have to do if they have an implementation that does not support any ECN tunnelling spec (RFC6040, RFC4301 or full functionality mode of RFC3168).

Have I misunderstood your point? Could I have made the text clearer?

My point is that the propagation of ECN across shim layers needs to be more clearly explained as optional (even, IMO, for "tightly coupled" cases). Right now, it reads more like "OK, so if you're layering has failed to support ECN propagation, here's how to at least make it safe".


I only realized S.3.2 was needed when I discovered that there is still equipment being built that is copying the 8-bit ToS byte from inner to outer as if the Internet Protocol is still as it was before Diffserv was standardized 19 years ago (Dec 1998).

I suspect lazy implementers search for "Internet Protocol header" and follow the many outdated articles you can find on the Web, rather than checking the RFCs. For instance, the 2nd hit from Google (ranked just below Wikipedia) erroneously tells us that the 8-bit ToS field contains 3 precedence bits (that are ignored), 4 ToS bits and 1 currently unused bit. I am not going to cite the link here, which will just reinforce its ranking.
Agreed, but again you're implying that there's something wrong with code that can't propagate ECN, rather than saying that ECN operates at the IP layer in which it is inserted by routers. Expecting ECN to propagate to tunnels is an optimization that in one sense is useful when it works, but in another is the antithesis of the point of tunneling.
The difficulty being addressed in this section is that blindly copying an inner ECN field to an outer is unsafe (whether or not you want to support ECN).

There is so much text in S.3.2 that says ECN is optional that I'm not sure how I can say it any more times without making the reader die of boredom. S.3.2. starts with
   Even when ECN propagation is not implemented or is not being used,
and the proposed new normative text starts:
      When the implementation of a tunnel ingress does not support
      [RFC6040] or one of its compatible predecessors ([RFC4301] or the
      full functionality mode of [RFC3168]) and when the outer tunnel
      header is IP (v4 or v6),
And the section ends with all this:
   Permanently zeroing the outer ECN field is safe, but it is not
   sufficient to claim compliance with RFC 6040 because it does not meet
   the aim of introducing ECN support to tunnels (see Section 4.3 of
   [RFC6040]).  Developers and network operators are encouraged to
   implement and deploy tunnel endpoints compliant with RFC 6040 (as
   updated by the present specification) in order to provide the
   benefits of wider ECN deployment [RFC8087].  Nonetheless, propagation
   of ECN between IP headers, whether separated by shim headers or not,
   has to be OPTIONAL to implement and to use, because:

   o  Legacy implementations of tunnels without any ECN support already
      exist

   o  A network might be designed so that there is usually no bottleneck
      within the tunnel

   o  If the tunnel endpoints would have to search within an L2 header
      to find an encapsulated IP header, it might not be worth the
      potential performance hit
What more do you want me to say, to emphasize that ECN is optional?

Preferably, please suggest specific edits.

Cheers


Bob


Joe

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------0422CFA2BED0051959A35AB5-- From nobody Wed Jun 21 00:05:02 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC42C1287A0; Wed, 21 Jun 2017 00:04:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149802869465.15920.14912001297881579159@ietfa.amsl.com> Date: Wed, 21 Jun 2017 00:04:54 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 07:04:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol Authors : Randall R. Stewart Michael Tuexen Salvatore Loreto Robin Seggelmann Filename : draft-ietf-tsvwg-sctp-ndata-11.txt Pages : 21 Date : 2017-06-21 Abstract: The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head of line blocking at the sender. Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined. A stream scheduler can choose to either implement, or not implement, user message interleaving. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-11 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-sctp-ndata-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-11 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 21 07:46:21 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0F7129BDA for ; Wed, 21 Jun 2017 07:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=hhy000AG; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=eFbCZFfZ 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 kMfWYfIgBGyE for ; Wed, 21 Jun 2017 07:46:17 -0700 (PDT) Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (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 AC3B8129B5B for ; Wed, 21 Jun 2017 07:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1498056370; x=1529592370; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bpTxtbaADd3UpusQbOrV/TF4L/rFcENN2Gd33C4jMQA=; b=hhy000AGndcV79ZGFH7z9Fk8yjkFOKpDOCSx3PtUBHYoWNTfnv/M2v8E RefC0minuHd73yFpqM+ypVeZ/fUUH+AuBiYPA7lkN3sTDGI1RpREhwgg1 9NuqHxKpdMOubQ29shEw1gzZuGpP3BA0ClU5Uto3tWawwBAuEEIXSM2wx U=; Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 09:46:04 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 20:46:01 +0600 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5LEjx75028307 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jun 2017 10:46:01 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v5LEjx75028307 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1498056361; bh=XL6kIT3h066gi9S/oUg+GoM9CsI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=eFbCZFfZmuceA/KscTskrjyefIH7h2qWAVqAnUe+notzGZOd05xhb2I5hMhihDaig BNJ/oTEZn7rafh7Inx20Hlgxod64hjAJaE3sjOV2nt2MsyUNaGAz9FqyG7hyuvq0db 824lcnEVdXdafJpYaUCLsoFFOJgmQpv9sjgbVbGg= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v5LEjx75028307 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 21 Jun 2017 10:45:48 -0400 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5LEjlbB001841 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 21 Jun 2017 10:45:48 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0352.000; Wed, 21 Jun 2017 10:45:46 -0400 To: Ingemar Johansson S CC: tsvwg IETF list Thread-Topic: WGLC comments on draft-ietf-tsvwg-ecn-experimentation Thread-Index: AdLZ5w8jVW866mTKRGO1T+XnKF0ESgQtYQvg Date: Wed, 21 Jun 2017 14:45:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FB3D823MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] WGLC comments on draft-ietf-tsvwg-ecn-experimentation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:46:19 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FB3D823MX307CL04corpem_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ingemar, Thank you for the careful read - comments inline. Thanks, --David From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] Sent: Wednesday, May 31, 2017 4:37 AM To: Black, David Cc: tsvwg IETF list Subject: WGLC comments on draft-ietf-tsvwg-ecn-experimentation Hi I have read through https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experi= mentation-02 and given that I have read it before I have mostly only editor= ial nits. + Page 13: "..sender SHOULD set the ECT(0) codepoints." Why is it a SHOULD= and not a MUST ? [David>] It should ;-) be a "MUST" - fixed. Minor nits: + I-D.briscoe-tsvwg-ecn-l4s-id should be I-D.ietf-tsvwg-ecn-l4s-id [David>] Updated. + Page 9. The text starting with 'Senders are free...' ending with 'SHOULD = use ECT(0)' make is difficult at first to deduce what is draft/RFC text and= what is comments. An alternative would be to enclose all draft/RFC text in= double quotes "..." . But this is not important, took me roughly 30 second= s to interpret the text correctly :) [David>] Changed lead-in text for that RFC 3168 text to say that two paragr= aphs are removed and changed the lead-in text for the replacement to say th= at it is replaced with one paragraph. That should help clarify that there = are two paragraphs quoted from RFC 3168. Regards /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_CE03DB3D7B45C245BCA0D243277949362FB3D823MX307CL04corpem_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ingemar,

 

Thank you for the care= ful read – comments inline.

 

Thanks, --David

 

From: Ingemar Johansson S [mailto:ingemar.s.j= ohansson@ericsson.com]
Sent: Wednesday, May 31, 2017 4:37 AM
To: Black, David <david.black@emc.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>
Subject: WGLC comments on draft-ietf-tsvwg-ecn-experimentation<= /o:p>

 

Hi

 

I have read through https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-02 and= given that I have read it before I have mostly only editorial nits.

 

+ Page 13: “..sender SHOULD set the ECT(0)= codepoints.”  Why is it a SHOULD and not a MUST ?

[David>] It s= hould ;-) be a “MUST” – fixed.

 

Minor nits:

+ I-D.briscoe-tsvwg-ecn-l4s-id should be I-D.iet= f-tsvwg-ecn-l4s-id

[David>] Upda= ted.

 

+ Page 9. The text starting with ‘Senders = are free…’ ending with ‘SHOULD use ECT(0)’ make is = difficult at first to deduce what is draft/RFC text and what is comments. A= n alternative would be to enclose all draft/RFC text in double quotes “…” . But this is not important, took me roughly 30 seco= nds to interpret the text correctly J

[David>] Chan= ged lead-in text for that RFC 3168 text to say that two paragraphs are remo= ved and changed the lead-in text for the replacement to say that it is repl= aced with one paragraph.  That should help clarify that there are two paragraphs quoted from RFC 3168.=

 

Regards

/Ingemar

 

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_CE03DB3D7B45C245BCA0D243277949362FB3D823MX307CL04corpem_-- From nobody Wed Jun 21 07:46:52 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE17129BF8 for ; Wed, 21 Jun 2017 07:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=W1PiBy/c; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=qQM79HQU 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 n4GtZfrNXz1m for ; Wed, 21 Jun 2017 07:46:49 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 B79FB129B81 for ; Wed, 21 Jun 2017 07:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1498056399; x=1529592399; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BKAPgJB/AiR4Ju1ojw7JpTkfckTEOj3p6okPTYlr/MA=; b=W1PiBy/cEdo7sdIK+gCAb0/iyuppwUBi3DY46rihu7cXUqQQ9rkyy7/b 9DwxBthJH0nqE1KaHF9YSraeFlRAV3UfbUwKzaXA6wVjw95I6bYdtWQ8E wF3s14suAntG0tPQsItp+mtyGzYjo+lE9vcDsc7c6LV3fYf1eAf2ss0Bu s=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 09:46:35 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 20:46:35 +0600 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5LEkWhB024753 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jun 2017 10:46:34 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v5LEkWhB024753 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1498056394; bh=Arm327kpK5DyH/aHWPxHFsNwg74=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=qQM79HQUjX211kd1T6n0EvjOtQogWtUcPGIEzwWQ/Y7ollbY0XKMJ+DPtNSl6GxiX mAa5xUi/AgLql5HLpvFeC2bJ/lTf5cBCKPhAa53etXTmNx68ha7rfX6EPBNCT5K+SB pfLYtC0Q3D05LYnZo7BUKk1HBM7vejvWCtI8r6qk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v5LEkWhB024753 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd54.lss.emc.com (RSA Interceptor); Wed, 21 Jun 2017 10:46:02 -0400 Received: from MXHUB320.corp.emc.com (MXHUB320.corp.emc.com [10.146.3.98]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5LEkIAI004795 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 21 Jun 2017 10:46:19 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB320.corp.emc.com ([10.146.3.98]) with mapi id 14.03.0352.000; Wed, 21 Jun 2017 10:46:17 -0400 To: "De Schepper, Koen (Nokia - BE/Antwerp)" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to conclude 12th June 2017 Thread-Index: AQHS1+gqsOh8TpdoBk253K0k0qi5NaIbgNKAgBQJiSA= Date: Wed, 21 Jun 2017 14:46:16 +0000 Message-ID: References: <592B2416.9030003@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to conclude 12th June 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:46:51 -0000 Koen, Thank you for checking this again during WGLC. Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of De Schepper, > Koen (Nokia - BE/Antwerp) > Sent: Thursday, June 8, 2017 12:47 PM > To: gorry@erg.abdn.ac.uk; tsvwg@ietf.org > Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to > conclude 12th June 2017 >=20 > > -----Original Message----- > > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurs= t > > Sent: zondag 28 mei 2017 21:25 > > To: tsvwg@ietf.org > > Subject: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to > conclude > > 12th June 2017 > > > > This email notes the start of a WGLC for > > draft-ietf-tsvwg-ecn-experimentation. > > > > Please send notes to this list or the WG Chairs, if you support > > publication of this draft or have any comments on the current revision > > of this document. The intended status (if the document completes the > > WGLC) is PS. > > > > The WGLC will conclude 12th June 2017. > > > > Best wishes, > > > > Gorry, David (author of this ID) and Wes. > > > Hi, >=20 > No further comments for WGLC from my side. All are already covered by > other's comments. >=20 > Regards, > Koen. >=20 From nobody Wed Jun 21 07:58:24 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD18129C43; Wed, 21 Jun 2017 07:58:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149805709598.15567.6760712935864557291@ietfa.amsl.com> Date: Wed, 21 Jun 2017 07:58:16 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:58:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Explicit Congestion Notification (ECN) Experimentation Author : David Black Filename : draft-ietf-tsvwg-ecn-experimentation-03.txt Pages : 17 Date : 2017-06-21 Abstract: This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as a replacement for packet drops as indicators of network congestion. It relaxes restrictions in RFC 3168 that would otherwise hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, and provides the rationale for reclassification of RFC 3540 as Historic; this reclassification enables new experimental use of the ECT(1) codepoint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimentation-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-experimentation-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 21 08:01:19 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A5C12EB05 for ; Wed, 21 Jun 2017 08:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=0Iv4sAP8; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=Cdnc0rUP 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 55S_BR8FFTyu for ; Wed, 21 Jun 2017 08:01:14 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 9400912EB0D for ; Wed, 21 Jun 2017 07:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1498057033; x=1529593033; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BYW7BhXXT9eEPRoMdhrcKCnCud3cUGZI+Wc/KXU/v7I=; b=0Iv4sAP8dKCxyXI0loJ/Wocd8HcNrajP1gq0UcDUObvCWx5SDcC899Xg QU/ms/sJUH99/aK+5hL22OR//SnBP3ckaqmRULgQJcPrf6GNK5Dkfm7cm B20dFvNZulX/fT9DHdXFehPi8tCM7GgQP/BvJTqAIyeKM+ikV1J/dOt0v 8=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 09:57:12 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 20:57:12 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5LEv8Ho020577 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jun 2017 10:57:11 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com v5LEv8Ho020577 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1498057031; bh=3ff5gftbyZY4i4y1eHvDlAyhS+U=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Cdnc0rUPEpdB4U04pgBhytbafmEibPLsXmglsfwmVyJ+iJzd4gWeXktWOfO0DJoG+ +DTvGC6NlmS1paZ0yI4HJXY0uz7emkX77BtL64jzENFMDBPordYhR59IQ4pTLew9eg FclEH3hyAqe2YW9ePj9VNc+6FSIwsILPTL6SKzEw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com v5LEv8Ho020577 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 21 Jun 2017 10:56:55 -0400 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5LEuqsb013022 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 21 Jun 2017 10:56:54 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0352.000; Wed, 21 Jun 2017 10:56:51 -0400 To: "gorry@erg.abdn.ac.uk" CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to conclude 12th June 2017 Thread-Index: AQHS1+gqsOh8TpdoBk253K0k0qi5NaIKY+4AgCUpaVA= Date: Wed, 21 Jun 2017 14:56:52 +0000 Message-ID: References: <592B2416.9030003@erg.abdn.ac.uk> <592B2476.6030201@erg.abdn.ac.uk> In-Reply-To: <592B2476.6030201@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to conclude 12th June 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 15:01:18 -0000 Done, about to upload -03, Thanks, --David > -----Original Message----- > From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: Sunday, May 28, 2017 3:27 PM > To: gorry@erg.abdn.ac.uk > Cc: tsvwg@ietf.org > Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to > conclude 12th June 2017 >=20 > On 28/05/2017, 20:25, Gorry Fairhurst wrote: > > This email notes the start of a WGLC for > > draft-ietf-tsvwg-ecn-experimentation. > > > > Please send notes to this list or the WG Chairs, if you support > > publication of this draft or have any comments on the current revision > > of this document. The intended status (if the document completes the > > WGLC) is PS. > > > > The WGLC will conclude 12th June 2017. > > > > Best wishes, > > > > Gorry, David (author of this ID) and Wes. > > > I have the following comments during the WGLC for the above document: >=20 > --- > OLD: > it would drop Not-ECT packets . > NEW: > it would drop Not-ECT packets. > - remove space before full stop. > --- > Please update the names of all drafts when revising this draft. > --- >=20 > Best wishes, >=20 > Gorry From nobody Wed Jun 21 08:17:04 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9757712EB3E for ; Wed, 21 Jun 2017 08:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=AkgonrH4; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=rC9N53VC 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 hWRgFpB7ds-x for ; Wed, 21 Jun 2017 08:16:59 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (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 A48C8129C16 for ; Wed, 21 Jun 2017 08:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1498057914; x=1529593914; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WLx4l3pRSjeoNSlPK0yFiT3/Ct0Ai/G9/HV5DXKx3X4=; b=AkgonrH4afDwoAuQqQKpmYJndSZ1ERJcvDee4YeB7jJ8dli8YNKygbuT wbJ5StY8jROzJwMJgoj4vfVvtiiV4OS75yAQ9UN+X/WLZl61bcABz+iml DHsQ3cZ/hoJO96jqmicmOf/Obk5NqGX0WtRTyEA4xFNHitZbsbF4fd1Yj 8=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 10:11:54 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 21:09:15 +0600 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5LFCHer030399 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 21 Jun 2017 11:12:17 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com v5LFCHer030399 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1498057937; bh=QQYKgN8vIiDLl7EavnbsAFzu0S8=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rC9N53VCYrXnH4TryQ7IpwimkjKYZ2ByYbzfiEb8y+dlA4e131EeA4Tqy2IIkLQmJ 0juWsdoHYlVKS4DeuUPfaBgZ4LJv9QWBjHdbFt8OOl5hptaOinwBflhyTgZRm/KkV6 CM/AoJwr9uFClGOZiUJlIpLpz/aknaUQR/aoFn18= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com v5LFCHer030399 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd06.lss.emc.com (RSA Interceptor) for ; Wed, 21 Jun 2017 11:11:19 -0400 Received: from MXHUB312.corp.emc.com (MXHUB312.corp.emc.com [10.146.3.90]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5LFBo9V032145 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 21 Jun 2017 11:12:09 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB312.corp.emc.com ([10.146.3.90]) with mapi id 14.03.0352.000; Wed, 21 Jun 2017 11:12:02 -0400 To: "tsvwg@ietf.org" Thread-Topic: I-D Action: draft-ietf-tsvwg-ecn-experimentation-03.txt Thread-Index: AQHS6p7XtpkT1x7RbkebaM383Tda9qIvaH/A Date: Wed, 21 Jun 2017 15:12:02 +0000 Message-ID: References: <149805709598.15567.6760712935864557291@ietfa.amsl.com> In-Reply-To: <149805709598.15567.6760712935864557291@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public, GIS Solicitation Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 15:17:01 -0000 This-03 version addresses all the WGLC comments, with particular thanks to= Ingemar Johansson for finding the "SHOULD" for DCCP sender use of ECT(0) t= hat needed to be changed to a "MUST" in accordance with prior WG discussion= of this topic (mea culpa - missed that one in earlier editing). There are two downrefs in this draft that is intended to become a proposed = status RFC: - This draft explains the end of the ECN Nonce experiment described in RFC = 3540, and hence normatively references RFC 3540.=20 - DCCP sender ECN behavior needs to be updated in 3 RFCs, one of which is E= xperimental - RFC 5622. Thanks, --David > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, June 21, 2017 10:58 AM > To: i-d-announce@ietf.org > Cc: tsvwg@ietf.org > Subject: I-D Action: draft-ietf-tsvwg-ecn-experimentation-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Transport Area Working Group of the IETF= . >=20 > Title : Explicit Congestion Notification (ECN) Experime= ntation > Author : David Black > Filename : draft-ietf-tsvwg-ecn-experimentation-03.txt > Pages : 17 > Date : 2017-06-21 >=20 > Abstract: > This memo updates RFC 3168, which specifies Explicit Congestion > Notification (ECN) as a replacement for packet drops as indicators of > network congestion. It relaxes restrictions in RFC 3168 that would > otherwise hinder experimentation towards benefits beyond just removal > of loss. This memo summarizes the anticipated areas of > experimentation and updates RFC 3168 to enable experimentation in > these areas. An Experimental RFC is required to take advantage of > any of these enabling updates. In addition, this memo makes related > updates to the ECN specifications for RTP in RFC 6679 and for DCCP in > RFC 4341, RFC 4342 and RFC 5622. This memo also records the > conclusion of the ECN Nonce experiment in RFC 3540, and provides the > rationale for reclassification of RFC 3540 as Historic; this > reclassification enables new experimental use of the ECT(1) > codepoint. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn- > experimentation-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-ecn-experimentation-= 03 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Jun 21 09:43:09 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FC51270AC for ; Wed, 21 Jun 2017 09:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 4eiy0V7LvPjS for ; Wed, 21 Jun 2017 09:43:06 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3014F1270A7 for ; Wed, 21 Jun 2017 09:43:06 -0700 (PDT) Received: from MacBook-2.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7A8621B00254 for ; Wed, 21 Jun 2017 19:37:25 +0100 (BST) Message-ID: <594AA218.5050308@erg.abdn.ac.uk> Date: Wed, 21 Jun 2017 17:43:04 +0100 From: G Fairhurst User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg WG References: <592BD80E.7040500@erg.abdn.ac.uk> <31A20166-F418-42D1-848C-FC4A1CAB8964@netflix.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] Implementation status for draft-ietf-tsvwg-sctp-ndata? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:43:09 -0000 TSVWG, The WGLC for i-Data, draft-ietf-tsvwg-sctp-ndata, has concluded and the Chairs are now preparing a publication request for this document as PS. To complete the write-up of this spec, we would be interested to hear of any implementations of the spec. Please let the Chairs know if you plan to or have already completed implementation of this SCTP update (and provide a few lines of text that we may compile into the write-up for this document). Gorry From nobody Wed Jun 21 11:33:38 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981D7124D85 for ; Wed, 21 Jun 2017 11:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Mr_ZmxBBgSMT for ; Wed, 21 Jun 2017 11:33:34 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2429B129458 for ; Wed, 21 Jun 2017 11:33:34 -0700 (PDT) Received: from [IPv6:2003:cd:6bd8:2c00:712e:2a6c:c8f8:ae3] (p200300CD6BD82C00712E2A6CC8F80AE3.dip0.t-ipconnect.de [IPv6:2003:cd:6bd8:2c00:712e:2a6c:c8f8:ae3]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 20742721E282F; Wed, 21 Jun 2017 20:33:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Tuexen In-Reply-To: <594AA218.5050308@erg.abdn.ac.uk> Date: Wed, 21 Jun 2017 20:33:29 +0200 Cc: tsvwg WG Content-Transfer-Encoding: quoted-printable Message-Id: <55F6DA3E-0E9E-4874-B0E6-C85DCB219264@lurchi.franken.de> References: <592BD80E.7040500@erg.abdn.ac.uk> <31A20166-F418-42D1-848C-FC4A1CAB8964@netflix.com> <594AA218.5050308@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] Implementation status for draft-ietf-tsvwg-sctp-ndata? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 18:33:37 -0000 > On 21. Jun 2017, at 18:43, G Fairhurst wrote: >=20 >=20 > TSVWG, >=20 > The WGLC for i-Data, draft-ietf-tsvwg-sctp-ndata, has concluded and = the Chairs are now preparing a publication request for this document as = PS. >=20 > To complete the write-up of this spec, we would be interested to hear = of any implementations of the spec. Please let the Chairs know if you = plan to or have already completed implementation of this SCTP update = (and provide a few lines of text that we may compile into the write-up = for this document). Hi Gorry, The FreeBSD kernel implementation and the userland stack usrsctp (which = is shares most of the code) support the sending and receiving of I-DATA chunks. The implementation of = interleaving schedulers is still missing, but it is planned to implement them in the timeframe of IETF 99. Best regards Michael >=20 > Gorry >=20 From nobody Wed Jun 21 12:01:34 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFD81270FC for ; Wed, 21 Jun 2017 12:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=EfzmcFoU; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=LjYBFE2C 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 BbkaL9wjTqvE for ; Wed, 21 Jun 2017 12:01:27 -0700 (PDT) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (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 D88B412EC39 for ; Wed, 21 Jun 2017 12:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1498071185; x=1529607185; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=koYN3v/eEU362lqq2TO8Ymrc2wyAoCQYpGhqN8RJVMc=; b=EfzmcFoUkXk1rAETagastIeW5j03Ik/K82B2RhYPdhYGEpdlFb4uv7ak bEMS3qB0aFf3Mb8laWcv57HPGiHrKHO5Hgwxqon1wYvR5By6eS+bHfFgF oAMg+XbJtTcS1LcPCTjU71SaVzfst4aCopsndu3FmG9wjgUtlZkB7wBSy U=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2017 13:53:04 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2017 00:55:31 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5LJ112t005920 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jun 2017 15:01:03 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v5LJ112t005920 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1498071663; bh=8Er351afvcMRSrtVMIwPohjQQos=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=LjYBFE2Co1086Vr92zzhu7T0Hy0DrGVITmUZ/5w4jzi/25i5XKKQ8/TdofdG4vQ7E JQD3janLJhdUYGvG0D4azMA13f2UUfFhJq7zDtss6vHf7Gvi1xheZ3KLDuzd0+GRfl vN9mBL+To1M4CQdHoYQixzG/AOFFhWS32bB5BHfM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com v5LJ112t005920 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 21 Jun 2017 15:00:41 -0400 Received: from MXHUB315.corp.emc.com (MXHUB315.corp.emc.com [10.146.3.93]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v5LJ0eWe024797 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 21 Jun 2017 15:00:41 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB315.corp.emc.com ([10.146.3.93]) with mapi id 14.03.0352.000; Wed, 21 Jun 2017 15:00:39 -0400 To: Bob Briscoe CC: tsvwg IETF list Thread-Topic: New Version draft-ietf-tsvwg-rfc6040update-shim-02 Thread-Index: AQHS5q+Qzg8x4c8g0U+n6O9GbhI5paIvs7BA Date: Wed, 21 Jun 2017 19:00:39 +0000 Message-ID: References: <149762248621.523.6078795399785182097.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.149] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FB3E246MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] New Version draft-ietf-tsvwg-rfc6040update-shim-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 19:01:30 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FB3E246MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBvcHNhd2cgd291bGQgbGlrZSB0byBsYXN0IGNhbGwgZHJhZnQtaWV0Zi10c3Z3Zy1yZmM2MDQw dXBkYXRlLXNoaW0gYXMgd2VsbCAoYWx0aG8gSSBoYXZlIG5vdyByZWFsaXplZCB0aGF0IG5vIHVw ZGF0ZSB0byBDQVBXQVAgaXMgbmVlZGVkLA0KPiBidXQgb3BzYXdnIGlzIG5vdyB3b3JraW5nIG9u IGFsdGVybmF0aXZlIHR1bm5lbGxpbmcgcHJvdG9jb2xzIHRvIENBUFdBUDogZHJhZnQtaWV0Zi1v cHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwgKS4gSSBndWVzcyBpbnQtYXJlYSBtaWdodCB3YW50DQo+ IHRvIGxhc3QgY2FsbCBkcmFmdC1pZXRmLXRzdndnLXJmYzYwNDB1cGRhdGUtc2hpbSB0b28uDQoN CldlIGNhbiBjZXJ0YWlubHkgYW5ub3VuY2UgdGhlIHRzdndnIFdHTEMgdG8gdGhvc2UgdHdvIFdH cyBpbiBvcmRlciB0byBpbnZpdGUgcmV2aWV3cyBhbmQgY29tbWVudHMuDQoNClRoYW5rcywgLS1E YXZpZA0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQpT ZW50OiBGcmlkYXksIEp1bmUgMTYsIDIwMTcgMTA6NDggQU0NClRvOiBCbGFjaywgRGF2aWQgPGRh dmlkLmJsYWNrQGVtYy5jb20+DQpDYzogdHN2d2cgSUVURiBsaXN0IDx0c3Z3Z0BpZXRmLm9yZz4N ClN1YmplY3Q6IE5ldyBWZXJzaW9uIGRyYWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGlt LTAyDQoNCkRhdmlkLCBhcyBkb2Mgc2hlcGhlcmQuDQoNCkkgaGF2ZSBqdXN0IHBvc3RlZCBhIG1h am9yIHJldmlzaW9uIHRvIGRyYWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGltDQoNClBs ZWFzZSBhbHNvIHRha2UgdGhpcyBhcyBhIHJlcXVlc3QgdG8gZ2l2ZSBhIDEwbWluIHByZXNlbnRh dGlvbiBpbiB0c3Z3Zy4NCg0KQXMgcmVxdWVzdGVkLCBJIGluY2x1ZGVkIHNwZWNpZmljIHRleHQg bmVjZXNzYXJ5IHRvIHVwZGF0ZSBjZXJ0YWluIHNoaW0gdHVubmVsIHByb3RvY29scyB0aGF0IGRp ZG4ndCBtZW50aW9uIEVDTiBhdCBhbGwgKEwyVFB2MiwgTDJUUHYzLCBHUkUpLg0KVGhlcmUgYXJl IHR3byBvdGhlcnMgdG8gZG86DQoqIFRlcmVkbzogSSdsbCBkbyB0aGlzIG9uY2UgSSBoZWFyIGZy b20gdGhlIG9yaWdpbmFsIGF1dGhvciwgQ2hyaXN0aWFuIEh1aXRlbWENCiogVlhMQU4tR1BFOiBU aGlzIGlzIGEgZHJhZnQgY3VycmVudGx5IGdvaW5nIHRocm91Z2ggTlZPMyBvbiB0aGUgc3RhbmRh cmRzIHRyYWNrLiBBRkFJSyB0aGUgTGludXggaW1wbGVtZW50YXRpb24gYWxyZWFkeSBzdXBwb3J0 cyBFQ04gdmlhIFJGQzYwNDAsIGJ1dCB0aGUgYXV0aG9ycyB3aWxsIG5lZWQgdG8gYWRkIEVDTiB0 ZXh0IHRvIHRoZSBzcGVjLCBzbyB0aGVyZSBpcyBzb21ldGhpbmcgZm9yIG90aGVyIGltcGxlbWVu dGF0aW9ucyB0byBmb2xsb3cuIEkgaGF2ZSBjb250YWN0ZWQgdGhlbSAtIHRoZXkgc2hvdWxkIGRv IHRoaXMsIG5vdCBtZS4NCg0KSSBoYXZlIGFsc28gYWRkZWQgbW9yZSBwcm90b2NvbHMgdG8gdGhl IGxpc3QgKGUuZy4gQ0FQV0FQLCBMSVNQKSwgYnV0IHRoZXNlIGFscmVhZHkgc3VwcG9ydGVkIEVD Ti4NCg0KQXMgeW91IGhhdmUgc2VlbiwgSSBoYXZlIGJlZW4gaW4gY29udmVyc2F0aW9uIHdpdGgg cGVvcGxlIG9uIHRoZSBsMnRwZXh0IGxpc3QsIGFuZCBvbiBvcHNhd2cgKGZvciBDQVBXQVApLiBJ IGhhdmVuJ3QgZm91bmQgYW55b25lIHNwZWNpZmljIHRvIHRhbGsgdG8gcmVnYXJkaW5nIEdSRSB5 ZXQsIGJ1dCBJIGhhdmUgbm90aWZpZWQgaW50LWFyZWEgYW5kIEkgZ2F2ZSBhIGhlYWRzLXVwIGF0 IGEgcmVjZW50IElFVEYuDQoNCg0KQlRXLCB5b3VyIHBsYW4gd2FzIHRvIGxhc3QgY2FsbCBkcmFm dC1pZXRmLXRzdndnLXJmYzYwNDB1cGRhdGUtc2hpbSBhbG9uZyB3aXRoIGVjbi1lbmNhcC1ndWlk ZWxpbmVzLCBkZWFkbGluZSBTZXAgMjAxNy4NCkkgc2hvdWxkIHBvaW50IG91dCB0aGF0IGRyYWZ0 LWlldGYtdHJpbGwtZWNuLXN1cHBvcnQgaXMgaW4gV0dMQyBpbiB0cmlsbCwgYW5kIGl0IGRlcGVu ZHMgbm9ybWF0aXZlbHkgb24gZWNuLWVuY2FwLWd1aWRlbGluZXMNCg0Kb3BzYXdnIHdvdWxkIGxp a2UgdG8gbGFzdCBjYWxsIGRyYWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGltIGFzIHdl bGwgKGFsdGhvIEkgaGF2ZSBub3cgcmVhbGl6ZWQgdGhhdCBubyB1cGRhdGUgdG8gQ0FQV0FQIGlz IG5lZWRlZCwgYnV0IG9wc2F3ZyBpcyBub3cgd29ya2luZyBvbiBhbHRlcm5hdGl2ZSB0dW5uZWxs aW5nIHByb3RvY29scyB0byBDQVBXQVA6IGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1hbHQtdHVu bmVsICkuIEkgZ3Vlc3MgaW50LWFyZWEgbWlnaHQgd2FudCB0byBsYXN0IGNhbGwgZHJhZnQtaWV0 Zi10c3Z3Zy1yZmM2MDQwdXBkYXRlLXNoaW0gdG9vLg0KDQoNCg0KQm9iDQoNCg0KLS0tLS0tLS0g Rm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCk5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10c3Z3Zy1yZmM2MDQwdXBkYXRlLXNoaW0tMDIudHh0DQoN CkRhdGU6DQoNCkZyaSwgMTYgSnVuIDIwMTcgMDc6MTQ6NDYgLTA3MDANCg0KRnJvbToNCg0KaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQoN ClRvOg0KDQpCb2IgQnJpc2NvZSA8aWV0ZkBib2JicmlzY29lLm5ldD48bWFpbHRvOmlldGZAYm9i YnJpc2NvZS5uZXQ+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi10c3Z3 Zy1yZmM2MDQwdXBkYXRlLXNoaW0tMDIudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgQm9iIEJyaXNjb2UgYW5kIHBvc3RlZCB0byB0aGUNCg0KSUVURiByZXBvc2l0b3J5 Lg0KDQoNCg0KTmFtZTogICAgICAgICBkcmFmdC1pZXRmLXRzdndnLXJmYzYwNDB1cGRhdGUtc2hp bQ0KDQpSZXZpc2lvbjogICAgIDAyDQoNClRpdGxlOiAgICAgICAgUHJvcGFnYXRpbmcgRXhwbGlj aXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gQWNyb3NzIElQIFR1bm5lbCBIZWFkZXJzIFNlcGFy YXRlZCBieSBhIFNoaW0NCg0KRG9jdW1lbnQgZGF0ZTogMjAxNy0wNi0xNg0KDQpHcm91cDogICAg ICAgIHRzdndnDQoNClBhZ2VzOiAgICAgICAgMTUNCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXRzdndnLXJmYzYwNDB1cGRh dGUtc2hpbS0wMi50eHQNCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGltLw0KDQpIdG1saXpl ZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctcmZj NjA0MHVwZGF0ZS1zaGltLTAyDQoNCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGltLTAy DQoNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi10c3Z3Zy1yZmM2MDQwdXBkYXRlLXNoaW0tMDINCg0KDQoNCkFic3RyYWN0Og0KDQog ICBSRkMgNjA0MCBvbiAiVHVubmVsbGluZyBvZiBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNh dGlvbiIgbWFkZSB0aGUNCg0KICAgcnVsZXMgZm9yIHByb3BhZ2F0aW9uIG9mIEVDTiBjb25zaXN0 ZW50IGZvciBhbGwgZm9ybXMgb2YgSVAgaW4gSVANCg0KICAgdHVubmVsLiAgVGhpcyBzcGVjaWZp Y2F0aW9uIGV4dGVuZHMgdGhlIHNjb3BlIG9mIFJGQyA2MDQwIHRvIGluY2x1ZGUNCg0KICAgdHVu bmVscyB3aGVyZSB0d28gSVAgaGVhZGVycyBhcmUgc2VwYXJhdGVkIGJ5IGF0IGxlYXN0IG9uZSBz aGltDQoNCiAgIGhlYWRlciB0aGF0IGlzIG5vdCBzdWZmaWNpZW50IG9uIGl0cyBvd24gZm9yIHBh Y2tldCBmb3J3YXJkaW5nLiAgSXQNCg0KICAgc3VydmV5cyB3aWRlbHkgZGVwbG95ZWQgSVAgdHVu bmVsbGluZyBwcm90b2NvbHMgc2VwYXJhdGVkIGJ5IGEgc2hpbQ0KDQogICBhbmQgdXBkYXRlcyB0 aGUgc3BlY2lmaWNhdGlvbnMgb2YgdGhvc2UgdGhhdCBkbyBub3QgbWVudGlvbiBFQ04NCg0KICAg cHJvcGFnYXRpb24gKEwyVFB2MiwgTDJUUHYzLCBHUkUgYW5kIFRlcmVkbykuICBUaGUgc3BlY2lm aWNhdGlvbiBhbHNvDQoNCiAgIHVwZGF0ZXMgUkZDIDYwNDAgd2l0aCBjb25maWd1cmF0aW9uIHJl cXVpcmVtZW50cyBuZWVkZWQgdG8gbWFrZSBhbnkNCg0KICAgbGVnYWN5IHR1bm5lbCBpbmdyZXNz IHNhZmUuDQoNCg0KDQoNCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQoNCnVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_CE03DB3D7B45C245BCA0D243277949362FB3E246MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9Indo aXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0Ow0KPC9zcGFuPjwvYT5v cHNhd2cgd291bGQgbGlrZSB0byBsYXN0IGNhbGwgZHJhZnQtaWV0Zi10c3Z3Zy1yZmM2MDQwdXBk YXRlLXNoaW0gYXMgd2VsbCAoYWx0aG8gSSBoYXZlIG5vdyByZWFsaXplZCB0aGF0IG5vIHVwZGF0 ZSB0byBDQVBXQVAgaXMgbmVlZGVkLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyBidXQgb3BzYXdnIGlzIG5vdyB3b3JraW5nIG9uIGFsdGVybmF0aXZlIHR1bm5lbGxp bmcgcHJvdG9jb2xzIHRvIENBUFdBUDogZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5u ZWwgKS4gSSBndWVzcyBpbnQtYXJlYSBtaWdodCB3YW50PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7IHRvIGxhc3QgY2FsbCBkcmFmdC1pZXRmLXRzdndnLXJmYzYwNDB1 cGRhdGUtc2hpbSB0b28uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5XZSBjYW4gY2VydGFpbmx5IGFubm91bmNlIHRoZSB0c3Z3ZyBXR0xDIHRvIHRob3NlIHR3byBX R3MgaW4gb3JkZXIgdG8gaW52aXRlIHJldmlld3MgYW5kIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCAtLURhdmlkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgW21h aWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVu ZSAxNiwgMjAxNyAxMDo0OCBBTTxicj4NCjxiPlRvOjwvYj4gQmxhY2ssIERhdmlkICZsdDtkYXZp ZC5ibGFja0BlbWMuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdHN2d2cgSUVURiBsaXN0ICZsdDt0 c3Z3Z0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gTmV3IFZlcnNpb24gZHJhZnQt aWV0Zi10c3Z3Zy1yZmM2MDQwdXBkYXRlLXNoaW0tMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZCwgYXMgZG9jIHNoZXBoZXJkLjxicj4NCjxicj4N CkkgaGF2ZSBqdXN0IHBvc3RlZCBhIG1ham9yIHJldmlzaW9uIHRvIGRyYWZ0LWlldGYtdHN2d2ct cmZjNjA0MHVwZGF0ZS1zaGltPGJyPg0KPGJyPg0KUGxlYXNlIGFsc28gdGFrZSB0aGlzIGFzIGEg cmVxdWVzdCB0byBnaXZlIGEgMTBtaW4gcHJlc2VudGF0aW9uIGluIHRzdndnLjxicj4NCjxicj4N CkFzIHJlcXVlc3RlZCwgSSBpbmNsdWRlZCBzcGVjaWZpYyB0ZXh0IG5lY2Vzc2FyeSB0byB1cGRh dGUgY2VydGFpbiBzaGltIHR1bm5lbCBwcm90b2NvbHMgdGhhdCBkaWRuJ3QgbWVudGlvbiBFQ04g YXQgYWxsIChMMlRQdjIsIEwyVFB2MywgR1JFKS48YnI+DQpUaGVyZSBhcmUgdHdvIG90aGVycyB0 byBkbzogPGJyPg0KKiBUZXJlZG86IEknbGwgZG8gdGhpcyBvbmNlIEkgaGVhciBmcm9tIHRoZSBv cmlnaW5hbCBhdXRob3IsIENocmlzdGlhbiBIdWl0ZW1hPGJyPg0KKiBWWExBTi1HUEU6IFRoaXMg aXMgYSBkcmFmdCBjdXJyZW50bHkgZ29pbmcgdGhyb3VnaCBOVk8zIG9uIHRoZSBzdGFuZGFyZHMg dHJhY2suIEFGQUlLIHRoZSBMaW51eCBpbXBsZW1lbnRhdGlvbiBhbHJlYWR5IHN1cHBvcnRzIEVD TiB2aWEgUkZDNjA0MCwgYnV0IHRoZSBhdXRob3JzIHdpbGwgbmVlZCB0byBhZGQgRUNOIHRleHQg dG8gdGhlIHNwZWMsIHNvIHRoZXJlIGlzIHNvbWV0aGluZyBmb3Igb3RoZXIgaW1wbGVtZW50YXRp b25zIHRvIGZvbGxvdy4NCiBJIGhhdmUgY29udGFjdGVkIHRoZW0gLSB0aGV5IHNob3VsZCBkbyB0 aGlzLCBub3QgbWUuPGJyPg0KPGJyPg0KSSBoYXZlIGFsc28gYWRkZWQgbW9yZSBwcm90b2NvbHMg dG8gdGhlIGxpc3QgKGUuZy4gQ0FQV0FQLCBMSVNQKSwgYnV0IHRoZXNlIGFscmVhZHkgc3VwcG9y dGVkIEVDTi48YnI+DQo8YnI+DQpBcyB5b3UgaGF2ZSBzZWVuLCBJIGhhdmUgYmVlbiBpbiBjb252 ZXJzYXRpb24gd2l0aCBwZW9wbGUgb24gdGhlIGwydHBleHQgbGlzdCwgYW5kIG9uIG9wc2F3ZyAo Zm9yIENBUFdBUCkuIEkgaGF2ZW4ndCBmb3VuZCBhbnlvbmUgc3BlY2lmaWMgdG8gdGFsayB0byBy ZWdhcmRpbmcgR1JFIHlldCwgYnV0IEkgaGF2ZSBub3RpZmllZCBpbnQtYXJlYSBhbmQgSSBnYXZl IGEgaGVhZHMtdXAgYXQgYSByZWNlbnQgSUVURi48YnI+DQo8YnI+DQo8YnI+DQpCVFcsIHlvdXIg cGxhbiB3YXMgdG8gbGFzdCBjYWxsIGRyYWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGlt IGFsb25nIHdpdGggZWNuLWVuY2FwLWd1aWRlbGluZXMsIGRlYWRsaW5lIFNlcCAyMDE3Ljxicj4N Ckkgc2hvdWxkIHBvaW50IG91dCB0aGF0IGRyYWZ0LWlldGYtdHJpbGwtZWNuLXN1cHBvcnQgaXMg aW4gV0dMQyBpbiB0cmlsbCwgYW5kIGl0IGRlcGVuZHMgbm9ybWF0aXZlbHkgb24gZWNuLWVuY2Fw LWd1aWRlbGluZXM8YnI+DQo8YnI+DQpvcHNhd2cgd291bGQgbGlrZSB0byBsYXN0IGNhbGwgZHJh ZnQtaWV0Zi10c3Z3Zy1yZmM2MDQwdXBkYXRlLXNoaW0gYXMgd2VsbCAoYWx0aG8gSSBoYXZlIG5v dyByZWFsaXplZCB0aGF0IG5vIHVwZGF0ZSB0byBDQVBXQVAgaXMgbmVlZGVkLCBidXQgb3BzYXdn IGlzIG5vdyB3b3JraW5nIG9uIGFsdGVybmF0aXZlIHR1bm5lbGxpbmcgcHJvdG9jb2xzIHRvIENB UFdBUDogZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwgKS4gSSBndWVzcw0KIGlu dC1hcmVhIG1pZ2h0IHdhbnQgdG8gbGFzdCBjYWxsIGRyYWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVw ZGF0ZS1zaGltIHRvby4gPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQm9iPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gRm9yd2Fy ZGVkIE1lc3NhZ2UgLS0tLS0tLS0gPG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8 dGJvZHk+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzow aW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHls ZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+U3ViamVjdDogPG86cD48L286cD48L2I+PC9wPg0KPC90 ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXRzdndnLXJmYzYw NDB1cGRhdGUtc2hpbS0wMi50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0K PHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246 cmlnaHQiPjxiPkRhdGU6IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyaSwgMTYgSnVu IDIwMTcgMDc6MTQ6NDYgLTA3MDA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0K PHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246 cmlnaHQiPjxiPkZyb206IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwv YT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxp Z249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlRvOiA8bzpw PjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Cb2IgQnJpc2NvZSA8YSBocmVmPSJtYWlsdG86aWV0 ZkBib2JicmlzY29lLm5ldCI+Jmx0O2lldGZAYm9iYnJpc2NvZS5uZXQmZ3Q7PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cHJlPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXRzdndnLXJmYzYwNDB1cGRh dGUtc2hpbS0wMi50eHQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5oYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEJvYiBCcmlzY29lIGFuZCBwb3N0ZWQgdG8gdGhlPG86cD48L286cD48 L3ByZT4NCjxwcmU+SUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGlt PG86cD48L286cD48L3ByZT4NCjxwcmU+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDAyPG86cD48L286cD48L3ByZT4NCjxwcmU+VGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByb3BhZ2F0aW5nIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZp Y2F0aW9uIEFjcm9zcyBJUCBUdW5uZWwgSGVhZGVycyBTZXBhcmF0ZWQgYnkgYSBTaGltPG86cD48 L286cD48L3ByZT4NCjxwcmU+RG9jdW1lbnQgZGF0ZTogMjAxNy0wNi0xNjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPkdyb3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0c3Z3ZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBhZ2VzOiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxNTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlVSTDombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGltLTAyLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGltLTAy LnR4dDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGltLyI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy1yZmM2MDQwdXBk YXRlLXNoaW0vPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkh0bWxpemVkOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1yZmM2MDQwdXBkYXRlLXNoaW0tMDIiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLXJmYzYwNDB1cGRhdGUtc2hpbS0wMjwv YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5IdG1saXplZDombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1pZXRmLXRzdndnLXJmYzYwNDB1cGRhdGUtc2hpbS0wMiI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRzdndnLXJmYzYwNDB1cGRhdGUt c2hpbS0wMjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5EaWZmOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10c3Z3Zy1yZmM2MDQwdXBk YXRlLXNoaW0tMDIiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LXRzdndnLXJmYzYwNDB1cGRhdGUtc2hpbS0wMjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgUkZDIDYwNDAgb24gJnF1b3Q7VHVubmVsbGluZyBvZiBFeHBsaWNp dCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiZxdW90OyBtYWRlIHRoZTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBydWxlcyBmb3IgcHJvcGFnYXRpb24gb2YgRUNOIGNvbnNpc3Rl bnQgZm9yIGFsbCBmb3JtcyBvZiBJUCBpbiBJUDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyB0dW5uZWwuJm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBleHRlbmRzIHRoZSBzY29w ZSBvZiBSRkMgNjA0MCB0byBpbmNsdWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IHR1bm5lbHMgd2hlcmUgdHdvIElQIGhlYWRlcnMgYXJlIHNlcGFyYXRlZCBieSBhdCBsZWFz dCBvbmUgc2hpbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBoZWFkZXIgdGhh dCBpcyBub3Qgc3VmZmljaWVudCBvbiBpdHMgb3duIGZvciBwYWNrZXQgZm9yd2FyZGluZy4mbmJz cDsgSXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3VydmV5cyB3aWRlbHkg ZGVwbG95ZWQgSVAgdHVubmVsbGluZyBwcm90b2NvbHMgc2VwYXJhdGVkIGJ5IGEgc2hpbTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhbmQgdXBkYXRlcyB0aGUgc3BlY2lmaWNh dGlvbnMgb2YgdGhvc2UgdGhhdCBkbyBub3QgbWVudGlvbiBFQ048bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgcHJvcGFnYXRpb24gKEwyVFB2MiwgTDJUUHYzLCBHUkUgYW5kIFRl cmVkbykuJm5ic3A7IFRoZSBzcGVjaWZpY2F0aW9uIGFsc288bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgdXBkYXRlcyBSRkMgNjA0MCB3aXRoIGNvbmZpZ3VyYXRpb24gcmVxdWly ZW1lbnRzIG5lZWRlZCB0byBtYWtlIGFueTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBsZWdhY3kgdHVubmVsIGluZ3Jlc3Mgc2FmZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D243277949362FB3E246MX307CL04corpem_-- From nobody Wed Jun 21 15:47:50 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AA6127137; Wed, 21 Jun 2017 15:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 qs-XY9C9ZZR6; Wed, 21 Jun 2017 15:47:46 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959BD126B72; Wed, 21 Jun 2017 15:47:46 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v5LMkpGU010485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Jun 2017 15:46:52 -0700 (PDT) To: Bob Briscoe Cc: tsvwg IETF list , "nvo3@ietf.org" References: <0fe496f1-f177-e08d-44a2-3e83849c8458@bobbriscoe.net> <5d2d437f-0c93-e28f-a77c-ba0c5e4a562c@isi.edu> <1e58ef8a-b996-5b47-e3c7-91761663c9e8@isi.edu> From: Joe Touch Message-ID: Date: Wed, 21 Jun 2017 15:46:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C5E87A28D9DDAB1753E15494" Content-Language: en-US X-MailScanner-ID: v5LMkpGU010485 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] [nvo3] VXLAN-GPE Support for ECN propagation between IP headers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 22:47:48 -0000 This is a multi-part message in MIME format. --------------C5E87A28D9DDAB1753E15494 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Bob, On 6/19/2017 10:41 AM, Bob Briscoe wrote: > Joe, > > On 19/06/17 13:45, Joe Touch wrote: >> >> Hi, Bob, >> >> On 6/19/2017 4:37 AM, Bob Briscoe wrote: >>> Joe, >>> >>> [Cutting the distr to nvo3 and adding tsvwg.] >>> >>> On 16/06/17 20:38, Joe Touch wrote: >>>> >>>> Hi, Bob, >>>> >>>> This approach seems to assume an integrated implementation of >>>> multiple protocol layers. >>>> >>>> There are other cases where the "shim" is added indirectly, as a >>>> packet is "tunneled" independently over multiple protocols. >>>> >>> >>> So what aspect of the following para (in S.3.1) does not include the >>> case(s) you are thinking of: >>> In some cases a tunnel adds an outer IP header and a tightly coupled >>> shim header to an inner header that is not an IP header, but that in >>> turn encapsulates an IP header (or might encapsulate an IP header). >>> For instance an inner Ethernet (or other link layer) header might >>> encapsulate an inner IP header as its payload. We call this a >>> tightly coupled shim over an encapsulating header. >>> Can you be more specific? Or perhaps give an example? Or suggest an >>> edit to the above text? >> >> The issue is that the paragraph defines "tightly coupled" in terms of >> "tightly coupled". >> >> AFAICT, "tightly coupled" depends on whether the layers are added all >> in the same software context or some "peeking" occurs after the shim >> layer is added but before the final IP. > So I think you are not objecting to the para I quoted above, but to > something in the previous para, quoted here: > In many cases the shim header(s) and the outer IP header are always > added (or removed) as part of the same process. We call this a > tightly coupled shim header. Processing the shim and outer together > is often necessary because the shim(s) are not sufficient for packet > forwarding in their own right; not unless complemented by an outer > header. > Is the phrase "as part of the same process" the one you are objecting to? Yes. The doc is written a bit backwards; it presumes an optimization rather than presuming the safe default. Also, the doc is written based on an implementation hint ('process') rather than a protocol requirement. IMO, the recommendations should be: ECN bits MUST be set to a known safe default when an IP layer is added, EXCEPT if a tunnel is specified as the integrated insertion of multiple layers, then jumping layers to coordinate ECN MAY be valid > If so, I have no objection to using an alternative to the word > 'process' to avoid the implication that this means specifically one > 'process' as defined for the OS in question. It wasn't intended to use > the word 'process' so strictly. The more general meaning of > 'procedure' or 'routine' was intended. > > The main point was that the definition of a shim is something that > cannot be used alone to forward a packet to another network address, > unless it is complemented by an outer PSN header. Even when a shim is enough to accomplish such fowarding, if the shim lacks ECN support then ECN information should not be crossing the shim layer (unless the shim isn't really defined as a separate layer, e.g., the example I gave above would state that the tunnel encapsulation isn't shim THEN IP, but shim AND IP as an integrated step). > The difficulty being addressed in this section is that blindly copying > an inner ECN field to an outer is unsafe (whether or not you want to > support ECN). Then IMHO that should be your title and focus. The doc reads a bit backwards, more focusing on the optimization of how and when you can do a smart copy across a shim than the basic idea that "this isn't how ECN works". It's not that you don't say this, it's that a reader would get the reverse impression (i.e., that they should find a way to integrate shim processing to enable this leap, rather than the fact that this is a true exception and not the focus). Joe --------------C5E87A28D9DDAB1753E15494 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi, Bob,


On 6/19/2017 10:41 AM, Bob Briscoe wrote:
Joe,

On 19/06/17 13:45, Joe Touch wrote:

Hi, Bob,

On 6/19/2017 4:37 AM, Bob Briscoe wrote:
Joe,

[Cutting the distr to nvo3 and adding tsvwg.]

On 16/06/17 20:38, Joe Touch wrote:

Hi, Bob,

This approach seems to assume an integrated implementation of multiple protocol layers.

There are other cases where the "shim" is added indirectly, as a packet is "tunneled" independently over multiple protocols.


So what aspect of the following para (in S.3.1) does not include the case(s) you are thinking of:
   In some cases a tunnel adds an outer IP header and a tightly coupled
   shim header to an inner header that is not an IP header, but that in
   turn encapsulates an IP header (or might encapsulate an IP header).
   For instance an inner Ethernet (or other link layer) header might
   encapsulate an inner IP header as its payload.  We call this a
   tightly coupled shim over an encapsulating header.
Can you be more specific? Or perhaps give an example? Or suggest an edit to the above text?

The issue is that the paragraph defines "tightly coupled" in terms of "tightly coupled".

AFAICT, "tightly coupled" depends on whether the layers are added all in the same software context or some "peeking" occurs after the shim layer is added but before the final IP.
So I think you are not objecting to the para I quoted above, but to something in the previous para, quoted here:
   In many cases the shim header(s) and the outer IP header are always
   added (or removed) as part of the same process.  We call this a
   tightly coupled shim header.  Processing the shim and outer together
   is often necessary because the shim(s) are not sufficient for packet
   forwarding in their own right; not unless complemented by an outer
   header.
Is the phrase "as part of the same process" the one you are objecting to?
Yes.

The doc is written a bit backwards; it presumes an optimization rather than presuming the safe default.

Also, the doc is written based on an implementation hint ('process') rather than a protocol requirement.

IMO, the recommendations should be:

ECN bits MUST be set to a known safe default when an IP layer is added,
EXCEPT if a tunnel is specified as the integrated insertion of multiple layers, then jumping layers to coordinate ECN MAY be valid

If so, I have no objection to using an alternative to the word 'process' to avoid the implication that this means specifically one 'process' as defined for the OS in question. It wasn't intended to use the word 'process' so strictly. The more general meaning of 'procedure' or 'routine' was intended.

The main point was that the definition of a shim is something that cannot be used alone to forward a packet to another network address, unless it is complemented by an outer PSN header.

Even when a shim is enough to accomplish such fowarding, if the shim lacks ECN support then ECN information should not be crossing the shim layer (unless the shim isn't really defined as a separate layer, e.g., the example I gave above would state that the tunnel encapsulation isn't shim THEN IP, but shim AND IP as an integrated step).

The difficulty being addressed in this section is that blindly copying an inner ECN field to an outer is unsafe (whether or not you want to support ECN).
Then IMHO that should be your title and focus.

The doc reads a bit backwards, more focusing on the optimization of how and when you can do a smart copy across a shim than the basic idea that "this isn't how ECN works".

It's not that you don't say this, it's that a reader would get the reverse impression (i.e., that they should find a way to integrate shim processing to enable this leap, rather than the fact that this is a true exception and not the focus).

Joe


--------------C5E87A28D9DDAB1753E15494-- From nobody Wed Jun 21 18:13:54 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E22128DF2; Wed, 21 Jun 2017 18:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 oPm0pUEsuTmQ; Wed, 21 Jun 2017 18:13:42 -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 DF56D120721; Wed, 21 Jun 2017 18:13:41 -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:From:References:Cc:To:Subject: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=8QlCDiHDUVx0f+VYG+uB4yfraB6HI10i5s4leW/XGI4=; b=lghloTtGTuiGV0TvreJfCUuDn rt9S9VGGqZxAokYep6e8HqH9SD/5PD4+FfEpOPp9nKJxug7XqDY/UOH793IiXfmb/LNO5LzDeY7si fYjTjYIMClz+d+2Jxpo54Xv9euol3pzlUu5JC1U3CfMEhJ75+J2CgbbKz3VbgMotuCv8y9QOFLWAY XDRH4r+oUMpv6GWjoVAES6SUCy3Pz9gZ3akQ76EdOzhmrbFsqHKnY+6XL/LLYL7j/oXSJoDPGA3sM E8+NVnpd5O/rH1FwhoprLqN5RJF7QzL6mJ/f6BWoGK1N6YF+R2qPjO96mx/IDoZpuejX9XbeJ+Ndn qSiYcS4Cg==; Received: from 167.6.208.46.dyn.plus.net ([46.208.6.167]:54792 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dNqgl-0001Yw-Ce; Thu, 22 Jun 2017 02:13:39 +0100 To: Joe Touch Cc: "nvo3@ietf.org" , tsvwg IETF list References: <0fe496f1-f177-e08d-44a2-3e83849c8458@bobbriscoe.net> <5d2d437f-0c93-e28f-a77c-ba0c5e4a562c@isi.edu> <1e58ef8a-b996-5b47-e3c7-91761663c9e8@isi.edu> From: Bob Briscoe Message-ID: <2c99c3a3-5368-5918-9036-e40838d5c936@bobbriscoe.net> Date: Thu, 22 Jun 2017 02:13:38 +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: Content-Type: multipart/alternative; boundary="------------818BB702C835B22A0D0941B2" 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: Subject: Re: [tsvwg] [nvo3] VXLAN-GPE Support for ECN propagation between IP headers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 01:13:46 -0000 This is a multi-part message in MIME format. --------------818BB702C835B22A0D0941B2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Joe, On 21/06/17 23:46, Joe Touch wrote: > > Hi, Bob, > > > On 6/19/2017 10:41 AM, Bob Briscoe wrote: >> Joe, >> >> On 19/06/17 13:45, Joe Touch wrote: >>> >>> Hi, Bob, >>> >>> On 6/19/2017 4:37 AM, Bob Briscoe wrote: >>>> Joe, >>>> >>>> [Cutting the distr to nvo3 and adding tsvwg.] >>>> >>>> On 16/06/17 20:38, Joe Touch wrote: >>>>> >>>>> Hi, Bob, >>>>> >>>>> This approach seems to assume an integrated implementation of >>>>> multiple protocol layers. >>>>> >>>>> There are other cases where the "shim" is added indirectly, as a >>>>> packet is "tunneled" independently over multiple protocols. >>>>> >>>> >>>> So what aspect of the following para (in S.3.1) does not include >>>> the case(s) you are thinking of: >>>> In some cases a tunnel adds an outer IP header and a tightly coupled >>>> shim header to an inner header that is not an IP header, but that in >>>> turn encapsulates an IP header (or might encapsulate an IP header). >>>> For instance an inner Ethernet (or other link layer) header might >>>> encapsulate an inner IP header as its payload. We call this a >>>> tightly coupled shim over an encapsulating header. >>>> Can you be more specific? Or perhaps give an example? Or suggest an >>>> edit to the above text? >>> >>> The issue is that the paragraph defines "tightly coupled" in terms >>> of "tightly coupled". >>> >>> AFAICT, "tightly coupled" depends on whether the layers are added >>> all in the same software context or some "peeking" occurs after the >>> shim layer is added but before the final IP. >> So I think you are not objecting to the para I quoted above, but to >> something in the previous para, quoted here: >> In many cases the shim header(s) and the outer IP header are always >> added (or removed) as part of the same process. We call this a >> tightly coupled shim header. Processing the shim and outer together >> is often necessary because the shim(s) are not sufficient for packet >> forwarding in their own right; not unless complemented by an outer >> header. >> Is the phrase "as part of the same process" the one you are objecting to? > Yes. > > The doc is written a bit backwards; it presumes an optimization rather > than presuming the safe default. [BB] Your concern holds if one believes that every RFC is implicitly preceded be the statement "The IETF recommends that you comply with this RFC". In contrast, I believe there is nothing implicit around an RFC. I see an RFC solely as a specification of what an implementer can voluntarily choose to comply with in order to interoperate with others all collectively and voluntarily choosing to add a particular feature to the Internet. I think some of our previous disagreement have hinged on this difference of opinion on the status of RFCs. If you know of any IETF document that resolves this, pls point to it. Otherwise, discussion of every I-D is going to tend to divert into an argument over this point. > > Also, the doc is written based on an implementation hint ('process') > rather than a protocol requirement. [BB] I explained (still in the thread below) that the normative protocol requirements text a little later in the draft is (deliberately) not dependent on this scene-setting paragraph. A common way to write an RFC is to say "We have this sort of stuff in the world. Now here's some normative text that is written more generically so that it applies to that sort of stuff we have just described, as well as more general cases." > > IMO, the recommendations should be: > > ECN bits MUST be set to a known safe default when an IP layer is added, > EXCEPT if a tunnel is specified as the integrated insertion of > multiple layers, then jumping layers to coordinate ECN MAY be valid [BB] See above. This would be a good way to write this RFC, if it was implicitly surrounded by "The IETF recommends you comply with this RFC". But If implementers reading this RFC are a self-selecting set who are trying to implement ECN tunnelling, then the way it is written is a good way. Neither is incorrect. But given RFC6040 is already immutably published. and it is written in the latter style, the only style that can be used for an update is the same style. > >> If so, I have no objection to using an alternative to the word >> 'process' to avoid the implication that this means specifically one >> 'process' as defined for the OS in question. It wasn't intended to >> use the word 'process' so strictly. The more general meaning of >> 'procedure' or 'routine' was intended. >> >> The main point was that the definition of a shim is something that >> cannot be used alone to forward a packet to another network address, >> unless it is complemented by an outer PSN header. > > Even when a shim is enough to accomplish such fowarding, if the shim > lacks ECN support then ECN information should not be crossing the shim > layer (unless the shim isn't really defined as a separate layer, e.g., > the example I gave above would state that the tunnel encapsulation > isn't shim THEN IP, but shim AND IP as an integrated step). [BB] I don't disagree. I believe we are still only disagreeing about the implicit status of RFCs ("Commandments" vs. "Points to Voluntarily congregate around"). > >> The difficulty being addressed in this section is that blindly >> copying an inner ECN field to an outer is unsafe (whether or not you >> want to support ECN). > Then IMHO that should be your title and focus. [BB] It is the title, but only of the section. The document as a whole is about what it says in the title of the document: "Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim" > > The doc reads a bit backwards, more focusing on the optimization of > how and when you can do a smart copy across a shim than the basic idea > that "this isn't how ECN works". > > It's not that you don't say this, it's that a reader would get the > reverse impression (i.e., that they should find a way to integrate > shim processing to enable this leap, rather than the fact that this is > a true exception and not the focus). That is indeed the impression I would expect a reader to get, given I see readers as a self-selected set who are already motivated to find a way to enable this leap. BTW, I have not come across an implementation yet that intrinsically cannot do this smart copy to enable ECN (or Diffserv) to leap across a shim. However, I would be surprised if there was not one. Bob > > Joe > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------818BB702C835B22A0D0941B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Joe,

On 21/06/17 23:46, Joe Touch wrote:

Hi, Bob,


On 6/19/2017 10:41 AM, Bob Briscoe wrote:
Joe,

On 19/06/17 13:45, Joe Touch wrote:

Hi, Bob,

On 6/19/2017 4:37 AM, Bob Briscoe wrote:
Joe,

[Cutting the distr to nvo3 and adding tsvwg.]

On 16/06/17 20:38, Joe Touch wrote:

Hi, Bob,

This approach seems to assume an integrated implementation of multiple protocol layers.

There are other cases where the "shim" is added indirectly, as a packet is "tunneled" independently over multiple protocols.


So what aspect of the following para (in S.3.1) does not include the case(s) you are thinking of:
   In some cases a tunnel adds an outer IP header and a tightly coupled
   shim header to an inner header that is not an IP header, but that in
   turn encapsulates an IP header (or might encapsulate an IP header).
   For instance an inner Ethernet (or other link layer) header might
   encapsulate an inner IP header as its payload.  We call this a
   tightly coupled shim over an encapsulating header.
Can you be more specific? Or perhaps give an example? Or suggest an edit to the above text?

The issue is that the paragraph defines "tightly coupled" in terms of "tightly coupled".

AFAICT, "tightly coupled" depends on whether the layers are added all in the same software context or some "peeking" occurs after the shim layer is added but before the final IP.
So I think you are not objecting to the para I quoted above, but to something in the previous para, quoted here:
   In many cases the shim header(s) and the outer IP header are always
   added (or removed) as part of the same process.  We call this a
   tightly coupled shim header.  Processing the shim and outer together
   is often necessary because the shim(s) are not sufficient for packet
   forwarding in their own right; not unless complemented by an outer
   header.
Is the phrase "as part of the same process" the one you are objecting to?
Yes.

The doc is written a bit backwards; it presumes an optimization rather than presuming the safe default.
[BB] Your concern holds if one believes that every RFC is implicitly preceded be the statement "The IETF recommends that you comply with this RFC". In contrast, I believe there is nothing implicit around an RFC. I see an RFC solely as a specification of what an implementer can voluntarily choose to comply with in order to interoperate with others all collectively and voluntarily choosing to add a particular feature to the Internet.

I think some of our previous disagreement have hinged on this difference of opinion on the status of RFCs. If you know of any IETF document that resolves this, pls point to it. Otherwise, discussion of every I-D is going to tend to divert into an argument over this point.


Also, the doc is written based on an implementation hint ('process') rather than a protocol requirement.
[BB] I explained (still in the thread below) that the normative protocol requirements text a little later in the draft is (deliberately) not dependent on this scene-setting paragraph. A common way to write an RFC is to say "We have this sort of stuff in the world. Now here's some normative text that is written more generically so that it applies to that sort of stuff we have just described, as well as more general cases."


IMO, the recommendations should be:

ECN bits MUST be set to a known safe default when an IP layer is added,
EXCEPT if a tunnel is specified as the integrated insertion of multiple layers, then jumping layers to coordinate ECN MAY be valid
[BB] See above. This would be a good way to write this RFC, if it was implicitly surrounded by "The IETF recommends you comply with this RFC". But If implementers reading this RFC are a self-selecting set who are trying to implement ECN tunnelling, then the way it is written is a good way.

Neither is incorrect. But given RFC6040 is already immutably published. and it is written in the latter style, the only style that can be used for an update is the same style.


If so, I have no objection to using an alternative to the word 'process' to avoid the implication that this means specifically one 'process' as defined for the OS in question. It wasn't intended to use the word 'process' so strictly. The more general meaning of 'procedure' or 'routine' was intended.

The main point was that the definition of a shim is something that cannot be used alone to forward a packet to another network address, unless it is complemented by an outer PSN header.

Even when a shim is enough to accomplish such fowarding, if the shim lacks ECN support then ECN information should not be crossing the shim layer (unless the shim isn't really defined as a separate layer, e.g., the example I gave above would state that the tunnel encapsulation isn't shim THEN IP, but shim AND IP as an integrated step).
[BB] I don't disagree. I believe we are still only disagreeing about the implicit status of RFCs ("Commandments" vs. "Points to Voluntarily congregate around").

The difficulty being addressed in this section is that blindly copying an inner ECN field to an outer is unsafe (whether or not you want to support ECN).
Then IMHO that should be your title and focus.
[BB] It is the title, but only of the section. The document as a whole is about what it says in the title of the document: "Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim"

The doc reads a bit backwards, more focusing on the optimization of how and when you can do a smart copy across a shim than the basic idea that "this isn't how ECN works".

It's not that you don't say this, it's that a reader would get the reverse impression (i.e., that they should find a way to integrate shim processing to enable this leap, rather than the fact that this is a true exception and not the focus).
That is indeed the impression I would expect a reader to get, given I see readers as a self-selected set who are already motivated to find a way to enable this leap.

BTW, I have not come across an implementation yet that intrinsically cannot do this smart copy to enable ECN (or Diffserv) to leap across a shim. However, I would be surprised if there was not one.


Bob

Joe




_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------818BB702C835B22A0D0941B2-- From nobody Thu Jun 22 01:05:07 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FE2128799 for ; Thu, 22 Jun 2017 01:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 Nk7Pou2H678Z for ; Thu, 22 Jun 2017 01:05:03 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 21DD5127B5A for ; Thu, 22 Jun 2017 01:05:03 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 27A171B00252 for ; Thu, 22 Jun 2017 10:59:00 +0100 (BST) Message-ID: <594B7A18.5020809@erg.abdn.ac.uk> Date: Thu, 22 Jun 2017 09:04:40 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] WGLC completed and revised ID submitted for publication: draft-ietf-tsvwg-sctp-ndata-11 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 08:05:06 -0000 The following publication request has been submited to Spencer on 22nd June 2017, requesting publication of draft-ietf-tsvwg-sctp-ndata-11. Best wishes, Gorry (tsvwg co-chair) ---- As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Standards Track, PS. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head of line blocking at the sender. Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined. A stream scheduler can choose to either implement, or not implement, user message interleaving. In line with other SCTP specifications, this document includes an informational appendix describing and API to the mechanisms. Working Group Summary: The document has received feedback from the WG. The FreeBSD kernel implementation and the userland stack usrsctp (which shares most of the code) both support sending and receiving of I-DATA chunks. An implementation of interleaving schedulers is planned in the timeframe of IETF 99. Document Quality: This document is one of several relating to WebRTC Datachannels, and has received inputs from other related WGs. Personnel: Who is the Document Shepherd? Gorry Fairhurst Who is the Responsible Area Director? Spencer Dawkins (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. This document is ready. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. This draft has been reviewed many times. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The authors confirm they know of no IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures known. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has been presented to the WG and there was consensus on the document during WGLC. Minor issues were raised, and changes have been incorporated in this revision of the ID. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not required. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. None. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This memo includes a request to IANA, see the IANA considerations. The request seems to be consistent with other SCTP assignments. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This memo does not include a request for a new registry to IANA. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None. From nobody Thu Jun 22 01:11:02 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F095127B5A for ; Thu, 22 Jun 2017 01:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 ESl8jip07ygO for ; Thu, 22 Jun 2017 01:11:00 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id CCCC11279EB for ; Thu, 22 Jun 2017 01:10:59 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 256DD1B00252 for ; Thu, 22 Jun 2017 11:04:57 +0100 (BST) Message-ID: <594B7B7D.1080506@erg.abdn.ac.uk> Date: Thu, 22 Jun 2017 09:10:37 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org References: <149811881496.30666.15844740546920191175.idtracker@ietfa.amsl.com> In-Reply-To: <149811881496.30666.15844740546920191175.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <149811881496.30666.15844740546920191175.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] IETF WG state changed for draft-ietf-tsvwg-ecn-experimentation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 08:11:01 -0000 Thanks to all who offered comments and reviewed this document. The WGLC has concluded for this ID, with comments. A revised ID has been published that reflects current WG Consensus. The IETF TSVWG WG state of draft-ietf-tsvwg-ecn-experimentation has therefore been changed to "WG Consensus: Waiting for Write-Up" from "In WG Last Call" by Gorry Fairhurst: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ I as document shepherd will now prepare a write-up. Best wishes, Gorry Fairhurst (TSVWG Co-Chair) From nobody Thu Jun 22 08:02:38 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C76127419; Thu, 22 Jun 2017 08:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 hNzU1ykfRKqO; Thu, 22 Jun 2017 08:02:21 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 DC105120726; Thu, 22 Jun 2017 08:02:20 -0700 (PDT) X-AuditID: c1b4fb2d-edfff7000000080d-ec-594bdbfa60dc Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.F2.02061.AFBDB495; Thu, 22 Jun 2017 17:02:19 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.25]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0339.000; Thu, 22 Jun 2017 17:02:17 +0200 From: Szilveszter Nadas To: "iccrg@irtf.org" CC: "tsvwg@ietf.org" , "'aqm@ietf.org'" , =?iso-8859-1?Q?S=E1ndor_Laki_=28lakis=40elte=2Ehu=29?= , =?iso-8859-1?Q?Zolt=E1n_Tur=E1nyi?= , "Gombos Gergo (ggombos@inf.elte.hu)" Thread-Topic: Potential ICCRG presentation about the Per Packet Value concept @ Prague? Thread-Index: AdLrZf3203Zshlh/Scm66nsplcQPYQ== Date: Thu, 22 Jun 2017 15:02:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE4254E5E0ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2J7iO7v296RBusXclus2SdpcXfSW0aL Awt2slu0Xv/GbnHszV02B1aPW21/mD2WLPnJ5LGtZzu7x+SNh9kCWKK4bFJSczLLUov07RK4 Mg6tfspcsMKq4suTuAbGKUZdjJwcEgImErunz2XvYuTiEBI4wigxsfcwlLOYUeLw5OMsIFVs AhYSDSs3s3UxcnCICKhK3DoqDlLDLDCZSWLeqy2MIHFhgRCJ6b+lIUoiJSaulAHpFBHQk5h3 9S8biM0C1Llr8Tt2EJtXwFdi0tnFrCA2o4CYxPdTa5hAbGYBcYlbT+YzQdwmILFkz3lmCFtU 4uXjf6wg4yUElCSmbU2DKM+XeHTtOBvESEGJkzOfsExgFJqFZNIsJGWzkJRBxPUkbkydwgZh a0ssW/iaGcLWlZjx7xALsvgCRvZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIERdXDLb90d jKtfOx5iFOBgVOLh3XHGO1KINbGsuDL3EKMEB7OSCESINyWxsiq1KD++qDQntfgQozQHi5I4 r8O+CxFCAumJJanZqakFqUUwWSYOTqkGRo4v01dVHA86KHT0XsvB+FWM0axVS2yjGVfVx517 tECW5fbBlqQepe3GMzLex5eeDA6Xtlnf8nnp5OaN37aq1p33vX2BoWFvNeuqz4GPuRc9Mv19 tU5/+bp1u86lbeiZ84F7tvWfS52yt613nGTRlu28dlSxv+J6+c5FFlsElL+s6A6xa1r3rliJ pTgj0VCLuag4EQCvkjwupAIAAA== Archived-At: Subject: [tsvwg] Potential ICCRG presentation about the Per Packet Value concept @ Prague? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 15:02:27 -0000 --_000_EA4C43BE752A194597B002779DF69BAE4254E5E0ESESSMB109erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi ICCRG, cc AQM and TSVWG, We have a research concept paper "Take your own share of the PIE" accepted = to the ANRW WS (Saturday before the Prague ietf https://irtf.org/anrw/2017/= ). Two of the reviewers mentioned that it might be interesting for the ietf, e= specially ICCRG, maybe AQM or TSVWG. I would be happy to present a summary = of this paper (and the previous one it is based upon) at the Monday iccrg s= lot, if indeed it is interesting for the group. It would take ~20-30 minute= s. I have to finalize my travel plans next week, so if I get a confirmatio= n that you are interested and that I have a slot reserved then I can extend= my travel accordingly. (I will not participate at the IETF otherwise). Link to the two papers: http://lakis.web.elte.hu/publ/PPOV-AQM-inpress-ANRW2017.pdf (the ANRW paper= ) https://www.researchgate.net/publication/312595858_Per_Packet_Value_A_Pract= ical_Concept_for_Network_Resource_Sharing (Base concept paper @Globecom 201= 6) Why it might be interesting (part of the Abstracts): We introduce a framework that consists of flow-aware Packet Value marking a= t the edges and flow-unaware operation inside the network. We show that ins= ide the network relatively simple scheduling and AQM algorithms operating solely on Packet Value are suitable to implement t= he policies set at the network edge. We propose the PVPIE Active Queue Management (AQM) method that combines the= packet scheduling and dropping algorithms of PIE AQM and the packet markin= g-based resource sharing of the Per Packet Value (PPV) concept. PVPIE AQM c= ombines the benefits of PIE and PPV concepts, keeping a target queueing del= ay and implementing policy-based resource sharing at the same time. I am also happy to discuss the papers and receive comments on the mailing l= ist. Cheers, Szilveszter --_000_EA4C43BE752A194597B002779DF69BAE4254E5E0ESESSMB109erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi ICCRG, cc AQM and TSVWG,

 

We have a research concept paper “Take your= own share of the PIE” accepted to the ANRW WS (Saturday before the P= rague ietf https://irtf.org/anrw/2017/).

 

Two of the reviewers mentioned that it might be i= nteresting for the ietf, especially ICCRG, maybe AQM or TSVWG. I would be h= appy to present a summary of this paper (and the previous one it is based u= pon) at the Monday iccrg slot, if indeed it is interesting for the group. It would take ~20-30 minutes. &nbs= p;I have to finalize my travel plans next week, so if I get a confirmation = that you are interested and that I have a slot reserved then I can extend m= y travel accordingly. (I will not participate at the IETF otherwise).

 

Link to the two papers:

http://lakis.web.elte.hu/publ/PPOV-AQM-inpress-ANRW2= 017.pdf (the ANRW paper)

https://www.researchgate.net/publication/312595858_Per_Packet_Value_A_= Practical_Concept_for_Network_Resource_Sharing (Base concept paper @Globecom 2016)

 

Why it might be interesting (part of the Abstract= s):

We introduce a framework that consists of flow-aw= are Packet Value marking at the edges and flow-unaware operation inside the= network. We show that inside the network relatively simple scheduling and<= o:p>

AQM algorithms operating solely on Packet Value a= re suitable to implement the policies set at the network edge.

We propose the PVPIE Active Queue Management (AQM= ) method that combines the packet scheduling and dropping algorithms of PIE= AQM and the packet marking-based resource sharing of the Per Packet Value = (PPV) concept. PVPIE AQM combines the benefits of PIE and PPV concepts, keeping a target queueing delay and = implementing policy-based resource sharing at the same time.

 

I am also happy to discuss the papers and receive= comments on the mailing list.

 

Cheers,

Szilveszter

 

 

 

 

--_000_EA4C43BE752A194597B002779DF69BAE4254E5E0ESESSMB109erics_-- From nobody Thu Jun 22 09:37:15 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A8C1272E1; Thu, 22 Jun 2017 09:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 x9ZiKVlUTu1L; Thu, 22 Jun 2017 09:37:04 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476CF126BF0; Thu, 22 Jun 2017 09:37:04 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v5MGZfEC025482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 Jun 2017 09:35:58 -0700 (PDT) To: Bob Briscoe Cc: "nvo3@ietf.org" , tsvwg IETF list References: <0fe496f1-f177-e08d-44a2-3e83849c8458@bobbriscoe.net> <5d2d437f-0c93-e28f-a77c-ba0c5e4a562c@isi.edu> <1e58ef8a-b996-5b47-e3c7-91761663c9e8@isi.edu> <2c99c3a3-5368-5918-9036-e40838d5c936@bobbriscoe.net> From: Joe Touch Message-ID: Date: Thu, 22 Jun 2017 09:35:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <2c99c3a3-5368-5918-9036-e40838d5c936@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------51D21910B8C76F45B818DC82" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] [nvo3] VXLAN-GPE Support for ECN propagation between IP headers X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 16:37:07 -0000 This is a multi-part message in MIME format. --------------51D21910B8C76F45B818DC82 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Bob, I think we're on the same page here. I'll suggest that it would be useful to clarify "tightly coupled" as referring to "is required by a specification (not just as an implementation issue)" and replace "part of the same process" with "as defined in an integrated manner in a specification requirement". FWIW, I do think nearly every RFC comes with "the IETF recommends you do this", which is at least partly why the IESG puts a strong wording to the contrary for individual submissions where they don't agree with that sentiment, so it would be useful to recheck the wording throughout in that light. However, I don't have any specific suggestions. I.e., although we agree, I'm not sure someone reading the document in its current form would get the same impression. Joe On 6/21/2017 6:13 PM, Bob Briscoe wrote: > Joe, > > On 21/06/17 23:46, Joe Touch wrote: >> >> Hi, Bob, >> >> >> On 6/19/2017 10:41 AM, Bob Briscoe wrote: >>> Joe, >>> >>> On 19/06/17 13:45, Joe Touch wrote: >>>> >>>> Hi, Bob, >>>> >>>> On 6/19/2017 4:37 AM, Bob Briscoe wrote: >>>>> Joe, >>>>> >>>>> [Cutting the distr to nvo3 and adding tsvwg.] >>>>> >>>>> On 16/06/17 20:38, Joe Touch wrote: >>>>>> >>>>>> Hi, Bob, >>>>>> >>>>>> This approach seems to assume an integrated implementation of >>>>>> multiple protocol layers. >>>>>> >>>>>> There are other cases where the "shim" is added indirectly, as a >>>>>> packet is "tunneled" independently over multiple protocols. >>>>>> >>>>> >>>>> So what aspect of the following para (in S.3.1) does not include >>>>> the case(s) you are thinking of: >>>>> In some cases a tunnel adds an outer IP header and a tightly coupled >>>>> shim header to an inner header that is not an IP header, but that in >>>>> turn encapsulates an IP header (or might encapsulate an IP header). >>>>> For instance an inner Ethernet (or other link layer) header might >>>>> encapsulate an inner IP header as its payload. We call this a >>>>> tightly coupled shim over an encapsulating header. >>>>> Can you be more specific? Or perhaps give an example? Or suggest >>>>> an edit to the above text? >>>> >>>> The issue is that the paragraph defines "tightly coupled" in terms >>>> of "tightly coupled". >>>> >>>> AFAICT, "tightly coupled" depends on whether the layers are added >>>> all in the same software context or some "peeking" occurs after the >>>> shim layer is added but before the final IP. >>> So I think you are not objecting to the para I quoted above, but to >>> something in the previous para, quoted here: >>> In many cases the shim header(s) and the outer IP header are always >>> added (or removed) as part of the same process. We call this a >>> tightly coupled shim header. Processing the shim and outer together >>> is often necessary because the shim(s) are not sufficient for packet >>> forwarding in their own right; not unless complemented by an outer >>> header. >>> Is the phrase "as part of the same process" the one you are >>> objecting to? >> Yes. >> >> The doc is written a bit backwards; it presumes an optimization >> rather than presuming the safe default. > [BB] Your concern holds if one believes that every RFC is implicitly > preceded be the statement "The IETF recommends that you comply with > this RFC". In contrast, I believe there is nothing implicit around an > RFC. I see an RFC solely as a specification of what an implementer can > voluntarily choose to comply with in order to interoperate with others > all collectively and voluntarily choosing to add a particular feature > to the Internet. > > I think some of our previous disagreement have hinged on this > difference of opinion on the status of RFCs. If you know of any IETF > document that resolves this, pls point to it. Otherwise, discussion of > every I-D is going to tend to divert into an argument over this point. > >> >> Also, the doc is written based on an implementation hint ('process') >> rather than a protocol requirement. > [BB] I explained (still in the thread below) that the normative > protocol requirements text a little later in the draft is > (deliberately) not dependent on this scene-setting paragraph. A common > way to write an RFC is to say "We have this sort of stuff in the > world. Now here's some normative text that is written more generically > so that it applies to that sort of stuff we have just described, as > well as more general cases." > >> >> IMO, the recommendations should be: >> >> ECN bits MUST be set to a known safe default when an IP layer is added, >> EXCEPT if a tunnel is specified as the integrated insertion of >> multiple layers, then jumping layers to coordinate ECN MAY be valid > [BB] See above. This would be a good way to write this RFC, if it was > implicitly surrounded by "The IETF recommends you comply with this > RFC". But If implementers reading this RFC are a self-selecting set > who are trying to implement ECN tunnelling, then the way it is written > is a good way. > > Neither is incorrect. But given RFC6040 is already immutably > published. and it is written in the latter style, the only style that > can be used for an update is the same style. > >> >>> If so, I have no objection to using an alternative to the word >>> 'process' to avoid the implication that this means specifically one >>> 'process' as defined for the OS in question. It wasn't intended to >>> use the word 'process' so strictly. The more general meaning of >>> 'procedure' or 'routine' was intended. >>> >>> The main point was that the definition of a shim is something that >>> cannot be used alone to forward a packet to another network address, >>> unless it is complemented by an outer PSN header. >> >> Even when a shim is enough to accomplish such fowarding, if the shim >> lacks ECN support then ECN information should not be crossing the >> shim layer (unless the shim isn't really defined as a separate layer, >> e.g., the example I gave above would state that the tunnel >> encapsulation isn't shim THEN IP, but shim AND IP as an integrated step). > [BB] I don't disagree. I believe we are still only disagreeing about > the implicit status of RFCs ("Commandments" vs. "Points to Voluntarily > congregate around"). >> >>> The difficulty being addressed in this section is that blindly >>> copying an inner ECN field to an outer is unsafe (whether or not you >>> want to support ECN). >> Then IMHO that should be your title and focus. > [BB] It is the title, but only of the section. The document as a whole > is about what it says in the title of the document: "Propagating > Explicit Congestion Notification Across IP Tunnel Headers Separated by > a Shim" >> >> The doc reads a bit backwards, more focusing on the optimization of >> how and when you can do a smart copy across a shim than the basic >> idea that "this isn't how ECN works". >> >> It's not that you don't say this, it's that a reader would get the >> reverse impression (i.e., that they should find a way to integrate >> shim processing to enable this leap, rather than the fact that this >> is a true exception and not the focus). > That is indeed the impression I would expect a reader to get, given I > see readers as a self-selected set who are already motivated to find a > way to enable this leap. > > BTW, I have not come across an implementation yet that intrinsically > cannot do this smart copy to enable ECN (or Diffserv) to leap across a > shim. However, I would be surprised if there was not one. > > > Bob >> >> Joe >> >> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ --------------51D21910B8C76F45B818DC82 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi, Bob,

I think we're on the same page here. I'll suggest that it would be useful to clarify "tightly coupled" as referring to "is required by a specification (not just as an implementation issue)" and replace "part of the same process" with "as defined in an integrated manner in a specification requirement".

FWIW, I do think nearly every RFC comes with "the IETF recommends you do this", which is at least partly why the IESG puts a strong wording to the contrary for individual submissions where they don't agree with that sentiment, so it would be useful to recheck the wording throughout in that light. However, I don't have any specific suggestions.

I.e., although we agree, I'm not sure someone reading the document in its current form would get the same impression.

Joe


On 6/21/2017 6:13 PM, Bob Briscoe wrote:
Joe,

On 21/06/17 23:46, Joe Touch wrote:

Hi, Bob,


On 6/19/2017 10:41 AM, Bob Briscoe wrote:
Joe,

On 19/06/17 13:45, Joe Touch wrote:

Hi, Bob,

On 6/19/2017 4:37 AM, Bob Briscoe wrote:
Joe,

[Cutting the distr to nvo3 and adding tsvwg.]

On 16/06/17 20:38, Joe Touch wrote:

Hi, Bob,

This approach seems to assume an integrated implementation of multiple protocol layers.

There are other cases where the "shim" is added indirectly, as a packet is "tunneled" independently over multiple protocols.


So what aspect of the following para (in S.3.1) does not include the case(s) you are thinking of:
   In some cases a tunnel adds an outer IP header and a tightly coupled
   shim header to an inner header that is not an IP header, but that in
   turn encapsulates an IP header (or might encapsulate an IP header).
   For instance an inner Ethernet (or other link layer) header might
   encapsulate an inner IP header as its payload.  We call this a
   tightly coupled shim over an encapsulating header.
Can you be more specific? Or perhaps give an example? Or suggest an edit to the above text?

The issue is that the paragraph defines "tightly coupled" in terms of "tightly coupled".

AFAICT, "tightly coupled" depends on whether the layers are added all in the same software context or some "peeking" occurs after the shim layer is added but before the final IP.
So I think you are not objecting to the para I quoted above, but to something in the previous para, quoted here:
   In many cases the shim header(s) and the outer IP header are always
   added (or removed) as part of the same process.  We call this a
   tightly coupled shim header.  Processing the shim and outer together
   is often necessary because the shim(s) are not sufficient for packet
   forwarding in their own right; not unless complemented by an outer
   header.
Is the phrase "as part of the same process" the one you are objecting to?
Yes.

The doc is written a bit backwards; it presumes an optimization rather than presuming the safe default.
[BB] Your concern holds if one believes that every RFC is implicitly preceded be the statement "The IETF recommends that you comply with this RFC". In contrast, I believe there is nothing implicit around an RFC. I see an RFC solely as a specification of what an implementer can voluntarily choose to comply with in order to interoperate with others all collectively and voluntarily choosing to add a particular feature to the Internet.

I think some of our previous disagreement have hinged on this difference of opinion on the status of RFCs. If you know of any IETF document that resolves this, pls point to it. Otherwise, discussion of every I-D is going to tend to divert into an argument over this point.


Also, the doc is written based on an implementation hint ('process') rather than a protocol requirement.
[BB] I explained (still in the thread below) that the normative protocol requirements text a little later in the draft is (deliberately) not dependent on this scene-setting paragraph. A common way to write an RFC is to say "We have this sort of stuff in the world. Now here's some normative text that is written more generically so that it applies to that sort of stuff we have just described, as well as more general cases."


IMO, the recommendations should be:

ECN bits MUST be set to a known safe default when an IP layer is added,
EXCEPT if a tunnel is specified as the integrated insertion of multiple layers, then jumping layers to coordinate ECN MAY be valid
[BB] See above. This would be a good way to write this RFC, if it was implicitly surrounded by "The IETF recommends you comply with this RFC". But If implementers reading this RFC are a self-selecting set who are trying to implement ECN tunnelling, then the way it is written is a good way.

Neither is incorrect. But given RFC6040 is already immutably published. and it is written in the latter style, the only style that can be used for an update is the same style.


If so, I have no objection to using an alternative to the word 'process' to avoid the implication that this means specifically one 'process' as defined for the OS in question. It wasn't intended to use the word 'process' so strictly. The more general meaning of 'procedure' or 'routine' was intended.

The main point was that the definition of a shim is something that cannot be used alone to forward a packet to another network address, unless it is complemented by an outer PSN header.

Even when a shim is enough to accomplish such fowarding, if the shim lacks ECN support then ECN information should not be crossing the shim layer (unless the shim isn't really defined as a separate layer, e.g., the example I gave above would state that the tunnel encapsulation isn't shim THEN IP, but shim AND IP as an integrated step).
[BB] I don't disagree. I believe we are still only disagreeing about the implicit status of RFCs ("Commandments" vs. "Points to Voluntarily congregate around").

The difficulty being addressed in this section is that blindly copying an inner ECN field to an outer is unsafe (whether or not you want to support ECN).
Then IMHO that should be your title and focus.
[BB] It is the title, but only of the section. The document as a whole is about what it says in the title of the document: "Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim"

The doc reads a bit backwards, more focusing on the optimization of how and when you can do a smart copy across a shim than the basic idea that "this isn't how ECN works".

It's not that you don't say this, it's that a reader would get the reverse impression (i.e., that they should find a way to integrate shim processing to enable this leap, rather than the fact that this is a true exception and not the focus).
That is indeed the impression I would expect a reader to get, given I see readers as a self-selected set who are already motivated to find a way to enable this leap.

BTW, I have not come across an implementation yet that intrinsically cannot do this smart copy to enable ECN (or Diffserv) to leap across a shim. However, I would be surprised if there was not one.


Bob

Joe




_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


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

--------------51D21910B8C76F45B818DC82-- From nobody Fri Jun 23 17:16:40 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1661D12EB86; Fri, 23 Jun 2017 17:07:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tsvwg@ietf.org, spencerdawkins.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283708.7840.439839564020171405.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:17 -0700 Archived-At: Subject: [tsvwg] tsvwg - Requested sessions have been scheduled for IETF 99 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:17 -0000 Dear Gorry Fairhurst, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tsvwg Session 1 (1:00:00) Thursday, Afternoon Session III 1810-1910 Room Name: Congress Hall III size: 250 --------------------------------------------- tsvwg Session 2 (2:00:00) Tuesday, Afternoon Session I 1330-1530 Room Name: Congress Hall I size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Area Working Group Area Name: Transport Area Session Requester: Gorry Fairhurst Number of Sessions: 2 Length of Session(s): 1 Hour, 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: intarea tsvarea iccrg aqm rmcat tcpm mptcp taps ippm quic tcpinc rtgwg opsarea Second Priority: dtn rtcweb v6ops tram dispatch Third Priority: artarea ccamp People who must be present: David L. Black Gorry Fairhurst Spencer Dawkins Wesley Eddy Mirja Kuehlewind Resources Requested: Special Requests: [If rtcweb has 2 sessions, 1 should not conflict] [Must not conflict with Transport Area BoFs] --------------------------------------------------------- From nobody Tue Jun 27 04:14:05 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 155611267BB; Tue, 27 Jun 2017 04:13:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149856203804.14897.7445293422625503412@ietfa.amsl.com> Date: Tue, 27 Jun 2017 04:13:58 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc6040update-shim-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 11:13:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim Author : Bob Briscoe Filename : draft-ietf-tsvwg-rfc6040update-shim-03.txt Pages : 16 Date : 2017-06-27 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 updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols separated by such shim header(s) and updates the specifications of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE and Teredo). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-03 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 05:00:18 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6555129AD1; Tue, 27 Jun 2017 05:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 X3sn1z_sjLH9; Tue, 27 Jun 2017 05:00:06 -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 6DE5E129ABE; Tue, 27 Jun 2017 05:00:06 -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:From:Cc:To:References:Subject: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=xEA3WGcZJ4DY7w+iccN9PQ7hDQNw6Tv/8nOsJeeDve4=; b=v1f995+2Nj3yxEa2m9Fo1TQ5z WsC1m3+Fe9t/oJg5KsIR9BSDLI8+qabOsUK7oNtKtBAYVcE0FtKnBzGMU0xkCPQY5a3WsXWuwUPcX KZaMCKe1A2xZOlVBQSNv3c08GpaGd9cUwCnmLS9X1Cw8Mg3iwWZl5+H/QiE3JXE/OdNQXctgvkYg/ cTrp8+ThxTURhE7wyJrPL0acfcn2hB7oqkr4Yqmn16GejOimWXErwAtr5sl+LQIg2EhcItU1JOO5m 67JNpYx16SEt9CCbLxF88+OJNfrbjLe3j7yXN4SsqXlyF3BdB6A7fUtwpwyKBBcTlxVbrPduDAlGb GcW694M5w==; Received: from [31.185.128.124] (port=52714 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dPpA3-0002YR-Bm; Tue, 27 Jun 2017 13:00:03 +0100 References: <149856203820.14897.6223506257752075989.idtracker@ietfa.amsl.com> To: "Black, David" , "Carlos Pignataro (cpignata)" , Ignacio Goyret , Alia ATLAS , Praveen Balasubramanian , Joe Touch , "nvo3@ietf.org" , Christian Huitema Cc: tsvwg IETF list , intarea IETF list , l2tp IETF list , "opsawg-chairs@ietf.org" , Service Function Chaining IETF list From: Bob Briscoe X-Forwarded-Message-Id: <149856203820.14897.6223506257752075989.idtracker@ietfa.amsl.com> Message-ID: <291369ad-5f3a-e529-c2ef-24dfe2406b2f@bobbriscoe.net> Date: Tue, 27 Jun 2017 13:00:01 +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: <149856203820.14897.6223506257752075989.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------6A1261D435D710497D63773F" 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: Subject: [tsvwg] ECN over IP-shim-(L2)-IP Tunnels: New draft-ietf-tsvwg-rfc6040update-shim-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 12:00:10 -0000 This is a multi-part message in MIME format. --------------6A1261D435D710497D63773F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit David (as doc shepherd), This is the 3rd revision in the last 2 months. This revision attempts to capture all the comments collected thanks to Carlos, Ignacio, Praveen, Joe and Alia. It would be useful to have a confirmation from each of you that I have addressed your concerns (or not). I have cross-posted all the lists potentially affected by this draft (intended proposed standard). If you reply concerning a specific point, pls trim the distribution only to those interested/relevant. * tsvwg: owns updates to ECN * int-area: owns mtce of many tunnelling protocols, particularly GRE?, Teredo? GUE * l2tpext: owns mtce of L2TP * opsawg: owns mtce of CAPWAP * nvo3: currently defining Geneve, VXLAN-GPE * sfc: currently defining NSH From my point of view, this draft is now 'finished'. I.e. I am happy with it, and it is the first draft where all the ToDo's are done. I believe it is on track for the milestone of WGLC before the Nov'17 IETF. As I understand it, WGLC will run in tsvwg and in parallel in int-area, l2tpext and perhaps opsawg. Main changes since -02: * Completely restructured, with definitions of scope before even mentioning "tightly coupled shim headers", and new subsections where existing text on feasibility and desirability has been re-homed. * Explanation of the safety problem, and the procedural problem this caused when previous ECN RFCs were written (an RFC cannot retrospectively set requirements on implementations, so we can only set operational requirements - configuration). * Added NSH, but it doesn't seem to cover encapsulation. * No longer categorized VXLAN-GPE as intended for standards track * Added Teredo update text (for safety). Cheers Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-tsvwg-rfc6040update-shim-03.txt Date: Tue, 27 Jun 2017 04:13:58 -0700 From: internet-drafts@ietf.org To: Bob Briscoe A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-03.txt has been successfully submitted by Bob Briscoe and posted to the IETF repository. Name: draft-ietf-tsvwg-rfc6040update-shim Revision: 03 Title: Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim Document date: 2017-06-27 Group: tsvwg Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/ Htmlized: https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-03 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 updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide area packet forwarding. It surveys widely deployed IP tunnelling protocols separated by such shim header(s) and updates the specifications of those that do not mention ECN propagation (L2TPv2, L2TPv3, GRE and Teredo). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe. 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 --------------6A1261D435D710497D63773F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit David (as doc shepherd),

This is the 3rd revision in the last 2 months. This revision attempts to capture all the comments collected thanks to Carlos, Ignacio, Praveen, Joe and Alia. It would be useful to have a confirmation from each of you that I have addressed your concerns (or not).

I have cross-posted all the lists potentially affected by this draft (intended proposed standard).
If you reply concerning a specific point, pls trim the distribution only to those interested/relevant.

* tsvwg: owns updates to ECN
* int-area: owns mtce of many tunnelling protocols, particularly GRE?, Teredo? GUE
* l2tpext: owns mtce of L2TP
* opsawg: owns mtce of CAPWAP
* nvo3: currently defining Geneve, VXLAN-GPE
* sfc: currently defining NSH

From my point of view, this draft is now 'finished'. I.e. I am happy with it, and it is the first draft where all the ToDo's are done. I believe it is on track for the milestone of WGLC before the Nov'17 IETF. As I understand it, WGLC will run in tsvwg and in parallel in int-area, l2tpext and perhaps opsawg.

Main changes since -02:
* Completely restructured, with definitions of scope before even mentioning "tightly coupled shim headers", and new subsections where existing text on feasibility and desirability has been re-homed.
* Explanation of the safety problem, and the procedural problem this caused when previous ECN RFCs were written (an RFC cannot retrospectively set requirements on implementations, so we can only set operational requirements - configuration).
* Added NSH, but it doesn't seem to cover encapsulation.
* No longer categorized VXLAN-GPE as intended for standards track
* Added Teredo update text (for safety).

Cheers


Bob

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-tsvwg-rfc6040update-shim-03.txt
Date: Tue, 27 Jun 2017 04:13:58 -0700
From: internet-drafts@ietf.org
To: Bob Briscoe <ietf@bobbriscoe.net> 


A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-03.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name:		draft-ietf-tsvwg-rfc6040update-shim
Revision:	03
Title:		Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
Document date:	2017-06-27
Group:		tsvwg
Pages:		16
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-03

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 updates RFC 6040 to clarify that its
   scope includes tunnels where two IP headers are separated by at least
   one shim header that is not sufficient on its own for wide area
   packet forwarding.  It surveys widely deployed IP tunnelling
   protocols separated by such shim header(s) and updates the
   specifications of those that do not mention ECN propagation (L2TPv2,
   L2TPv3, GRE and Teredo).  This specification also updates RFC 6040
   with configuration requirements needed to make any legacy tunnel
   ingress safe.

                                                                                  


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
--------------6A1261D435D710497D63773F-- From nobody Tue Jun 27 13:52:52 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DC712EA56; Tue, 27 Jun 2017 13:52:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149859676199.31073.16978555797843649491@ietfa.amsl.com> Date: Tue, 27 Jun 2017 13:52:42 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 20:52:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Transport Options for UDP Author : Joe Touch Filename : draft-ietf-tsvwg-udp-options-01.txt Pages : 27 Date : 2017-06-27 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-01 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 27 13:57:47 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F1F12EB22; Tue, 27 Jun 2017 13:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 L27PIm4d6h3d; Tue, 27 Jun 2017 13:57:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1658F12EAC0; Tue, 27 Jun 2017 13:57:44 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v5RKvaYK005521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 Jun 2017 13:57:36 -0700 (PDT) To: internet-drafts@ietf.org, i-d-announce@ietf.org Cc: tsvwg@ietf.org References: <149859676199.31073.16978555797843649491@ietfa.amsl.com> From: Joe Touch Message-ID: Date: Tue, 27 Jun 2017 13:57:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <149859676199.31073.16978555797843649491@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 20:57:46 -0000 Hi, all, This update adds some clarification on how to handle options whose values depend on other options (e.g., ACS and AE). Joe On 6/27/2017 1:52 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group of the IETF. > > Title : Transport Options for UDP > Author : Joe Touch > Filename : draft-ietf-tsvwg-udp-options-01.txt > Pages : 27 > Date : 2017-06-27 > > Abstract: > Transport protocols are extended through the use of transport header > options. This document experimentally extends UDP by indicating the > location, syntax, and semantics for UDP transport layer options. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-01 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 28 01:47:49 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C44412EBFB for ; Wed, 28 Jun 2017 01:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no 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 DDqdgT-2dmjD for ; Wed, 28 Jun 2017 01:47:39 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 E255312EBF8 for ; Wed, 28 Jun 2017 01:47:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,274,1496095200"; d="scan'208,217";a="280946011" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2017 10:47:37 +0200 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_22B4C403-F9E7-4E5D-AD8F-3535D2B24671" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 28 Jun 2017 10:47:36 +0200 References: <149857927630.31141.7440659917539952133.idtracker@ietfa.amsl.com> Cc: Vincent Roca , "Ali C. Begen" To: tsvwg@ietf.org, nwcrg@irtf.org Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-roca-tsvwg-fecframev2-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 08:47:42 -0000 --Apple-Mail=_22B4C403-F9E7-4E5D-AD8F-3535D2B24671 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello everybody, Here is a new version of the "FECFRAME extension" I-D. Main differences are motivated by feedbacks received from Marie-Jos=C3=A9 = (see my email sent mid April): - "Section 3. Architecture Overview" now provides introductory material. = It quickly introduces FECFRAME architecture, terminology, and key concepts - References to =C2=AB convolutional codes =C2=BB have been replaced by = =C2=AB sliding window codes =C2=BB At this stage it is still submitted as an Individual I-D, even if this = I-D (and the companion FEC Scheme I-D) received significant support during WG Item Call at previous IETF98 = meeting. Once again we cross-post this message to the NWCRG mailing list where = the work has been initiated. Cheers, Vincent and Ali > De: internet-drafts@ietf.org > Objet: New Version Notification for draft-roca-tsvwg-fecframev2-04.txt > Date: 27 juin 2017 =C3=A0 18:01:16 UTC+2 > =C3=80: "Vincent Roca" , "Ali Begen" = >=20 >=20 > A new version of I-D, draft-roca-tsvwg-fecframev2-04.txt > has been successfully submitted by Vincent Roca and posted to the > IETF repository. >=20 > Name: draft-roca-tsvwg-fecframev2 > Revision: 04 > Title: Forward Error Correction (FEC) Framework = Extension to Sliding Window Codes > Document date: 2017-06-27 > Group: Individual Submission > Pages: 20 > URL: = https://www.ietf.org/internet-drafts/draft-roca-tsvwg-fecframev2-04.txt > Status: = https://datatracker.ietf.org/doc/draft-roca-tsvwg-fecframev2/ > Htmlized: = https://tools.ietf.org/html/draft-roca-tsvwg-fecframev2-04 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-roca-tsvwg-fecframev2-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-roca-tsvwg-fecframev2-04 >=20 > Abstract: > RFC 6363 describes a framework for using Forward Error Correction > (FEC) codes with applications in public and private IP networks to > provide protection against packet loss. The framework supports > applying FEC to arbitrary packet flows over unreliable transport and > is primarily intended for real-time, or streaming, media. However > FECFRAME as per RFC 6363 is restricted to block FEC codes. The > present document extends FECFRAME to support FEC Codes based on a > sliding encoding window, in addition to Block FEC Codes, in a > backward compatible way. During multicast/broadcast real-time > content delivery, the use of sliding window codes significantly > improves robustness in harsh environments, with less repair traffic > and lower FEC-related added latency. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_22B4C403-F9E7-4E5D-AD8F-3535D2B24671 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello everybody,

Here is a new version of the "FECFRAME extension" = I-D.
Main differences are motivated by feedbacks = received from Marie-Jos=C3=A9 (see my email sent mid April):

- "Section = 3. Architecture Overview" now provides introductory material. It = quickly introduces
FECFRAME architecture, = terminology, and key concepts
- References to = =C2=AB convolutional codes =C2=BB have been replaced by =C2=AB = sliding window codes =C2=BB

At this stage it is still submitted as = an Individual I-D, even if this I-D (and the companion FEC = Scheme
I-D) received significant support during WG = Item Call at previous IETF98 meeting.

Once again we = cross-post this message to the NWCRG mailing list where the work has = been initiated.

Cheers,

  Vincent and Ali


De: internet-drafts@ietf.org
Objet: = New Version = Notification for draft-roca-tsvwg-fecframev2-04.txt
Date: = 27 juin 2017 =C3=A0 18:01:16 = UTC+2
=C3=80: = "Vincent Roca" <vincent.roca@inria.fr>, "Ali Begen" <ali.begen@networked.media>

A new version of I-D, draft-roca-tsvwg-fecframev2-04.txt
has been successfully submitted by Vincent Roca and posted to = the
IETF repository.

Name: = draft-roca-tsvwg-fecframev2
Revision: 04
Title:= = Forward Error Correction (FEC) Framework Extension to Sliding = Window Codes
Document date: 2017-06-27
Group:= = Individual Submission
Pages: 20
URL: =            https://www.ietf.org/internet-drafts/draft-roca-tsvwg-fecframev= 2-04.txt
Status: =         https://datatracker.ietf.org/doc/draft-roca-tsvwg-fecframev2/
Htmlized:       https://tools.ietf.org/html/draft-roca-tsvwg-fecframev2-04<= br class=3D"">Htmlized:       https://datatracker.ietf.org/doc/html/draft-roca-tsvwg-fecframe= v2-04
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-roca-tsvwg-fecframev2= -04

Abstract:
=   RFC 6363 describes a framework for using Forward Error = Correction
  (FEC) codes with applications in = public and private IP networks to
  provide = protection against packet loss.  The framework supports
  applying FEC to arbitrary packet flows over = unreliable transport and
  is primarily = intended for real-time, or streaming, media.  However
=   FECFRAME as per RFC 6363 is restricted to block FEC codes. =  The
  present document extends FECFRAME = to support FEC Codes based on a
  sliding = encoding window, in addition to Block FEC Codes, in a
=   backward compatible way.  During multicast/broadcast = real-time
  content delivery, the use of = sliding window codes significantly
  improves = robustness in harsh environments, with less repair traffic
=   and lower FEC-related added latency.




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


= --Apple-Mail=_22B4C403-F9E7-4E5D-AD8F-3535D2B24671-- From nobody Wed Jun 28 02:04:15 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995E512EBFE for ; Wed, 28 Jun 2017 02:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no 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 G1TNNbUcoHkD for ; Wed, 28 Jun 2017 02:04:04 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 9168112EBFD for ; Wed, 28 Jun 2017 02:04:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.40,274,1496095200"; d="scan'208,217";a="280951098" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2017 11:04:01 +0200 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_6047F7EF-F180-4D97-8B4E-B3674374935C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 28 Jun 2017 11:04:01 +0200 References: <149857982583.31069.11724309388141175849.idtracker@ietfa.amsl.com> To: tsvwg@ietf.org, nwcrg@irtf.org Message-Id: <7C313B61-5DB9-422D-A001-8337E766B913@inria.fr> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-roca-tsvwg-rlc-fec-scheme-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 09:04:08 -0000 --Apple-Mail=_6047F7EF-F180-4D97-8B4E-B3674374935C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And here is the second I-D update... Main differences WRT -00 version, some of them motivated by M-J = feedbacks: - we replaced references to =C2=AB convolutional codes =C2=BB by =C2=AB = sliding window codes =C2=BB - we kept the acronym RLC but changed the expanded name to add =C2=AB = sliding window =C2=BB to it=20 (to avoid confusion as we already communicated a lot under the = RLC name) - we changed text in order to support multiple repair symbols per FEC = Repair Packet (useful when the symbol size E is small compared to the PMTU) - we filled Section 5. "FEC Code Specification =C2=BB that now describe = encoding and decoding operations This section plus Sections 3 and 4 should be sufficient to have = interoperable implementations (at least that=E2=80=99s the goal) - we detailed sections 7 =C2=AB Security Considerations =C2=BB and 8 =C2=AB= Operations and Management Considerations =C2=BB For the same reasons it is still submitted as an individual I-D and this = email is cross-posted to NWCRG. Cheers, Vincent > De: internet-drafts@ietf.org > Objet: New Version Notification for = draft-roca-tsvwg-rlc-fec-scheme-01.txt > Date: 27 juin 2017 =C3=A0 18:10:25 UTC+2 > =C3=80: "Vincent Roca" >=20 >=20 > A new version of I-D, draft-roca-tsvwg-rlc-fec-scheme-01.txt > has been successfully submitted by Vincent Roca and posted to the > IETF repository. >=20 > Name: draft-roca-tsvwg-rlc-fec-scheme > Revision: 01 > Title: The Sliding Window Random Linear Code (RLC) = Forward Erasure Correction (FEC) Scheme for FECFRAME > Document date: 2017-06-27 > Group: Individual Submission > Pages: 23 > URL: = https://www.ietf.org/internet-drafts/draft-roca-tsvwg-rlc-fec-scheme-01.tx= t > Status: = https://datatracker.ietf.org/doc/draft-roca-tsvwg-rlc-fec-scheme/ > Htmlized: = https://tools.ietf.org/html/draft-roca-tsvwg-rlc-fec-scheme-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-roca-tsvwg-rlc-fec-scheme-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-roca-tsvwg-rlc-fec-scheme-01 >=20 > Abstract: > This document describes a fully-specified FEC scheme for the Sliding > Window Random Linear Codes (RLC) over GF(2^^m), where m equals 1 > (binary case), 4 or 8, that can be used to protect arbitrary media > streams along the lines defined by FECFRAME extended to sliding > window codes. These sliding window FEC codes rely on an encoding > window that slides over the source symbols, generating new repair > symbols whenever needed. Compared to block FEC codes, these sliding > window FEC codes offer key advantages with real-time flows in terms > of reduced FEC-related latency while often providing improved = erasure > recovery capabilities. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_6047F7EF-F180-4D97-8B4E-B3674374935C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 And here is the second I-D update...

Main differences WRT -00 version, some of them = motivated by M-J feedbacks:

- we = replaced references to =C2=AB convolutional codes =C2=BB by =C2=AB= sliding window codes =C2=BB
- we kept the = acronym RLC but changed the expanded name to add =C2=AB sliding = window =C2=BB to it 
(to avoid = confusion as we already communicated a lot under the RLC name)
- we changed text in order to support multiple repair symbols = per FEC Repair Packet (useful when the
symbol = size E is small compared to the PMTU)
- we filled = Section 5. "FEC Code Specification =C2=BB that now describe = encoding and decoding operations
This = section plus Sections 3 and 4 should be sufficient to have interoperable = implementations
(at least that=E2=80=99s the = goal)
- we detailed sections 7 =C2=AB Security = Considerations =C2=BB and 8 =C2=AB Operations and Management = Considerations =C2=BB

For the same reasons it is still submitted as an individual = I-D and this email is cross-posted to NWCRG.

Cheers,

  Vincent


De: = internet-drafts@ietf.org
Objet: = New Version = Notification for draft-roca-tsvwg-rlc-fec-scheme-01.txt
Date: = 27 juin 2017 =C3=A0 18:10:25 = UTC+2
=C3=80: = "Vincent Roca" <vincent.roca@inria.fr>


A new version = of I-D, draft-roca-tsvwg-rlc-fec-scheme-01.txt
has been = successfully submitted by Vincent Roca and posted to the
IETF repository.

Name: = draft-roca-tsvwg-rlc-fec-scheme
Revision: 01
Title:= = The Sliding Window Random Linear Code (RLC) Forward Erasure = Correction (FEC) Scheme for FECFRAME
Document date: = 2017-06-27
Group: Individual Submission
Pages:= = 23
URL: =            https://www.ietf.org/internet-drafts/draft-roca-tsvwg-rlc-fec-s= cheme-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-roca-tsvwg-rlc-fec-schem= e/
Htmlized:       https://tools.ietf.org/html/draft-roca-tsvwg-rlc-fec-scheme-01<= /a>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-roca-tsvwg-rlc-fec-= scheme-01
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-roca-tsvwg-rlc-fec-sc= heme-01

Abstract:
=   This document describes a fully-specified FEC scheme for the = Sliding
  Window Random Linear Codes (RLC) over = GF(2^^m), where m equals 1
  (binary case), 4 = or 8, that can be used to protect arbitrary media
=   streams along the lines defined by FECFRAME extended to = sliding
  window codes.  These sliding = window FEC codes rely on an encoding
  window = that slides over the source symbols, generating new repair
=   symbols whenever needed.  Compared to block FEC codes, = these sliding
  window FEC codes offer key = advantages with real-time flows in terms
  of = reduced FEC-related latency while often providing improved erasure
  recovery capabilities.




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


= --Apple-Mail=_6047F7EF-F180-4D97-8B4E-B3674374935C-- From nobody Thu Jun 29 05:08:39 2017 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45508129B2B for ; Thu, 29 Jun 2017 05:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tcjMgRrV9_ry for ; Thu, 29 Jun 2017 05:08:36 -0700 (PDT) Received: from vesa.cs.pub.ro (vesa.cs.pub.ro [141.85.227.187]) by ietfa.amsl.com (Postfix) with ESMTP id 84BC71204DA for ; Thu, 29 Jun 2017 05:08:35 -0700 (PDT) IronPort-PHdr: =?us-ascii?q?9a23=3ALBABVRAWTWtRWPd1SZ2QUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSPT5oMbcNUDSrc9gkEXOFd2CrakV1KyO6+jJYi8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?= =?us-ascii?q?JvjvGo7Vks+7y/2+94fdbghMhjexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfO?= =?us-ascii?q?pWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnM?= =?us-ascii?q?VhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Qiqp4bt1RxD0iS?= =?us-ascii?q?cHLz85/3/Risxsl6JQvRatqwViz4LIfI2ZMfxzdb7fc9wHX2pMRttfVyJfDI28?= =?us-ascii?q?bIUBAeQOMulaoIbhvFYBtweyCBO2Ce/zxDJFhHn71rA63eQ7FgHG2RQtEN0KsH?= =?us-ascii?q?vOsdr1NaISUeGvzKLV1DvDa+9W1inn54jObxAqvPaBXax0ccXL1EYvFgbFjlSK?= =?us-ascii?q?qYD/ODOV0vgNvHaB4OpmSOKikHIoqxprrji328cjkZPFhpgSyl3d8yhy3Yg7Jd?= =?us-ascii?q?q9SEFhYN6kFoNdtyCEOItqTMMuWWZouDw1yrAApJW1fzAKxYw6yxPQdvCLaYuF?= =?us-ascii?q?7xL5WOqPPzt1hmhpdbynixqv/kWs1/fwW8q03VpQsCZInNfBumoQ2xHc9MSKTO?= =?us-ascii?q?Z28F271jaVzQ/T7/lJIUUzlaXGNZEs2qUwlp8PsUTbGS/2hVn2gLeWdko6/uio?= =?us-ascii?q?7PzqYqvjppCGNo90jhvyPbg1msClGeQ4LxMBU3KB+eS7zLHj/Ev5T6tWjvAuj6?= =?us-ascii?q?XUv43WKd4Yq6O5GQNZzJgv5hSlAzqoyNgYmGMILFNBeBKJlYjpPFTOLejmDfe7?= =?us-ascii?q?mVujjTZrx/XHPr37GJnNKXzDkKv/crln7U5c1RE+wsxE555OErEBPen8VlXrtN?= =?us-ascii?q?zfFhM5KRC7w/77CNVh0YMTQX6PArSHMKLcvl+F/eMvLPeQZI8bojr9LOIl5/G9?= =?us-ascii?q?xUM+zEMGY7am9ZoadH7+Ge5pcGuDZn+5vNMIHWYPvxB2a+j2hVSETHYHeXK7U6?= =?us-ascii?q?M55yt9D4a6AI7FW6imm/qZwS39BJoANTMOMUyFDXq9L9bMYPwLci/HZ5Y5yjE?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CXBADA7FRZjAPjVY1dHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBhBEDgQuOeJBRIpgMLoVuAoNlAQEBAQEBAQECARIBAQEmV4IzJAG?= =?us-ascii?q?CQAEDAyNUAhAcAwECKwICTQIIEwYCAQGKLwyyToImKYsgAQEBAQYBAQEBAQEig?= =?us-ascii?q?yeDTIIMC4JuhFQ2gnOCYQWJW4ZqgQWNLIIchSCOQlaBD4Nlg0uGeJUoAlaBCzA?= =?us-ascii?q?hV4VLgXVzAYlAAQEB?= X-IPAS-Result: =?us-ascii?q?A2CXBADA7FRZjAPjVY1dHAEBBAEBCgEBFwEBBAEBCgEBhBE?= =?us-ascii?q?DgQuOeJBRIpgMLoVuAoNlAQEBAQEBAQECARIBAQEmV4IzJAGCQAEDAyNUAhAcA?= =?us-ascii?q?wECKwICTQIIEwYCAQGKLwyyToImKYsgAQEBAQYBAQEBAQEigyeDTIIMC4JuhFQ?= =?us-ascii?q?2gnOCYQWJW4ZqgQWNLIIchSCOQlaBD4Nlg0uGeJUoAlaBCzAhV4VLgXVzAYlAA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.40,280,1496091600"; d="scan'208,217";a="861631" Received: from mail.cs.pub.ro (HELO vmail.cs.pub.ro) ([141.85.227.3]) by vesa.cs.pub.ro with ESMTP; 29 Jun 2017 15:08:34 +0300 Received: from localhost (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTP id 098CE1A600CA; Thu, 29 Jun 2017 15:08:34 +0300 (EEST) Received: from vmail.cs.pub.ro ([127.0.0.1]) by localhost (vmail.cs.pub.ro [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id aloIc5kCPGQu; Thu, 29 Jun 2017 15:08:33 +0300 (EEST) Received: from vmail.cs.pub.ro (localhost [127.0.0.1]) by vmail.cs.pub.ro (Postfix) with ESMTPS id DE5D01A60151; Thu, 29 Jun 2017 15:08:33 +0300 (EEST) Received: from [172.19.2.57] (unknown [141.85.233.142]) by vmail.cs.pub.ro (Postfix) with ESMTPSA id D91661A600CA; Thu, 29 Jun 2017 15:08:33 +0300 (EEST) References: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> To: tsvwg@ietf.org From: Vladimir Olteanu X-Forwarded-Message-Id: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 29 Jun 2017 15:08:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <149871247634.6490.5928844232347189122.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------4790451F86075B5EB7B934CC" Content-Language: en-US Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-olteanu-intarea-socks-6-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 12:08:38 -0000 This is a multi-part message in MIME format. --------------4790451F86075B5EB7B934CC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, We have submitted a draft describing a new version of the SOCKS=20 protocol. You can find the abstract and a link to the draft below. Best, Vlad and Drago=C8=99 -------- Forwarded Message -------- Subject: New Version Notification for draft-olteanu-intarea-socks-6-00.t= xt Date: Wed, 28 Jun 2017 22:01:16 -0700 From: internet-drafts@ietf.org To: Vladimir Olteanu , Dragos Niculescu=20 A new version of I-D, draft-olteanu-intarea-socks-6-00.txt has been successfully submitted by Vladimir Olteanu and posted to the IETF repository. Name: draft-olteanu-intarea-socks-6 Revision: 00 Title: SOCKS Protocol Version 6 Document date: 2017-06-28 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-olteanu-intare= a-socks-6-00.txt Status: https://datatracker.ietf.org/doc/draft-olteanu-intarea-so= cks-6/ Htmlized: https://tools.ietf.org/html/draft-olteanu-intarea-socks-6= -00 Htmlized: https://datatracker.ietf.org/doc/html/draft-olteanu-intar= ea-socks-6-00 Abstract: The SOCKS protocol is used primarily to proxy TCP connections to arbitrary destinations via the use of a proxy server. Under the latest version of the protocol (version 5), it takes 2 RTTs (or 3, if authentication is used) before data can flow between the client and the server. This memo proposes SOCKS version 6, which reduces the number of RTTs used, takes full advantage of TCP Fast Open, and adds support for 0-RTT authentication. = =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------4790451F86075B5EB7B934CC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hello,

We have submitted a draft describing a new version of the SOCKS protocol. You can find the abstract and a link to the draft below.<= br>
Best,
Vlad and Drago=C8=99



-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-olteanu-intarea-socks-6-00.txt
Dat= e: Wed, 28 Jun 2017 22:01:16 -0700
Fro= m: internet-drafts@ietf.org
To:= Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>, Dragos Niculescu <dragos.niculescu@cs.pub.ro> 


A new version of I-D, draft-olteanu-intarea-socks-6-00.txt
has been successfully submitted by Vladimir Olteanu and posted to the
IETF repository.

Name:		draft-olteanu-intarea-socks-6
Revision:	00
Title:		SOCKS Protocol Version 6
Document date:	2017-06-28
Group:		Individual Submission
Pages:		12
URL:            https://www.=
ietf.org/internet-drafts/draft-olteanu-intarea-socks-6-00.txt
Status:         https://datatracker.ie=
tf.org/doc/draft-olteanu-intarea-socks-6/
Htmlized:       https://tools.ietf.org/ht=
ml/draft-olteanu-intarea-socks-6-00
Htmlized:       https://datatra=
cker.ietf.org/doc/html/draft-olteanu-intarea-socks-6-00


Abstract:
   The SOCKS protocol is used primarily to proxy TCP connections to
   arbitrary destinations via the use of a proxy server.  Under the
   latest version of the protocol (version 5), it takes 2 RTTs (or 3, if
   authentication is used) before data can flow between the client and
   the server.

   This memo proposes SOCKS version 6, which reduces the number of RTTs
   used, takes full advantage of TCP Fast Open, and adds support for
   0-RTT authentication.

                                                                         =
        =20


Please note that it may take a couple of minutes from the time of submiss=
ion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------4790451F86075B5EB7B934CC-- From nobody Fri Jun 30 01:08:32 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD5E127977; Fri, 30 Jun 2017 01:08:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149881011155.4592.15528543773256522295@ietfa.amsl.com> Date: Fri, 30 Jun 2017 01:08:31 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-le-phb-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 08:08:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : A Lower Effort Per-Hop Behavior (LE PHB) Author : Roland Bless Filename : draft-ietf-tsvwg-le-phb-02.txt Pages : 12 Date : 2017-06-30 Abstract: This document specifies properties and characteristics of a Lower Effort (LE) per-hop behavior (PHB). The primary objective of this LE PHB is to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, best-effort traffic has precedence over LE traffic and may preempt it. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard DSCP value for the LE PHB. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-02 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-le-phb-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-le-phb-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/