From nobody Tue Jan 1 13:26:26 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A861B129A87; Tue, 1 Jan 2019 13:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VKfQ9lpo1-eM; Tue, 1 Jan 2019 13:26:24 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 95659128D52; Tue, 1 Jan 2019 13:26:21 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id m62so38960371ith.5; Tue, 01 Jan 2019 13:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Lp+zZ6xsNeruoRqKNyGR/c3hrU7dqkEgb733owljDmw=; b=gA785Bzn5uiLAd/rLLGxBQpimA7M3TIHDQdBSv89sb5+H/7eIwBF1Jflb+vP46Fedo Ru8Z/zMAUA+RaesRcRB7SaTXiiVMO8WjhtEyrCJowXafzmkFSX3l8GvsmBMYQpgEVM60 a5OoMg9B4xsiukC56AOy+Lu5zW96cVUfhbnXGNEKhwtO5DQWzS01OZZAEz/QurdWow2F 9c7lsDdAuatu8rPNpdjkL8P380L62peracc5LOIEGHHNTJ6UlTCf2ZmOMiH9cV0imoW0 sp87OzAqqlI6o9SRsCUf2sBkitUWEW2ZE+6zcwNLHJLL+yUdX9Dt+mOACH8XxOA7IFJU UptA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Lp+zZ6xsNeruoRqKNyGR/c3hrU7dqkEgb733owljDmw=; b=gF52aNz1SmbrZHveGCOAi8YSobsDd6zXJ6CmYVgFgLZgvCrie0dYdbxV7q35FHkJe5 eC9q37PcKJsGXfioizUmhUMBqDISRfqjqgO123EQfPTmV9ZNrBJEjF/Cqazy2W7eWQqU LnNQKZ8gm0M7onJGge5ii1Qt89BrmHx5yqfcwp/m9nHlp+WrPCWFr1C2dS4LWuyMuyag vRjr33L0sjN05sA06Cwh4UxI3MPacWB0LhiCEeXY5JFMyvVsYUOYk1LottYZwvpCGBlj /gUcIoEuSfraY5V8SlH+qYEfN63EZq8AoKI86prigFNxSXNwHvZCzouDw4aEUtUgB2cj 2z4w== X-Gm-Message-State: AA+aEWbmIRz83rGbLoaSUzPpM+DpXd9NnmKbxQtoLAJRcws3DtDOM+47 tBcQ8IEf7J91kCCwKKGP8NiBb6FraJalImghJW9rvJ/X X-Google-Smtp-Source: ALg8bN4Riad9uZgd/cuGanxJPBYNZq2OBNdy7q4iaBupeLUJs0UhFV8Cu6L9atF0LVGpKgxW/RhF6WEsnITqkfvK8tc= X-Received: by 2002:a24:36cf:: with SMTP id l198mr28829804itl.102.1546377980570; Tue, 01 Jan 2019 13:26:20 -0800 (PST) MIME-Version: 1.0 From: Donald Eastlake Date: Tue, 1 Jan 2019 16:26:09 -0500 Message-ID: To: sfc@ietf.org Cc: draft-eastlake-sfc-nsh-ecn-support@ietf.org Content-Type: multipart/alternative; boundary="000000000000386fe4057e6c2e8e" Archived-At: Subject: Re: [sfc] draft-eastlake-sfc-nsh-ecn-support X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2019 21:26:26 -0000 --000000000000386fe4057e6c2e8e Content-Type: text/plain; charset="UTF-8" Seasons Greetings I spazzed in the file name in the message below, leaving out the "-nsh" so I'm correcting that in this message. I'd like to renew my request to start a WG LC. The draft is here https://tools.ietf.org/html/draft-eastlake-sfc-nsh-ecn-support-02 Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Sat, Nov 10, 2018 at 1:21 AM Donald Eastlake wrote: > Hi, > > As discussed at the SFC meeting, I think draft-eastlake-sfc-ecn-support is > ready for WG adoption and request that an adoption poll be started. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > --000000000000386fe4057e6c2e8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Seasons Greetings
<= div dir=3D"ltr">
I spazzed in the file name in th= e message below, leaving out the "-nsh" so I'm correcting tha= t in this message. I'd like to renew my request to start a WG LC. The d= raft is here

Thanks,
Donald
=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
=C2=A0Donald E. Eastlake 3rd = =C2=A0 +1-508-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 3= 3896 USA
=C2=A0d3e= 3e3@gmail.com


On Sat, Nov 10, 2018 at 1:21 AM Donald Eastlake <d3e3e3@gmail.com> wrote:<= br>
Hi,

As discussed at the SFC meeting, I think draft-east= lake-sfc-ecn-support is ready for WG adoption and request that an adoption = poll be started.

Thanks,<= br>Donald
=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
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1= -508-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA<= br>=C2=A0d3e3e3@gmail= .com
--000000000000386fe4057e6c2e8e-- From nobody Tue Jan 1 13:51:06 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AD212D4EB; Tue, 1 Jan 2019 13:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jTgm17CvZjjU; Tue, 1 Jan 2019 13:51:02 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 8F8D9129BBF; Tue, 1 Jan 2019 13:51:02 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id l14so23319852ioj.5; Tue, 01 Jan 2019 13:51:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qyIytH6sr9PrW7h/Pz9fF0imFXJ6zU+piz5pXc7I2Sw=; b=HTiMaAqByeoFTbF6UZQYZg7GEhmKnPkleC0Myq7efT746tJIQjRf7v5OzOcL5J7ohc iI5hqbQHpM383vPSM8VXs9bs0l/oAZpAYDmePGhPlHMzzhKYGMZTEFxyXHBbs3LlrXlw M8OacwCVZi3eDQVcsLBcyth4EenKw9vst+XBxnbQ0IyB16qoqINKLHqK8J/Rr5IlcIUu QEIRw5shkSGYgDzzaP+5EQ6FHDe/Vp5lKUjcrO5SKQ3gP9dP6wJUIiQGF0r64sb5pgIr lfm0SQwoh3dNLLTrVoUq0F5IJjNG7a1oUCFJRO6kVbrP1dm9JAI1XH+yG6x1co6VRoQF BowA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qyIytH6sr9PrW7h/Pz9fF0imFXJ6zU+piz5pXc7I2Sw=; b=tVBtW//SplHGcbl6jQGJb/+i1bLi3RsBzZTTVdWnFmJzIpRODp0bNtnQHFa9P84GCg svUgOa1RJ+8dG08Y8MIvI/16SYkOrt07acIrfCmPDL0lyFIxGkQCTgN7zuPx7fdCIjTB qX7WeBrfNHfc95xIEsW3aD1rHyUJl7LEVEOgJUbUNE5X0SzmPS6bda+NL9aDWuvNRr3f CPVgO9fLgzSSFIuUvepGifVsR/62UfBzDr5Y9F9jkb6Qjwoe9cvucCCyuxUYB1D3wk7u QxUzC6dALCpS+OSA/y/dV0DrnwI0qJcQ0bpmrWYoiS9MNemfl3wUhlpYAL9AWQaBXTlr bfDw== X-Gm-Message-State: AJcUukdZCK5SlMuxxEBTefd3Yf0v7jKbE3+7pozb2OXwrmxK1lfPosa/ FZteULj6Ayb+ON3i2xTsgDiUd42712f32FKgWbqov7Jn X-Google-Smtp-Source: ALg8bN4lGz0WrPbvNqRl0SAMgIAwbhTAZqCKoFhGSYClcmU0KSpn9guea/e8FrfhTjATJvxTiICPHInNqylq2cispHg= X-Received: by 2002:a5d:88ce:: with SMTP id i14mr32180574iol.66.1546379461510; Tue, 01 Jan 2019 13:51:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Donald Eastlake Date: Tue, 1 Jan 2019 16:50:50 -0500 Message-ID: To: sfc@ietf.org Cc: draft-eastlake-sfc-nsh-ecn-support@ietf.org Content-Type: multipart/alternative; boundary="0000000000007dc8cd057e6c86ed" Archived-At: Subject: Re: [sfc] draft-eastlake-sfc-nsh-ecn-support X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2019 21:51:04 -0000 --0000000000007dc8cd057e6c86ed Content-Type: text/plain; charset="UTF-8" Third time is the Charm. I mean a call for WG Adoption as in the first message. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Tue, Jan 1, 2019 at 4:26 PM Donald Eastlake wrote: > Seasons Greetings > > I spazzed in the file name in the message below, leaving out the "-nsh" so > I'm correcting that in this message. I'd like to renew my request to start > a WG LC. The draft is here > https://tools.ietf.org/html/draft-eastlake-sfc-nsh-ecn-support-02 > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > > > On Sat, Nov 10, 2018 at 1:21 AM Donald Eastlake wrote: > >> Hi, >> >> As discussed at the SFC meeting, I think draft-eastlake-sfc-ecn-support >> is ready for WG adoption and request that an adoption poll be started. >> >> Thanks, >> Donald >> =============================== >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 1424 Pro Shop Court, Davenport, FL 33896 USA >> d3e3e3@gmail.com >> > --0000000000007dc8cd057e6c86ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Third time is the Charm. I mean a call for WG Adoption as = in the first message.

Thanks,
Donald
= =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
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (= cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com
<= /div>

On Tue= , Jan 1, 2019 at 4:26 PM Donald Eastlake <d3e3e3@gmail.com> wrote:
Se= asons Greetings

I spazzed = in the file name in the message below, leaving out the "-nsh" so = I'm correcting that in this message. I'd like to renew my request t= o start a WG LC. The draft is here
https://tools.ietf.org/html/draft-eastlake-sfc-nsh-ecn-support-02
Thanks,
Donald
=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
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
= =C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.com

=

On Sat, Nov 10, 2018 = at 1:21 AM Donald Eastlake <d3e3e3@gmail.com> wrote:
Hi,

As disc= ussed at the SFC meeting, I think draft-eastlake-sfc-ecn-support is ready f= or WG adoption and request that an adoption poll be started.

Thanks,
D= onald
=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
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-3= 33-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2= =A0d3e3e3@gmail.com
--0000000000007dc8cd057e6c86ed-- From nobody Tue Jan 1 15:27:17 2019 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF5212008A; Tue, 1 Jan 2019 15:27:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <154638522960.28373.1804101579367312699@ietfa.amsl.com> Date: Tue, 01 Jan 2019 15:27:09 -0800 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-09.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2019 23:27:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Service Function Chaining Use Cases in Mobile Networks Authors : Walter Haeffner Jeffrey Napper Martin Stiemerling Diego R. Lopez Jim Uttaro Filename : draft-ietf-sfc-use-case-mobility-09.txt Pages : 26 Date : 2019-01-01 Abstract: This document provides some exemplary use cases for service function chaining in mobile service provider networks. The objective of this draft is not to cover all conceivable service chains in detail. Rather, the intention is to localize and explain the application domain of service chaining within mobile networks as far as it is required to complement the SFC problem statement and architecture framework of the working group. Service function chains typically reside in a LAN segment which links the mobile access network to the actual application platforms located in the carrier's datacenters or somewhere else in the Internet. Service function chains (SFC) ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery or take care of security and privacy. SFCs may also include Value Added Services (VAS). Commonly, SFCs are typical middle box based services. General considerations and specific use cases are presented in this document to demonstrate the different technical requirements of these goals for service function chaining in mobile service provider networks. The specification of service function chaining for mobile networks must take into account an interaction between service function chains and the 3GPP Policy and Charging Control (PCC) environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-09 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-use-case-mobility-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-use-case-mobility-09 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 Jan 2 16:41:25 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7390F12D4EB for ; Wed, 2 Jan 2019 16:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 tJ-QzdaOfVZN for ; Wed, 2 Jan 2019 16:41:21 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 5053C1200D7 for ; Wed, 2 Jan 2019 16:41:20 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id D5977E6A5B1B25BF3AE0 for ; Thu, 3 Jan 2019 08:41:18 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id BF440C8C75530963345C for ; Thu, 3 Jan 2019 08:41:18 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id x030fHSA068733 for ; Thu, 3 Jan 2019 08:41:17 +0800 (GMT-8) (envelope-from ao.ting@zte.com.cn) Message-Id: <201901030041.x030fHSA068733@mse01.zte.com.cn> Received: from xgxapp03.zte.com.cn ([10.30.14.24]) by mse01.zte.com.cn with SMTP id x02Eg9Dm064935 for ; Wed, 2 Jan 2019 22:42:09 +0800 (GMT-8) (envelope-from ao.ting@zte.com.cn) Received: from mapi (xgxapp03[null]) by mapi (Zmail) with MAPI id mid71; Wed, 2 Jan 2019 22:42:11 +0800 (CST) Date: Wed, 2 Jan 2019 22:42:11 +0800 (CST) X-Zmail-TransId: 2afb5c2ccdc3ab40a4b0 X-Mailer: Zmail v1.0 References: 154589912163.11942.4493370819356671143.idtracker@ietfa.amsl.com Mime-Version: 1.0 From: To: Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse01.zte.com.cn x030fHSA068733 X-MSS: AUDITRELEASE@mse01.zte.com.cn Archived-At: Subject: [sfc] =?utf-8?q?Fw=3ANew_Version_Notification_for_draft-ao-sfc-o?= =?utf-8?q?am-path-consistency-04=2Etxt?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 00:41:24 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgYWxs77yMDQoNCg0KDQoNCg0KDQoNCldlIGhhdmUgdXBkYXRlZCBhIG5ldyB2ZXJzaW9uIGZv ciBkcmFmdCBkcmFmdC1hby1zZmMtb2FtLXBhdGgtY29uc2lzdGVuY3ktMDQgYmFzZWQgb24gdGhl IGRpc2N1c3Npb24gaW4gdGhlIG1haWxpc3QuIFRoZSBtYWluIGNoYW5nZSBpcyB0aGUgQ09BTSBS ZXBseSBtZXNzYWdlIGZvciBsb2FkIGJhbGFuY2Ugc2NlbmFyaW8gaW4gc2VjdGlvbiAzLjQuMi4g IEFueSBjb21tZW50cyBhcmUgYWx3YXlzIHdlbGNvbWUuDQoNCg0KDQoNCg0KDQpXZSB0aGluayBi b3RoIGRyYWZ0LWFvLXNmYy1vYW0tcGF0aC1jb25zaXN0ZW5jeS0wNChodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtYW8tc2ZjLW9hbS1wYXRoLWNvbnNpc3RlbmN5LTA0KSBhbmQgZHJh ZnQtYW8tc2ZjLW9hbS1yZXR1cm5lZC1wYXRoLXNwZWNpZmllZC0wMihodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtYW8tc2ZjLW9hbS1yZXR1cm4tcGF0aC1zcGVjaWZpZWQtMDIpIGFy ZSByZWFkeS4gV2UgcmVxdWVzdCBmb3IgdGhlIGNvbnNpZGVyYXRpb24gb2YgdGhlIFdHIGFkb3B0 aW9uLg0KDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRzLg0KDQoNCg0KDQpUaW5nIEFvDQoNCg0KDQoN Cg0KDQoNCg0KDQrljp/lp4vpgq7ku7YNCg0KDQoNCuWPkeS7tuS6uu+8mmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K5pS25Lu25Lq677yaR3JlZ29y eSBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT475pWW5am3MDAwNzEyNDY7S2VudCBMZXVu ZyA8a2xldW5nQGNpc2NvLmNvbT47WmhvbmdodWEgQ2hlbiA8MTg5MTg1ODg4OTdAMTg5LmNuPjtH cmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPjsNCuaXpSDmnJ8g77yaMjAxOOW5tDEy 5pyIMjfml6UgMTY6MjYNCuS4uyDpopgg77yaTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1hby1zZmMtb2FtLXBhdGgtY29uc2lzdGVuY3ktMDQudHh0DQoNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtYW8tc2ZjLW9hbS1wYXRoLWNvbnNpc3RlbmN5LTA0LnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaW5nIEFvIGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICBkcmFmdC1hby1zZmMtb2FtLXBhdGgt Y29uc2lzdGVuY3kNClJldmlzaW9uOiAgICAwNA0KVGl0bGU6ICAgICAgICBTRkMgT0FNIGZvciBw YXRoIGNvbnNpc3RlbmN5DQpEb2N1bWVudCBkYXRlOiAgICAyMDE4LTEyLTI3DQpHcm91cDogICAg ICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAxMQ0KVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hby1zZmMtb2Ft LXBhdGgtY29uc2lzdGVuY3ktMDQudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYW8tc2ZjLW9hbS1wYXRoLWNvbnNpc3RlbmN5Lw0KSHRt bGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hby1zZmMtb2Ft LXBhdGgtY29uc2lzdGVuY3ktMDQNCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWFvLXNmYy1vYW0tcGF0aC1jb25zaXN0ZW5jeQ0KRGlm ZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1hby1z ZmMtb2FtLXBhdGgtY29uc2lzdGVuY3ktMDQNCg0KQWJzdHJhY3Q6DQogICBTZXJ2aWNlIEZ1bmN0 aW9uIENoYWluIChTRkMpIGRlZmluZXMgYW4gb3JkZXJlZCBzZXQgb2Ygc2VydmljZQ0KICAgZnVu Y3Rpb25zIChTRnMpIHRvIGJlIGFwcGxpZWQgdG8gcGFja2V0cyBhbmQvb3IgZnJhbWVzIGFuZC9v ciBmbG93cw0KICAgc2VsZWN0ZWQgYXMgYSByZXN1bHQgb2YgY2xhc3NpZmljYXRpb24uICBTRkMg T3BlcmF0aW9uLA0KICAgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50ZW5hbmNlIGNhbiBtb25pdG9y IHRoZSBjb250aW51aXR5IG9mIHRoZSBTRkMsDQogICBpLmUuLCB0aGF0IGFsbCBlbGVtZW50cyBv ZiB0aGUgU0ZDIGFyZSByZWFjaGFibGUgdG8gZWFjaCBvdGhlciBpbiB0aGUNCiAgIGRvd25zdHJl YW0gZGlyZWN0aW9uLiAgQnV0IFNGQyBPQU0gbXVzdCBzdXBwb3J0IHZlcmlmaWNhdGlvbiB0aGF0 IHRoZQ0KICAgb3JkZXIgb2YgdHJhdmVyc2luZyB0aGVzZSBTRnMgY29ycmVzcG9uZHMgdG8gdGhl IHN0YXRlIGRlZmluZWQgYnkgdGhlDQogICBTRkMgY29udHJvbCBwbGFuZSBvciBvcmNoZXN0cmF0 b3IsIHRoZSBtZXRyaWMgcmVmZXJyZWQgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXMgdGhlIHBhdGgg Y29uc2lzdGVuY3kgb2YgdGhlIFNGQy4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhDQogICBuZXcg U0ZDIE9BTSBtZXRob2QgdG8gc3VwcG9ydCBTRkMgY29uc2lzdGVuY3kgY2hlY2ssIGkuZS4NCiAg IHZlcmlmaWNhdGlvbiB0aGF0IGFsbCBlbGVtZW50cyBvZiB0aGUgZ2l2ZW4gU0ZDIGFyZSBiZWlu ZyB0cmF2ZXJzZWQNCiAgIGluIHRoZSBleHBlY3RlZCBvcmRlci4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0 --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPkhpIGFsbO+8jDxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2Zv bnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1m YW1pbHk6YXJpYWw7Ij5XZSBoYXZlIHVwZGF0ZWQgYSBuZXcgdmVyc2lvbiBmb3IgZHJhZnQ8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxNHB4OyI+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbCwg5a6L5L2TLCAnTWljcm9zb2Z0IFlhaGVpJywgJ0x1Y2lkYSBHcmFuZGUnLCBWZXJk YW5hLCBMdWNpZGEsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgbGluZS1oZWlnaHQ6IDIwcHg7IGJh Y2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPmRyYWZ0LWFvLXNmYy1vYW0tcGF0 aC1jb25zaXN0ZW5jeS0wNCBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBpbiB0aGUgbWFpbGlzdC4g VGhlIG1haW4gY2hhbmdlIGlzIHRoZSBDT0FNIFJlcGx5IG1lc3NhZ2UgZm9yIGxvYWQgYmFsYW5j ZSBzY2VuYXJpbyBpbiBzZWN0aW9uIDMuNC4yLiAmbmJzcDtBbnkgY29tbWVudHMgYXJlIGFsd2F5 cyB3ZWxjb21lLjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250 LWZhbWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0cHg7Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLCDlrovkvZMsICdNaWNyb3NvZnQgWWFoZWknLCAnTHVjaWRh IEdyYW5kZScsIFZlcmRhbmEsIEx1Y2lkYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBsaW5lLWhl aWdodDogMjBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPjwv c3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlh bDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBBcmlhbCwg5a6L 5L2TLCAnTWljcm9zb2Z0IFlhaGVpJywgJ0x1Y2lkYSBHcmFuZGUnLCBWZXJkYW5hLCBMdWNpZGEs IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgbGluZS1oZWlnaHQ6IDIwcHg7IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPldlIHRoaW5rIGJvdGggPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IEFyaWFsLCDlrovkvZMsICdNaWNyb3NvZnQgWWFoZWkn LCAnTHVjaWRhIEdyYW5kZScsIFZlcmRhbmEsIEx1Y2lkYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlm OyBsaW5lLWhlaWdodDogMjBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg5a6L5L2TLCAnTWljcm9zb2Z0IFlh aGVpJywgJ0x1Y2lkYSBHcmFuZGUnLCBWZXJkYW5hLCBMdWNpZGEsIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsgbGluZS1oZWlnaHQ6IDIwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPmRyYWZ0LWFvLXNmYy1vYW0tcGF0aC1jb25zaXN0ZW5jeS0wNCg8YSB0YXJnZXQ9Il9i bGFuayIgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFvLXNmYy1vYW0t cGF0aC1jb25zaXN0ZW5jeS0wNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFv LXNmYy1vYW0tcGF0aC1jb25zaXN0ZW5jeS0wNDwvYT4pIGFuZCBkcmFmdC1hby1zZmMtb2FtLXJl dHVybmVkLXBhdGgtc3BlY2lmaWVkLTAyKDxhIHRhcmdldD0iX2JsYW5rIiBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYW8tc2ZjLW9hbS1yZXR1cm4tcGF0aC1zcGVjaWZp ZWQtMDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hby1zZmMtb2FtLXJldHVy bi1wYXRoLXNwZWNpZmllZC0wMjwvYT4pIGFyZSByZWFkeS4gV2UgcmVxdWVzdCBmb3IgdGhlIGNv bnNpZGVyYXRpb24gb2YgdGhlIFdHIGFkb3B0aW9uLjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvcD48 cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxwIHN0 eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsiPkJlc3QgUmVnYXJkcy48L3A+ PGRpdiBjbGFzcz0iek1haWxTaWduIiB1bm9uYW1lY2g9IuaVluWptzAwMDcxMjQ2IiB1bm9uYW1l ZW49ImFvIHRpbmcwMDA3MTI0NiI+PGRpdiBjbGFzcz0iek1haWxTaWduQ29udGVudCI+PHAgc3R5 bGU9Im1hcmdpbjowO2xpbmUtaGVpZ2h0OjIwcHg7Ij48c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlk PSJzaWduX25hbWVfZW5nIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAjMDA4ZWQz O2ZvbnQtc2l6ZTogMTRweCI+VGluZyBBbzwvc3Bhbj48L3A+PHAgc3R5bGU9Im1hcmdpbjowO2xp bmUtaGVpZ2h0OjIwcHg7Ij48c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlkPSJzaWduX3Bvc2l0aW9u X2VuZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHgiPjwvc3Bhbj48 YnI+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlSb3ciIHN0eWxlPSJk aXNwbGF5OmJsb2NrIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeURlcyIgc3R5bGU9IndpZHRoOiAxMDAl OyBoZWlnaHQ6IDI4cHg7IGxpbmUtaGVpZ2h0OiAyOHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRTBF NUU5OyBjb2xvcjogIzEzODhGRjsgdGV4dC1hbGlnbjogY2VudGVyOyIgbGFuZ3VhZ2UtZGF0YT0i SGlzdG9yeU9yZ1R4dCI+5Y6f5aeL6YKu5Lu2PC9kaXY+PGRpdiBpZD0iendyaXRlSGlzdG9yeUNv bnRhaW5lciI+PGRpdiBjbGFzcz0iY29udHJvbC1ncm91cCB6aGlzdG9yeVBhbmVsIj48ZGl2IGNs YXNzPSJ6aGlzdG9yeUhlYWRlciIgc3R5bGU9InBhZGRpbmc6IDhweDsgYmFja2dyb3VuZC1jb2xv cjogI0Y1RjZGODsiPjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5U2VuZGVyVHh0 Ij7lj5Hku7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSI+aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnICZsdDtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcmZ3Q7PC9zcGFu PjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5VE9UeHQiPuaUtuS7tuS6 uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTog aW5saW5lOyI+R3JlZ29yeSBNaXJza3kgJmx0O2dyZWdpbWlyc2t5QGdtYWlsLmNvbSZndDs7PC9z cGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+ 5pWW5am3MDAwNzEyNDY7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0i ZGlzcGxheTogaW5saW5lOyI+S2VudCBMZXVuZyAmbHQ7a2xldW5nQGNpc2NvLmNvbSZndDs7PC9z cGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+ WmhvbmdodWEgQ2hlbiAmbHQ7MTg5MTg1ODg4OTdAMTg5LmNuJmd0Ozs8L3NwYW4+PHNwYW4gY2xh c3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5HcmVnIE1pcnNreSAm bHQ7Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0Ozs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxh bmd1YWdlLWRhdGE9Ikhpc3RvcnlEYXRlVHh0Ij7ml6Ug5pyfIO+8mjwvc3Ryb25nPjxzcGFuIGNs YXNzPSIiPjIwMTjlubQxMuaciDI35pelIDE2OjI2PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBs YW5ndWFnZS1kYXRhPSJIaXN0b3J5U3ViamVjdFR4dCI+5Li7IOmimCDvvJo8L3N0cm9uZz48c3Bh biBjbGFzcz0ienJlYWRUaXRsZSI+PHN0cm9uZz5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWFvLXNmYy1vYW0tcGF0aC1jb25zaXN0ZW5jeS0wNC50eHQ8L3N0cm9uZz48L3NwYW4+ PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlDb250ZW50Ij48ZGl2Pjxicj5BJm5ic3A7 bmV3Jm5ic3A7dmVyc2lvbiZuYnNwO29mJm5ic3A7SS1ELCZuYnNwO2RyYWZ0LWFvLXNmYy1vYW0t cGF0aC1jb25zaXN0ZW5jeS0wNC50eHQ8YnI+aGFzJm5ic3A7YmVlbiZuYnNwO3N1Y2Nlc3NmdWxs eSZuYnNwO3N1Ym1pdHRlZCZuYnNwO2J5Jm5ic3A7VGluZyZuYnNwO0FvJm5ic3A7YW5kJm5ic3A7 cG9zdGVkJm5ic3A7dG8mbmJzcDt0aGU8YnI+SUVURiZuYnNwO3JlcG9zaXRvcnkuPGJyPjxicj5O YW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RyYWZ0 LWFvLXNmYy1vYW0tcGF0aC1jb25zaXN0ZW5jeTxicj5SZXZpc2lvbjombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDswNDxicj5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtTRkMmbmJzcDtPQU0mbmJzcDtmb3ImbmJzcDtwYXRoJm5ic3A7Y29uc2lzdGVu Y3k8YnI+RG9jdW1lbnQmbmJzcDtkYXRlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzIwMTgtMTIt Mjc8YnI+R3JvdXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7SW5kaXZpZHVhbCZuYnNwO1N1Ym1pc3Npb248YnI+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7MTE8YnI+VVJMOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hby1zZmMtb2FtLXBhdGgt Y29uc2lzdGVuY3ktMDQudHh0PGJyPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1hby1zZmMtb2FtLXBhdGgtY29uc2lzdGVuY3kvPGJyPkh0bWxpemVkOiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1hby1zZmMtb2FtLXBhdGgtY29uc2lzdGVuY3ktMDQ8YnI+SHRtbGl6ZWQ6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1hby1zZmMtb2FtLXBhdGgtY29uc2lzdGVuY3k8YnI+ RGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYW8t c2ZjLW9hbS1wYXRoLWNvbnNpc3RlbmN5LTA0PGJyPjxicj5BYnN0cmFjdDo8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7U2VydmljZSZuYnNwO0Z1bmN0aW9uJm5ic3A7Q2hhaW4mbmJzcDsoU0ZDKSZuYnNw O2RlZmluZXMmbmJzcDthbiZuYnNwO29yZGVyZWQmbmJzcDtzZXQmbmJzcDtvZiZuYnNwO3NlcnZp Y2U8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ZnVuY3Rpb25zJm5ic3A7KFNGcykmbmJzcDt0byZuYnNw O2JlJm5ic3A7YXBwbGllZCZuYnNwO3RvJm5ic3A7cGFja2V0cyZuYnNwO2FuZC9vciZuYnNwO2Zy YW1lcyZuYnNwO2FuZC9vciZuYnNwO2Zsb3dzPGJyPiZuYnNwOyZuYnNwOyZuYnNwO3NlbGVjdGVk Jm5ic3A7YXMmbmJzcDthJm5ic3A7cmVzdWx0Jm5ic3A7b2YmbmJzcDtjbGFzc2lmaWNhdGlvbi4m bmJzcDsmbmJzcDtTRkMmbmJzcDtPcGVyYXRpb24sPGJyPiZuYnNwOyZuYnNwOyZuYnNwO0FkbWlu aXN0cmF0aW9uJm5ic3A7YW5kJm5ic3A7TWFpbnRlbmFuY2UmbmJzcDtjYW4mbmJzcDttb25pdG9y Jm5ic3A7dGhlJm5ic3A7Y29udGludWl0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7U0ZDLDxicj4m bmJzcDsmbmJzcDsmbmJzcDtpLmUuLCZuYnNwO3RoYXQmbmJzcDthbGwmbmJzcDtlbGVtZW50cyZu YnNwO29mJm5ic3A7dGhlJm5ic3A7U0ZDJm5ic3A7YXJlJm5ic3A7cmVhY2hhYmxlJm5ic3A7dG8m bmJzcDtlYWNoJm5ic3A7b3RoZXImbmJzcDtpbiZuYnNwO3RoZTxicj4mbmJzcDsmbmJzcDsmbmJz cDtkb3duc3RyZWFtJm5ic3A7ZGlyZWN0aW9uLiZuYnNwOyZuYnNwO0J1dCZuYnNwO1NGQyZuYnNw O09BTSZuYnNwO211c3QmbmJzcDtzdXBwb3J0Jm5ic3A7dmVyaWZpY2F0aW9uJm5ic3A7dGhhdCZu YnNwO3RoZTxicj4mbmJzcDsmbmJzcDsmbmJzcDtvcmRlciZuYnNwO29mJm5ic3A7dHJhdmVyc2lu ZyZuYnNwO3RoZXNlJm5ic3A7U0ZzJm5ic3A7Y29ycmVzcG9uZHMmbmJzcDt0byZuYnNwO3RoZSZu YnNwO3N0YXRlJm5ic3A7ZGVmaW5lZCZuYnNwO2J5Jm5ic3A7dGhlPGJyPiZuYnNwOyZuYnNwOyZu YnNwO1NGQyZuYnNwO2NvbnRyb2wmbmJzcDtwbGFuZSZuYnNwO29yJm5ic3A7b3JjaGVzdHJhdG9y LCZuYnNwO3RoZSZuYnNwO21ldHJpYyZuYnNwO3JlZmVycmVkJm5ic3A7aW4mbmJzcDt0aGlzPGJy PiZuYnNwOyZuYnNwOyZuYnNwO2RvY3VtZW50Jm5ic3A7YXMmbmJzcDt0aGUmbmJzcDtwYXRoJm5i c3A7Y29uc2lzdGVuY3kmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO1NGQy4mbmJzcDsmbmJzcDtUaGlz Jm5ic3A7ZG9jdW1lbnQmbmJzcDtkZWZpbmVzJm5ic3A7YTxicj4mbmJzcDsmbmJzcDsmbmJzcDtu ZXcmbmJzcDtTRkMmbmJzcDtPQU0mbmJzcDttZXRob2QmbmJzcDt0byZuYnNwO3N1cHBvcnQmbmJz cDtTRkMmbmJzcDtjb25zaXN0ZW5jeSZuYnNwO2NoZWNrLCZuYnNwO2kuZS48YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7dmVyaWZpY2F0aW9uJm5ic3A7dGhhdCZuYnNwO2FsbCZuYnNwO2VsZW1lbnRzJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtnaXZlbiZuYnNwO1NGQyZuYnNwO2FyZSZuYnNwO2JlaW5nJm5i c3A7dHJhdmVyc2VkPGJyPiZuYnNwOyZuYnNwOyZuYnNwO2luJm5ic3A7dGhlJm5ic3A7ZXhwZWN0 ZWQmbmJzcDtvcmRlci48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ozxicj48YnI+PGJyPlBsZWFzZSZuYnNwO25vdGUmbmJzcDt0aGF0Jm5ic3A7aXQmbmJzcDttYXkm bmJzcDt0YWtlJm5ic3A7YSZuYnNwO2NvdXBsZSZuYnNwO29mJm5ic3A7bWludXRlcyZuYnNwO2Zy b20mbmJzcDt0aGUmbmJzcDt0aW1lJm5ic3A7b2YmbmJzcDtzdWJtaXNzaW9uPGJyPnVudGlsJm5i c3A7dGhlJm5ic3A7aHRtbGl6ZWQmbmJzcDt2ZXJzaW9uJm5ic3A7YW5kJm5ic3A7ZGlmZiZuYnNw O2FyZSZuYnNwO2F2YWlsYWJsZSZuYnNwO2F0Jm5ic3A7dG9vbHMuaWV0Zi5vcmcuPGJyPjxicj5U aGUmbmJzcDtJRVRGJm5ic3A7U2VjcmV0YXJpYXQ8YnI+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD48L2Rpdj4= --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Wed Jan 2 21:10:57 2019 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C40A81310F5; Wed, 2 Jan 2019 21:10:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> Date: Wed, 02 Jan 2019 21:10:55 -0800 Archived-At: Subject: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 05:10:56 -0000 The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state Candidate for WG Adoption (entered by Joel Halpern) The document is available at https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ Comment: This starts the WG call for adoption of this draft. Please respond to the list, indicating support for this as a work item of the working group with this document as the basis for the work, or objection to the working group adopting this item as a working group draft. The authors should confirm to the chairs and WG secretary that all IPR known to them relevant to this draft has been disclosed. The working group adoption call will last 2 weeks, ending at the end of the day on Thursday, January 17 2019 COB somewhere. Thank you, Joel From nobody Thu Jan 3 06:15:23 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6063C12D84C; Thu, 3 Jan 2019 06:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 CE8nndci6QiL; Thu, 3 Jan 2019 06:15:20 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 6508B12785F; Thu, 3 Jan 2019 06:15:20 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id y20so36955728qtm.13; Thu, 03 Jan 2019 06:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1wGveSHvtkIjesClZT8JEROypZ6j6PyVuiJyjFBbvpI=; b=mIiKgxElGTF4FwUAX4+feaSojVPhvr12VU93X/wcWVuZ99/J3e5g/JGRvx1SfXoUyF wXq5IssJI6LAjQybHgQ2555IZUPw61A7ida2rWNSbyBVHxvjuCIDVIv3/6Dax5/5iCjV /XhgqSco3gBUXsY2Y1qtiuczpNquDAgt8ALRid+pQTljd99QFzC22+RnDna6msmDNPOB fJLrehJzD6/EAJ1f7Lcuxmspb1KGxcAioDIt8BUuLnto6u31qE/70B9Af0COq8R78YBZ rHZw6A7Djhpy9XrdB5L1KwOlqMDCPNpib8rO9bWue3YARwjl28HxYMnGY/TNYsBK8fiF syrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1wGveSHvtkIjesClZT8JEROypZ6j6PyVuiJyjFBbvpI=; b=EVCGo5LE0qiuTjWPEma8P/XR8RZbcgQZbxOccNIsog9Vs+mwRkiseGpz9G0Ko5VMAh 55yvhMIXYua3iEX+6rnHx5qLlJMY8IA+g/H7IhEk9sDzgj7AcQ2p3b27FkSuKnbbwOJt ES5eJSt+aYS89Abvbf/7tWvb4d/SqytVTBdZII8dilPom3bJ7q1M9QkTxlLTCoECnl/X UhhixIIlBvQnMAnFAUEob/OFynZSkOt70cQIz0qXlOMSKpsoOmUApH6YISMNUuKdyJIq y9YWAPVwV+zdysInb98OqvoJ9Ah42GlJDqk5y4f6txQ16stSyllDN96peTsfV1t2+DN0 HIkA== X-Gm-Message-State: AJcUukcS/G6mIMAcxZrXiP8CUPzryrHJOl0Zhh3cFgMvWFL3uN6vB0ZK 1ii1m3WWHMTw5cQD+4NgRHFuiPz/ON69IK71CxGg8A== X-Google-Smtp-Source: ALg8bN4hP1a9xGb9hzahaG2RPhJ2OtNsUhaxUvAzU7DIURBorqvfr1zYEigHoBUf/6+nPe0Rz6WDVJfm1KTw3pnIVg4= X-Received: by 2002:a0c:e105:: with SMTP id w5mr46620653qvk.234.1546524919336; Thu, 03 Jan 2019 06:15:19 -0800 (PST) MIME-Version: 1.0 References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> In-Reply-To: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Thu, 3 Jan 2019 09:15:08 -0500 Message-ID: To: IETF Secretariat Cc: sfc-chairs@ietf.org, draft-eastlake-sfc-nsh-ecn-support@ietf.org, sfc@ietf.org Content-Type: multipart/alternative; boundary="0000000000007411f9057e8e646c" Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 14:15:22 -0000 --0000000000007411f9057e8e646c Content-Type: text/plain; charset="UTF-8" As a co-author, I feel that this draft is ready for WG adoption. Thanks, Andy On Thu, Jan 3, 2019 at 12:11 AM IETF Secretariat < ietf-secretariat-reply@ietf.org> wrote: > > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state > Candidate for WG Adoption (entered by Joel Halpern) > > The document is available at > https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ > > Comment: > This starts the WG call for adoption of this draft. > Please respond to the list, indicating support for this as a work item of > the > working group with this document as the basis for the work, or objection to > the working group adopting this item as a working group draft. > > The authors should confirm to the chairs and WG secretary that all IPR > known > to them relevant to this draft has been disclosed. > > The working group adoption call will last 2 weeks, ending at the end of the > day on Thursday, January 17 2019 COB somewhere. > > Thank you, > Joel > --0000000000007411f9057e8e646c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a co-author, I feel that this draft is ready for WG ado= ption.

Thanks,
Andy

=

The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state
Candidate for WG Adoption (entered by Joel Halpern)

The document is available at
https://datatracker.ietf.org/doc= /draft-eastlake-sfc-nsh-ecn-support/

Comment:
This starts the WG call for adoption of this draft.
Please respond to the list, indicating support for this as a work item of t= he
working group with this document as the basis for the work, or objection to=
the working group adopting this item as a working group draft.

The authors should confirm to the chairs and WG secretary that all IPR know= n
to them relevant to this draft has been disclosed.

The working group adoption call will last 2 weeks, ending at the end of the=
day on Thursday, January 17 2019 COB somewhere.

Thank you,
Joel
--0000000000007411f9057e8e646c-- From nobody Thu Jan 3 06:21:56 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A2D12EB11; Thu, 3 Jan 2019 06:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 TVnUwCX7NSFs; Thu, 3 Jan 2019 06:21:52 -0800 (PST) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 B65C112785F; Thu, 3 Jan 2019 06:21:52 -0800 (PST) Received: by mail-qt1-x842.google.com with SMTP id k12so36988175qtf.7; Thu, 03 Jan 2019 06:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AL7pDinqdxxYvffrlPlHuCe11fJ+4jObI/2R73UUVjQ=; b=fuWdiyDIChHMxBk0arEoN8/gElK2Tz10QSKNcwwVNKf44aLGzkrtxEuyWs8qIUDU7U nz69ZQg7vVlAIaArp6gsaLBav3t/86S5+nNylfAGHSC8xxCsqjch/CniqTWdmwg5483/ oj6wPlDIWCI4ef/wFKoBRzUcS6zzP4RGXOFbE9/ejPlgIIJRoy453rl8LZ3H6Ph9U8ul YMQjf8xzVgWS5+m4JXOMob9xFpPBMJmD5viPrB64oFhS9xnn/hUwdaUBP75da8I3HJHV 5X+CT+ZC42YRi2h1KJevKrTP/YdqE3mlFZkvJY8y/JNGGNntiqAn5x9tDlba7TbfhbTq GQ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AL7pDinqdxxYvffrlPlHuCe11fJ+4jObI/2R73UUVjQ=; b=TFRxEu9fxs2W8Gvf42W8lN4/yRm+FLkspVGkVMrsWVmquUQr1WfXLr8GCRdEj3k+mV CNihvKdyajlwJTJCLrv7ZvOd+lGFK+E6yDeudfEMDF4lEozTgGAAq/A3OYXpcPR+CrEK bNYyzySyMM9yxCFgqFa/8pXBK36PlgYJMVeAgBdb5nU6vaxzNWZn+1LLI1o69seIm2Sc qPRF9T4Nf+xr9Boqkl87lEVCYZGF7iIqmByhIAR5STttvFUlLRVhG74ky0CJl46LYGUC uqheCwLAHTNDv367JmRILjxdNpCCEVBPS0SF/SWkTKk2jxeVwE8zf0um5Parkawq7+uf iaiw== X-Gm-Message-State: AA+aEWZ6nlLssXCYtkKPyir00oV6Naw907jM9x/d/2WkuKNFIcLniYOP l25RRoAm4JPfZtwtwBxONx/E5pIGNMaC+ulXqdaKng== X-Google-Smtp-Source: AFSGD/UNWmwxdraro5afDvY1UQhrlxtq/sRdmn1YYtuoY9xvIDVfPV1jiD9FIhox0MARoRj1U/sDMTz8T6qNDdWgGqY= X-Received: by 2002:ac8:2eb8:: with SMTP id h53mr45734407qta.18.1546525311842; Thu, 03 Jan 2019 06:21:51 -0800 (PST) MIME-Version: 1.0 References: <201812280721.wBS7LLbS078487@mse02.zte.com.cn> In-Reply-To: <201812280721.wBS7LLbS078487@mse02.zte.com.cn> From: "Andrew G. Malis" Date: Thu, 3 Jan 2019 09:21:41 -0500 Message-ID: To: ao.ting@zte.com.cn Cc: cjbc@it.uc3m.es, sfc-chairs@ietf.org, draft-sfc-serviceid-header@ietf.org, IETF Secretariat , sfc@ietf.org Content-Type: multipart/alternative; boundary="000000000000d93e63057e8e7be3" Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-sfc-serviceid-header in state"Call For Adoption By WG Issued" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 14:21:55 -0000 --000000000000d93e63057e8e7be3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also support adopting the draft. Thanks, Andy On Fri, Dec 28, 2018 at 2:21 AM wrote: > +1. > > I have reviewed the draft and I support the adoption this draft. > > > Best Regards. > > Ting Ao > > > =E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6 > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A*CarlosJes=C3=BAsBernardosCano > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A*IETF Secretariat ; > sfc-chairs@ietf.org ; > draft-sfc-serviceid-header@ietf.org = ; > sfc@ietf.org ; > *=E6=97=A5 =E6=9C=9F =EF=BC=9A*2018=E5=B9=B412=E6=9C=8823=E6=97=A5 20:07 > *=E4=B8=BB =E9=A2=98 =EF=BC=9A**Re: [sfc] The SFC WG has placed draft-sfc= -serviceid-header in > state"Call For Adoption By WG Issued"* > Hi, > > I support adopting this draft. > > Carlos > > On Sun, 2018-12-16 at 18:46 -0800, IETF Secretariat wrote: > > The SFC WG has placed draft-sfc-serviceid-header in state > > Call For Adoption By WG Issued (entered by Joel Halpern) > > > > The document is available at > > https://datatracker.ietf.org/doc/draft-sfc-serviceid-header/ > > > > Comment: > > This starts a 3 week working group adoption call for "Service > > Function > > Chaining: Subscriber and Policy Identification Variable-Length > > Network > > Service Header (NSH) Context Headers" > > https://datatracker.ietf.org/doc/draft-sfc-serviceid-header/ Please > > speak up. > > Silence will NOT be taken as support. Earlier comments about the > > document, > > while appreciated, will not be taken for support. > > > > The last call will end a CoB on Monday, January 7, 2019 > > > > Thank you, > > Joel and Jim > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --000000000000d93e63057e8e7be3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also support adopting the draft.

Than= ks,
Andy


On Fri, Dec 28, 2018 at 2:21 AM <ao.ting@zte.com.cn> wrote:

+1.

I have reviewed the draft and I suppo= rt the adoption this draft.


Best Regards.

= Ting Ao


<= /div>
=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB= =B6
=E5=8F= =91=E4=BB=B6=E4=BA=BA=EF=BC=9ACarlosJes=C3=BAsBernardosCano <cjbc@it.uc3m.es>
=E6=97=A5 =E6=9C=9F = =EF=BC=9A2018=E5=B9=B412=E6=9C=8823=E6=97=A5 20:07
=E4=B8=BB =E9=A2=98 =EF=BC=9ARe: [sfc] The SFC WG has placed dr= aft-sfc-serviceid-header in state"Call For Adoption By WG Issued"=
Hi,

I=C2=A0support=C2=A0adopting=C2=A0this=C2=A0draf= t.

Carlos

On=C2=A0Sun,=C2=A02018-12-16=C2=A0at=C2=A018:46=C2= =A0-0800,=C2=A0IETF=C2=A0Secretariat=C2=A0wrote:
>=C2=A0The=C2=A0SFC= =C2=A0WG=C2=A0has=C2=A0placed=C2=A0draft-sfc-serviceid-header=C2=A0in=C2=A0= state
>=C2=A0Call=C2=A0For=C2=A0Adoption=C2=A0By=C2=A0WG=C2=A0Issued= =C2=A0(entered=C2=A0by=C2=A0Joel=C2=A0Halpern)
>=C2=A0
>=C2=A0T= he=C2=A0document=C2=A0is=C2=A0available=C2=A0at
>=C2=A0https://datatracker.ietf.org/doc/draft-sfc-serviceid-header/
>= =C2=A0
>=C2=A0Comment:
>=C2=A0This=C2=A0starts=C2=A0a=C2=A03=C2= =A0week=C2=A0working=C2=A0group=C2=A0adoption=C2=A0call=C2=A0for=C2=A0"= ;Service
>=C2=A0Function
>=C2=A0Chaining:=C2=A0Subscriber=C2=A0= and=C2=A0Policy=C2=A0Identification=C2=A0Variable-Length
>=C2=A0Netwo= rk
>=C2=A0Service=C2=A0Header=C2=A0(NSH)=C2=A0Context=C2=A0Headers&qu= ot;
>=C2=A0https://datatracker.ietf.org/doc/draft-sfc= -serviceid-header/=C2=A0Please
>=C2=A0speak=C2=A0up.
>=C2= =A0=C2=A0Silence=C2=A0will=C2=A0NOT=C2=A0be=C2=A0taken=C2=A0as=C2=A0support= .=C2=A0=C2=A0Earlier=C2=A0comments=C2=A0about=C2=A0the
>=C2=A0documen= t,
>=C2=A0while=C2=A0appreciated,=C2=A0will=C2=A0not=C2=A0be=C2=A0tak= en=C2=A0for=C2=A0support.
>=C2=A0
>=C2=A0The=C2=A0last=C2=A0cal= l=C2=A0will=C2=A0end=C2=A0a=C2=A0CoB=C2=A0on=C2=A0Monday,=C2=A0January=C2= =A07,=C2=A02019
>=C2=A0
>=C2=A0Thank=C2=A0you,
>=C2=A0Joe= l=C2=A0and=C2=A0Jim
>=C2=A0
>=C2=A0____________________________= ___________________
>=C2=A0sfc=C2=A0mailing=C2=A0list
>=C2=A0sfc@ietf.org
>=C2= =A0= https://www.ietf.org/mailman/listinfo/sfc

______________________= _________________________
sfc=C2=A0mailing=C2=A0list
sfc@ietf.org
https://www.ietf.org/mai= lman/listinfo/sfc


_= ______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--000000000000d93e63057e8e7be3-- From nobody Sun Jan 6 23:57:16 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5765130E8A; Sun, 6 Jan 2019 23:57:15 -0800 (PST) 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, FREEMAIL_FROM=0.001, 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=gmail.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 4joOINOerjCa; Sun, 6 Jan 2019 23:57:13 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 33546130E68; Sun, 6 Jan 2019 23:57:13 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id e5so46714315qtr.12; Sun, 06 Jan 2019 23:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hR7g9LmMXbK7FBMfb/q9MR4ZtEJGC0J52TqjFIKEs5s=; b=Nk7n5eBzJEToEqyiPmQc3xeGqdnAehGoE3InWnGaWTmUnYoPS1PBe7YgmB4A3yEcPN v5IEKGOjwrvPbCtpz8OUfKPrntmI2IbvwRjVJPaICvK09Z0G6zPPIMEHG8EOzDhG5wdE hO6gYIeapX+RQCB269hbOP4zHzN7/yIvN+nx9YDQcwZvbiriKzqFN/fxAi3TRNh+1sJg HM66UQgVzBBMVEiiFKkfpxMPswuDC5+/JNnufON9JgsA31HZuHUGnsm511syoRdwW6vh 5nWXq54qgrMKM2MJUiH+vqL8qAVczpWPTrnyA7uyVk2OtZQkHME6nWm5VkOC34JrruYC nCUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hR7g9LmMXbK7FBMfb/q9MR4ZtEJGC0J52TqjFIKEs5s=; b=jikt0gcgAL20W0pLTzFLsm9P5+qGh8WbIn5zpg0rcVXWiF+Ry2Uf54Hzfoq0qSS/4Z PSK/xpbvAH5JWkhaj2skmk4YYYTpoM1y8uB4PGvBCEUa97x3DNHI1kiBoRTUAChUUm0s ld0G9WKdL/XsOAYn3iQBaQtIOJt3WRGW9Rn8SFzH/76Xx0MrJoljLP09psNAx5/xrPvN Cq7mr8edtwIZ9jKae7w1hiV12ODBIyeVyJv2eDQY42oTpgF5JL3ZK608iRgRYNcKC4UA oKXsEkZsbsX0iypZvMMceHuIFbCLPza0wp+hKw3dpYrIjfSWhMXFLc6KWYUHS9/KPMEM 8f+w== X-Gm-Message-State: AA+aEWa957yQaG8nkgkrrf5fLLvKYDqYfnS5VFTDM3GFlFjTeK8P1DUt 1S2EQN1EvecGFVEERWVI4+kLWAcIGhpjCP3lBbySpoSyLWI= X-Google-Smtp-Source: AFSGD/Xc87Spn9uETVEFwuVgzW5nI90psUEmuvt8ulYp0TOdnJBMEIy0AX8gIgIj3UmJVTZVQvh5nus0spNMrwjFgTI= X-Received: by 2002:aed:33e3:: with SMTP id v90mr58070840qtd.261.1546847832109; Sun, 06 Jan 2019 23:57:12 -0800 (PST) MIME-Version: 1.0 References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> In-Reply-To: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> From: Tal Mizrahi Date: Mon, 7 Jan 2019 09:57:01 +0200 Message-ID: To: IETF Secretariat Cc: sfc-chairs@ietf.org, draft-eastlake-sfc-nsh-ecn-support@ietf.org, sfc@ietf.org Content-Type: multipart/alternative; boundary="0000000000008df8dd057ed9933c" Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 07:57:16 -0000 --0000000000008df8dd057ed9933c Content-Type: text/plain; charset="UTF-8" Hi, I reviewed the draft, and I believe it is worth pursuing in the working group. Comments: - Section 1.3 / Section 4: these sections discuss how the ingress node (classifier) may react to the congestion. However, it seems that there may be a conflict if the egress node both propagates the ECN to the destination AND sends a congestion feedback to the ingress node. In this case traffic may be throttled by two nodes (traffic source and NSH classifier). It would be helpful if the draft clarifies whether these two behaviors are mutually exclusive, or how they coexist. - The draft implies that in a network that uses ECN-in-NSH the Ingress and Egress nodes must be ECN aware, while the SFFs and SFs may be ECN unaware, allowing interoperability with older SFF/SF nodes. I would suggest to state this explicitly in the introduction. - "It MAY instead be set to ECT(1) if the NSH domain supports the experimental L4S capability [RFC8311], [ecnL4S]." This sentence is confusing from an implementer's perspective. Does the "MAY" here allow interoperability between the two approaches (RFC3168/ RFC8311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are expected to be implemented as defined in [RFC3168] or as in [RFC8311], or a combination of both. Cheers, Tal. On Thu, Jan 3, 2019 at 7:11 AM IETF Secretariat < ietf-secretariat-reply@ietf.org> wrote: > > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state > Candidate for WG Adoption (entered by Joel Halpern) > > The document is available at > https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ > > Comment: > This starts the WG call for adoption of this draft. > Please respond to the list, indicating support for this as a work item of > the > working group with this document as the basis for the work, or objection to > the working group adopting this item as a working group draft. > > The authors should confirm to the chairs and WG secretary that all IPR > known > to them relevant to this draft has been disclosed. > > The working group adoption call will last 2 weeks, ending at the end of the > day on Thursday, January 17 2019 COB somewhere. > > Thank you, > Joel > --0000000000008df8dd057ed9933c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I revie= wed the draft, and I believe it is worth pursuing in the working group.

Comments:

- Section 1.3 / Se= ction 4: these sections discuss how the ingress node (classifier) may react= to the congestion. However, it seems that there may be a conflict if the e= gress node both propagates the ECN to the destination AND sends a congestio= n feedback to the ingress node. In this case traffic may be throttled by tw= o nodes (traffic source and NSH classifier). It would be helpful if the dra= ft clarifies whether these two behaviors are mutually exclusive, or how the= y coexist.

- The draft implies that in a network t= hat uses ECN-in-NSH the Ingress and Egress nodes must be ECN aware, while t= he SFFs and SFs may be ECN unaware, allowing interoperability with older SF= F/SF nodes. I would suggest to state this explicitly in the introduction.

- "It MAY instead be set to ECT(1) if the NSH = domain supports the experimental L4S capability [RFC8311], [ecnL4S]."<= /div>
=C2=A0 This sentence is confusing from an implementer's persp= ective. Does the "MAY" here allow interoperability between the tw= o approaches (RFC3168/ RFC8311)? Please clarify in the draft whether ECN-in= -NSH-aware nodes are expected to be implemented as defined in [RFC3168] or = as in [RFC8311], or a combination of both.=C2=A0

C= heers,
Tal.

On Thu, Jan 3, 2019 at 7:11 AM IETF Secretariat <ietf-secretariat-reply@ietf.org= > wrote:

The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state
Candidate for WG Adoption (entered by Joel Halpern)

The document is available at
https://datatracker.ietf.org/doc= /draft-eastlake-sfc-nsh-ecn-support/

Comment:
This starts the WG call for adoption of this draft.
Please respond to the list, indicating support for this as a work item of t= he
working group with this document as the basis for the work, or objection to=
the working group adopting this item as a working group draft.

The authors should confirm to the chairs and WG secretary that all IPR know= n
to them relevant to this draft has been disclosed.

The working group adoption call will last 2 weeks, ending at the end of the=
day on Thursday, January 17 2019 COB somewhere.

Thank you,
Joel
--0000000000008df8dd057ed9933c-- From nobody Mon Jan 7 13:55:57 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9811B12DDA3; Mon, 7 Jan 2019 13:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telefonica.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 D23UtqqHQNud; Mon, 7 Jan 2019 13:55:50 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB0912D4F0; Mon, 7 Jan 2019 13:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o5yqCrFnvUvMhUaREptzMlZb7jUrXhbliTy2aFE077o=; b=OVlSIOUl4+1wAyDLvXu+5CIl8WmS/y2h9R/N27vRU4UzDPcc6HBNj0lswLcTwKk7fJ6RGUnZxO9EAJ9RRnTycEcmfp8cDgB1oU8aU1SbcMONkj5Vd13n32DqZdtF4HNvZ8H39jk5tVvaCDes0SMo1ncrQIEFLYdnarhNcvAWZ8g= Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com (52.134.70.148) by DB3PR0602MB3739.eurprd06.prod.outlook.com (52.134.71.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.7; Mon, 7 Jan 2019 21:55:48 +0000 Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::f5d1:7904:ce83:c841]) by DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::f5d1:7904:ce83:c841%2]) with mapi id 15.20.1495.011; Mon, 7 Jan 2019 21:55:48 +0000 From: "Diego R. Lopez" To: IETF Secretariat , "sfc-chairs@ietf.org" , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" Thread-Index: AQHUoyK8tretySRROk2urprnkJo896WkE5OA Date: Mon, 7 Jan 2019 21:55:47 +0000 Message-ID: <6CC35C03-7EDC-4019-B032-FDE04B795D5C@telefonica.com> References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> In-Reply-To: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.5.181209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [80.155.25.210] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0602MB3739; 6:prGR2RhU54wle0z6XYLObLTT/01BlSf4thWDrRZKcL+FiIPBrtLVf7tyc8ebkjerkaFjVbLt9DxU5Li1FcoUfsRdRDdQqQP6YU0PiMw2KIB+i+4g8gxC8+2FgYvqu9S9Jk7Vaf+hEX+XyQMYf3z2qRVwCbhl10lG4K/XihCQgvwm3JuS6PGzz7QnAGWFG+3cxAr2jIo2xoo1GzR7XxZUkTscF2/X8ztHQXJVL/pjR6vEjcV2LNJBPR75eonnJG+KziMk0q4LEfi56gBbEJEdlVr76A/vXBF0/IZObFOEs7vA/eS5HoLujBZI3JuzySOLkDKt3cbnTlM7Rru5EZoiSLdi7Gaiif+eq8NmD+pDy9IhQM1UfnGfZrdBnfNekCwmlTzp4nHiYBo0LRUtFjAxCpN2OeoLpR9BfW7UD4+/KSc+vByC5/aDsAKZcc3jaVcau0DmWfwQu73Ptzm2XfNztw==; 5:k/mJL0nxWUKxxktIkkEB4fNzTcKq7v68Q7A7zcQOuzZiNtHThtySHgP4UY28wqVkGtGxyAaKMO5Z0/UPXxC920SUFpV0Egh61TQmHdz4FenZl/w0tDcxkVhQXwSGYGsM1uuqQNq1+9B/Js4Sq2IDTMzoKyC3lX1ZrFbVhwjikTfSBYNntTLZr/6v/iMzTcyNizGjJdkw/1FHiLRFc2ha4A==; 7:pB20CjOuvPyztImUhcx9xfZwO82YjpIsi5ZNJumvzPzn3OUJ/Aizo0FdCJEIDPv1pkaiMeww5znzk7ft6UBtaFoUVQ7N1wcqqgUYaIkck2w2EB9H+1sjKcN+bdNV7oxMNKCHXsI7r2VhWCf8mP3Dig== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ed3d746e-b852-4efa-4394-08d674eae1e5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB3PR0602MB3739; x-ms-traffictypediagnostic: DB3PR0602MB3739: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(93006095)(93001095)(3231475)(944501520)(52105112)(10201501046)(3002001)(6055026)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(201702281529075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB3PR0602MB3739; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0602MB3739; x-forefront-prvs: 0910AAF391 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(396003)(346002)(366004)(39860400002)(40134004)(189003)(199004)(83716004)(71190400001)(71200400001)(6436002)(5660300001)(229853002)(8676002)(486006)(8936002)(26005)(2616005)(6116002)(36756003)(82746002)(6486002)(186003)(76176011)(81166006)(81156014)(68736007)(6506007)(2201001)(45080400002)(110136005)(3846002)(446003)(33656002)(11346002)(478600001)(99286004)(14444005)(25786009)(2501003)(106356001)(7736002)(6512007)(6306002)(86362001)(786003)(105586002)(102836004)(66066001)(305945005)(256004)(966005)(66574012)(14454004)(2906002)(6246003)(58126008)(53936002)(316002)(450100002)(476003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR0602MB3739; H:DB3PR0602MB3788.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TRaQOGbKsF/Op5bTPXxs+Djcs6RWCtHP4UTiVEVF7Xru40nnrFN+9r8sQz+kOta+3zC1I05kV+MMqO/QHo69pJ3aXV31ZKu6U+pwinQD4Q5vyKIqSP6ihuJm4KKUPzqEE5CXSz32tLZi5SGhmrSiPU+fb5wFTQ8FR93B8ZjSelGmwW0yok5E9EwMy2C6iSgELaQ1TrOBdbq9y3zUgtgSzn/2212KpYoUWfU/uPTFLOKZt62FxKI5sokysKZaIrNF+78VDtxKfJrYgVWFfEZrAQ2zqfyc9xj6/sYwLIKvgLSfn52XpdhhdGhB8eKGn5r1 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <42B9532B3757BF4D9BACEEFC1B0C17C6@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed3d746e-b852-4efa-4394-08d674eae1e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2019 21:55:47.9601 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0602MB3739 Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 21:55:55 -0000 SGksDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC4gQ29uZ2VzdGlvbiBt YW5hZ2VtZW50IGlzIGFuIGVzc2VudGlhbCBmZWF0dXJlIGluIHRoZSBOU0ggZnJhbWV3b3JrLg0K DQpCZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVy bm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cHM6Ly93d3cubGlu a2VkaW4uY29tL2luL2RyMmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmlj YS5jb20NClRlbDogICAgICAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogICszNCA2ODIgMDUx IDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrvu79PbiAwMy8wMS8y MDE5LCAwNjoxMSwgInNmYyBvbiBiZWhhbGYgb2YgSUVURiBTZWNyZXRhcmlhdCIgPHNmYy1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpZXRmLXNlY3JldGFyaWF0LXJlcGx5QGlldGYub3Jn PiB3cm90ZToNCg0KDQogICAgVGhlIFNGQyBXRyBoYXMgcGxhY2VkIGRyYWZ0LWVhc3RsYWtlLXNm Yy1uc2gtZWNuLXN1cHBvcnQgaW4gc3RhdGUNCiAgICBDYW5kaWRhdGUgZm9yIFdHIEFkb3B0aW9u IChlbnRlcmVkIGJ5IEpvZWwgSGFscGVybikNCg0KICAgIFRoZSBkb2N1bWVudCBpcyBhdmFpbGFi bGUgYXQNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1lYXN0bGFr ZS1zZmMtbnNoLWVjbi1zdXBwb3J0Lw0KDQogICAgQ29tbWVudDoNCiAgICBUaGlzIHN0YXJ0cyB0 aGUgV0cgY2FsbCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC4NCiAgICBQbGVhc2UgcmVzcG9u ZCB0byB0aGUgbGlzdCwgaW5kaWNhdGluZyBzdXBwb3J0IGZvciB0aGlzIGFzIGEgd29yayBpdGVt IG9mIHRoZQ0KICAgIHdvcmtpbmcgZ3JvdXAgd2l0aCB0aGlzIGRvY3VtZW50IGFzIHRoZSBiYXNp cyBmb3IgdGhlIHdvcmssIG9yIG9iamVjdGlvbiB0bw0KICAgIHRoZSB3b3JraW5nIGdyb3VwIGFk b3B0aW5nIHRoaXMgaXRlbSBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuDQoNCiAgICBUaGUgYXV0 aG9ycyBzaG91bGQgY29uZmlybSB0byB0aGUgY2hhaXJzIGFuZCBXRyBzZWNyZXRhcnkgdGhhdCBh bGwgSVBSIGtub3duDQogICAgdG8gdGhlbSByZWxldmFudCB0byB0aGlzIGRyYWZ0IGhhcyBiZWVu IGRpc2Nsb3NlZC4NCg0KICAgIFRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGNhbGwgd2lsbCBs YXN0IDIgd2Vla3MsIGVuZGluZyBhdCB0aGUgZW5kIG9mIHRoZQ0KICAgIGRheSBvbiBUaHVyc2Rh eSwgSmFudWFyeSAxNyAyMDE5IENPQiBzb21ld2hlcmUuDQoNCiAgICBUaGFuayB5b3UsDQogICAg Sm9lbA0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICBzZmMgbWFpbGluZyBsaXN0DQogICAgc2ZjQGlldGYub3JnDQogICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2Vu IGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1h Y2nDs24gcHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZv IGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBk ZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEs IHV0aWxpemFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBw dWVkZSBlc3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRl LiBTaSBoYSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBu b3MgbG8gY29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9j ZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBu YW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu YXRpb24sIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lv biBpbiBlcnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0 aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVy cm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNl IGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVy IGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28g ZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZv c3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRl IHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNl bSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xh w6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9z LWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlh IGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== From nobody Tue Jan 8 13:43:52 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6263B13119A; Tue, 8 Jan 2019 13:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 CQl2FErUb52P; Tue, 8 Jan 2019 13:43:50 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 0F63F131199; Tue, 8 Jan 2019 13:43:50 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id m19so4388143ioh.3; Tue, 08 Jan 2019 13:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ym+lGuhPtceZic2HeJnwOJ6hBgbeVdepGc3ij3P351o=; b=arGyM63FVXvtvXvnJKZYkt2qZSSG27ZmMS3C7l/Ahheo4Vtw1wYxi7DkSAPmI82fIb Ts2YxKWG2o1z238OsXCrj8fVKzISxKI53wYvHP0Va6dArZ1FSe1PdnSZCmRneRUqZf2I 59XzF5rkXsJzUQln1syCNiowTfK+wzeoyh0V1mfopXc3oVs135Dkjr5dHH3dVptJDIRY LVv/J1TulrHund/joOqJkus4whlTbUr3AsQxsj5zMc+duQdq0jqtW1AunRT17FbyFXEF an3Kn5sQ3aDV0Sv7ptKjFuNZr75eDoQbI1+nstxZMVDAnjhrl/xLxgnoSkyOYp+LykiU 9J0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ym+lGuhPtceZic2HeJnwOJ6hBgbeVdepGc3ij3P351o=; b=YwjehcRlyULYB3DCFFGxK4uq9j4V9SPeeXvE5jvXfdA2GRB86zIm36mgf8vhTw05qc kaLs4L01rSS2FkuETF23FNjgHSGIb6Gp4xOcEVDcoSbtpEWV6+QV0ke3RqKou0Te5f0x IWF4k62to/SnH+a6mEG+BKMGDVtbK6EmKNqgvOgk/lPFxyl7sWFmZ3WoLhs/upU8Uo2N PlydLDF7WUmse/ayVWu624BO1gQGZGhxYrgsPZz0Ll5/SrOgoGPkwxukPpEMAlG2e72t spfn3TXo3/fwBDNAmy26TTuFnNvgCn5TtFY3X8GIX7t6Vr0NEaKxRJ1RrTnUn3QTxPc5 axrA== X-Gm-Message-State: AJcUukfXix/HRUlvrwB8nN1DpjGOvpH8qMbNWCKxU4tk9wrmU4+QR2o/ 5uJjjujk6J+0mQ2AJcgtRIf4MBBKZrFue1dSTzDoR21GKBc= X-Google-Smtp-Source: ALg8bN6ZGna4jp5MwMqwMKByu1sugQhpQpjI5/59fVlWbtXiHRjJBuLzF3Ye/du/6DZksweMiTF1QC9mdoa6IXBdDqc= X-Received: by 2002:a5d:88ce:: with SMTP id i14mr2481164iol.66.1546983829191; Tue, 08 Jan 2019 13:43:49 -0800 (PST) MIME-Version: 1.0 References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> In-Reply-To: From: Donald Eastlake Date: Tue, 8 Jan 2019 16:43:37 -0500 Message-ID: To: Tal Mizrahi Cc: IETF Secretariat , sfc-chairs@ietf.org, draft-eastlake-sfc-nsh-ecn-support@ietf.org, sfc@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 21:43:51 -0000 Hi Tal, On Mon, Jan 7, 2019 at 2:57 AM Tal Mizrahi wrot= e: > > Hi, > > I reviewed the draft, and I believe it is worth pursuing in the working g= roup. Thanks for the support. > Comments: > > - Section 1.3 / Section 4: these sections discuss how the ingress node (c= lassifier) may react to the congestion. However, it seems that there may be= a conflict if the egress node both propagates the ECN to the destination A= ND sends a congestion feedback to the ingress node. In this case traffic ma= y be throttled by two nodes (traffic source and NSH classifier). It would b= e helpful if the draft clarifies whether these two behaviors are mutually e= xclusive, or how they coexist. That is a reasonable consideration and the draft should probably talk about it. I think some actions by the NSH classifier could cause problems but there are other NSH classifier actions that would be OK. > - The draft implies that in a network that uses ECN-in-NSH the Ingress an= d Egress nodes must be ECN aware, while the SFFs and SFs may be ECN unaware= , allowing interoperability with older SFF/SF nodes. I would suggest to sta= te this explicitly in the introduction. OK. > - "It MAY instead be set to ECT(1) if the NSH domain supports the experim= ental L4S capability [RFC8311], [ecnL4S]." > This sentence is confusing from an implementer's perspective. Does the = "MAY" here allow interoperability between the two approaches (RFC3168/ RFC8= 311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are expect= ed to be implemented as defined in [RFC3168] or as in [RFC8311], or a combi= nation of both. I agree we need to clarify that. Thanks, Donald =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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com > Cheers, > Tal. > > On Thu, Jan 3, 2019 at 7:11 AM IETF Secretariat wrote: >> >> >> The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state >> Candidate for WG Adoption (entered by Joel Halpern) >> >> The document is available at >> https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ >> >> Comment: >> This starts the WG call for adoption of this draft. >> Please respond to the list, indicating support for this as a work item o= f the >> working group with this document as the basis for the work, or objection= to >> the working group adopting this item as a working group draft. >> >> The authors should confirm to the chairs and WG secretary that all IPR k= nown >> to them relevant to this draft has been disclosed. >> >> The working group adoption call will last 2 weeks, ending at the end of = the >> day on Thursday, January 17 2019 COB somewhere. >> >> Thank you, >> Joel From nobody Fri Jan 11 07:31:05 2019 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41147124BE5; Fri, 11 Jan 2019 07:30:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154722065925.21834.10425174390527888475@ietfa.amsl.com> Date: Fri, 11 Jan 2019 07:30:59 -0800 Archived-At: Subject: [sfc] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to RFC 7665 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2019 15:30:59 -0000 Dear Joel M. Halpern, Carlos Pignataro: An IPR disclosure that pertains to your RFC entitled "Service Function Chaining (SFC) Architecture" (RFC7665) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3382/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 7665" Thank you IETF Secretariat From nobody Mon Jan 14 00:09:32 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C360130F9A; Mon, 14 Jan 2019 00:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VmOuJPtEQ1jn; Mon, 14 Jan 2019 00:09:28 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 827E5130ED4; Mon, 14 Jan 2019 00:09:28 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C8907E3141FC718BB9BB; Mon, 14 Jan 2019 08:09:26 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 14 Jan 2019 08:09:26 +0000 Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0415.000; Mon, 14 Jan 2019 16:09:20 +0800 From: Mach Chen To: "sfc-chairs@ietf.org" , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" Thread-Index: AQHUoyLFv5WA01WlSkW3MX57Ud3gkqWuenag Date: Mon, 14 Jan 2019 08:09:19 +0000 Message-ID: References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> In-Reply-To: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 08:09:30 -0000 Yes/support. Best regards, Mach > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of IETF Secretariat > Sent: Thursday, January 03, 2019 1:11 PM > To: sfc-chairs@ietf.org; draft-eastlake-sfc-nsh-ecn-support@ietf.org; > sfc@ietf.org > Subject: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support i= n > state "Candidate for WG Adoption" >=20 >=20 > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state > Candidate for WG Adoption (entered by Joel Halpern) >=20 > The document is available at > https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ >=20 > Comment: > This starts the WG call for adoption of this draft. > Please respond to the list, indicating support for this as a work item of= the > working group with this document as the basis for the work, or objection = to > the working group adopting this item as a working group draft. >=20 > The authors should confirm to the chairs and WG secretary that all IPR kn= own > to them relevant to this draft has been disclosed. >=20 > The working group adoption call will last 2 weeks, ending at the end of t= he > day on Thursday, January 17 2019 COB somewhere. >=20 > Thank you, > Joel >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jan 14 07:52:25 2019 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2941310F2; Mon, 14 Jan 2019 07:52:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <154748114344.4755.4784751223318539423@ietfa.amsl.com> Date: Mon, 14 Jan 2019 07:52:23 -0800 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-serviceid-header-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 15:52:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Service Function Chaining: Subscriber and Policy Identification Variable-Length Network Service Header (NSH) Context Headers Authors : Mohamed Boucadair Dirk von Hugo Behcet Sarikaya Filename : draft-ietf-sfc-serviceid-header-00.txt Pages : 9 Date : 2019-01-14 Abstract: This document discusses how to inform Service Functions about subscriber- and service-related information for the sake of policy enforcement and appropriate service function chaining operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sfc-serviceid-header-00 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-serviceid-header-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 Tue Jan 15 14:53:32 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBDF130F1F; Tue, 15 Jan 2019 14:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9eWYLb0KeVd; Tue, 15 Jan 2019 14:53:27 -0800 (PST) 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 E2EFD127598; Tue, 15 Jan 2019 14:53:26 -0800 (PST) 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=AepkGPFN0DypkiFeETQcnn8oHn18vsrRm/KlXIvJWuo=; b=LLBWDdITocjGxUOFAyO3PCQBz gylXqW4mDUcxIpFW6Wwhk/J/LwdFegrkxPol56jpB5ulVY7l95/hV28hDoutVktBq9jAE4dmwMKLR Xshoscxt5hChC24hR6f9aSuz/6dcVdlhf5//X0v9tL6hv+NedSargKMaOcpqWMXMaMjRzYgcTkfBm cInrWLr1Hrvr5EYMRlhP+IVrmYMSiRTi2LDLHQDPojkO9p7SVqjeWf9qAfn/odCng3FIJQXQHXZ0b KRAlZHVxCIXsGzxwjRbJM9a0cAHT2/nFWv0dJaLv6PlPfAXKpvByQMxs+iC7YBLKLzCE40k/KZzDK uLPhxDO0A==; Received: from 35.0.208.46.dyn.plus.net ([46.208.0.35]:58330 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gjXaF-0003dC-KR; Tue, 15 Jan 2019 22:53:24 +0000 To: Donald Eastlake , Tal Mizrahi Cc: IETF Secretariat , sfc-chairs@ietf.org, draft-eastlake-sfc-nsh-ecn-support@ietf.org, sfc@ietf.org References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> From: Bob Briscoe Message-ID: <4f7963fc-0157-8587-eeb5-48d63a3de7f8@bobbriscoe.net> Date: Tue, 15 Jan 2019 22:53:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E6819EA495549B4E2C925F01" 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: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 22:53:31 -0000 This is a multi-part message in MIME format. --------------E6819EA495549B4E2C925F01 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Tal, Following up on Donald's responses as a co-author,... On 08/01/2019 21:43, Donald Eastlake wrote: > Hi Tal, > > On Mon, Jan 7, 2019 at 2:57 AM Tal Mizrahi wrote: >> Hi, >> >> I reviewed the draft, and I believe it is worth pursuing in the working group. > Thanks for the support. > >> Comments: >> >> - Section 1.3 / Section 4: these sections discuss how the ingress node (classifier) may react to the congestion. However, it seems that there may be a conflict if the egress node both propagates the ECN to the destination AND sends a congestion feedback to the ingress node. In this case traffic may be throttled by two nodes (traffic source and NSH classifier). It would be helpful if the draft clarifies whether these two behaviors are mutually exclusive, or how they coexist. > That is a reasonable consideration and the draft should probably talk > about it. I think some actions by the NSH classifier could cause > problems but there are other NSH classifier actions that would be OK. [BB] We've started covered to cover this in Section 1.3 , where we list and discuss the three types of action at the domain ingress that would be reasonable in response to congestion. However, I agree this isn't sufficient to address your concern, so it would also be useful to say what type of ingress action would /not/ be appropriate. Perhaps adding the following text to the note after the 3 bullets (subject to agreement by co-authors): "Any action by the ingress to reduce congestion needs to allow sufficient time for the end-to-end congestion control loop to respond first, for instance by the ingress taking a smoothed average of the level of congestion signalled by feedback from the tunnel egress." I can also reassure you for each specific case that we suggest: 1. Policing: Policing based on congestion feedback is intended to take over if the load is unresponsive to congestion signalling forwarded towards the receiver. Therefore, if the end-to-end congestion control is doing its job, policing-based on congestion feedback should do nothing. So the two ought not to conflict. Congestion-based policing should only intervene if congestion becomes excessive. [Note that this is not the same as a rate policer (which doesn't need congestion feedback - it can see the rate locally, so it can police to a rate without feedback about congestion from other nodes). Typically, rate policing conservatively limits everyone's rates to limit the possibility of congestion downstream. The idea of congestion policing is that you don't need to police rates - you only police if the sum of all the traffic at any node exceeds capacity (and if the end-systems don't respond to the congestion themselves).] 2. Upstream congestion feedback: I believe this is a sub-case of congestion-based-policing (1), where the ingress passes its signals to some other node that does the policing on its behalf. 3. Re-direction: Traffic engineering is definitely a case where it has to move slowly, which gives time for the end-system congestion controls to respond. We already have a point about taking care to avoid flap, etc. But I think being more specific with the extra words above can only help. > >> - The draft implies that in a network that uses ECN-in-NSH the Ingress and Egress nodes must be ECN aware, while the SFFs and SFs may be ECN unaware, allowing interoperability with older SFF/SF nodes. I would suggest to state this explicitly in the introduction. > OK. > >> - "It MAY instead be set to ECT(1) if the NSH domain supports the experimental L4S capability [RFC8311], [ecnL4S]." >> This sentence is confusing from an implementer's perspective. Does the "MAY" here allow interoperability between the two approaches (RFC3168/ RFC8311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are expected to be implemented as defined in [RFC3168] or as in [RFC8311], or a combination of both. > I agree we need to clarify that. Let me get back to you on this one. I have to admit that I can't remember why we catered for L4S in the way written around table 2. I've checked back, and I actually wrote this part myself, but it looks wrong to me, which would be embarrassing. However, I need to check with my co-authors to confirm that. Whatever, thanks for picking this up. Bob > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > >> Cheers, >> Tal. >> >> On Thu, Jan 3, 2019 at 7:11 AM IETF Secretariat wrote: >>> >>> The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state >>> Candidate for WG Adoption (entered by Joel Halpern) >>> >>> The document is available at >>> https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ >>> >>> Comment: >>> This starts the WG call for adoption of this draft. >>> Please respond to the list, indicating support for this as a work item of the >>> working group with this document as the basis for the work, or objection to >>> the working group adopting this item as a working group draft. >>> >>> The authors should confirm to the chairs and WG secretary that all IPR known >>> to them relevant to this draft has been disclosed. >>> >>> The working group adoption call will last 2 weeks, ending at the end of the >>> day on Thursday, January 17 2019 COB somewhere. >>> >>> Thank you, >>> Joel -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------E6819EA495549B4E2C925F01 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Tal,

Following up on Donald's responses as a co-author,...

On 08/01/2019 21:43, Donald Eastlake wrote:
Hi Tal,

On Mon, Jan 7, 2019 at 2:57 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:

Hi,

I reviewed the draft, and I believe it is worth pursuing in the working group.

Thanks for the support.


Comments:

- Section 1.3 / Section 4: these sections discuss how the ingress node (classifier) may react to the congestion. However, it seems that there may be a conflict if the egress node both propagates the ECN to the destination AND sends a congestion feedback to the ingress node. In this case traffic may be throttled by two nodes (traffic source and NSH classifier). It would be helpful if the draft clarifies whether these two behaviors are mutually exclusive, or how they coexist.

That is a reasonable consideration and the draft should probably talk
about it. I think some actions by the NSH classifier could cause
problems but there are other NSH classifier actions that would be OK.
[BB] We've started covered to cover this in Section 1.3, where we list and discuss the three types of action at the domain ingress that would be reasonable in response to congestion. However, I agree this isn't sufficient to address your concern, so it would also be useful to say what type of ingress action would /not/ be appropriate. Perhaps adding the following text to the note after the 3 bullets (subject to agreement by co-authors):

"Any action by the ingress to reduce congestion needs to allow sufficient time for the end-to-end congestion control loop to respond first, for instance by the ingress taking a smoothed average of the level of congestion signalled by feedback from the tunnel egress."
I can also reassure you for each specific case that we suggest:
  1. Policing: Policing based on congestion feedback is intended to take over if the load is unresponsive to congestion signalling forwarded towards the receiver. Therefore, if the end-to-end congestion control is doing its job, policing-based on congestion feedback should do nothing. So the two ought not to conflict. Congestion-based policing should only intervene if congestion becomes excessive.

    [Note that this is not the same as a rate policer (which doesn't need congestion feedback - it can see the rate locally, so it can police to a rate without feedback about congestion from other nodes). Typically, rate policing conservatively limits everyone's rates to limit the possibility of congestion downstream. The idea of congestion policing is that you don't need to police rates - you only police if the sum of all the traffic at any node exceeds capacity (and if the end-systems don't respond to the congestion themselves).]

  2. Upstream congestion feedback: I believe this is a sub-case of congestion-based-policing (1), where the ingress passes its signals to some other node that does the policing on its behalf.

  3. Re-direction: Traffic engineering is definitely a case where it has to move slowly, which gives time for the end-system congestion controls to respond. We already have a point about taking care to avoid flap, etc. But I think being more specific with the extra words above can only help.

- The draft implies that in a network that uses ECN-in-NSH the Ingress and Egress nodes must be ECN aware, while the SFFs and SFs may be ECN unaware, allowing interoperability with older SFF/SF nodes. I would suggest to state this explicitly in the introduction.

OK.


- "It MAY instead be set to ECT(1) if the NSH domain supports the experimental L4S capability [RFC8311], [ecnL4S]."
  This sentence is confusing from an implementer's perspective. Does the "MAY" here allow interoperability between the two approaches (RFC3168/ RFC8311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are expected to be implemented as defined in [RFC3168] or as in [RFC8311], or a combination of both.

I agree we need to clarify that.
Let me get back to you on this one. I have to admit that I can't remember why we catered for L4S in the way written around table 2. I've checked back, and I actually wrote this part myself, but it looks wrong to me, which would be embarrassing. However, I need to check with my co-authors to confirm that.

Whatever, thanks for picking this up.


Bob


Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com


Cheers,
Tal.

On Thu, Jan 3, 2019 at 7:11 AM IETF Secretariat <ietf-secretariat-reply@ietf.org> wrote:


The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state
Candidate for WG Adoption (entered by Joel Halpern)

The document is available at
https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/

Comment:
This starts the WG call for adoption of this draft.
Please respond to the list, indicating support for this as a work item of the
working group with this document as the basis for the work, or objection to
the working group adopting this item as a working group draft.

The authors should confirm to the chairs and WG secretary that all IPR known
to them relevant to this draft has been disclosed.

The working group adoption call will last 2 weeks, ending at the end of the
day on Thursday, January 17 2019 COB somewhere.

Thank you,
Joel


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------E6819EA495549B4E2C925F01-- From nobody Thu Jan 17 06:12:44 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461BB128CB7; Thu, 17 Jan 2019 06:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 bqtSWSAmKBjG; Thu, 17 Jan 2019 06:12:40 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671B7130EA3; Thu, 17 Jan 2019 06:12:40 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 43gQyG75fKz4wFK; Thu, 17 Jan 2019 15:12:38 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 43gQyG5vxBzDq78; Thu, 17 Jan 2019 15:12:38 +0100 (CET) Received: from OPEXCAUBM8F.corporate.adroot.infra.ftgroup (10.114.13.107) by OPEXCLILM32.corporate.adroot.infra.ftgroup (10.114.31.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Jan 2019 15:12:38 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0415.000; Thu, 17 Jan 2019 15:12:38 +0100 From: To: IETF Secretariat , "sfc-chairs@ietf.org" , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" Thread-Index: AQHUoyK7AP7W2v1e202zdcW0+LgwT6WzknSw Date: Thu, 17 Jan 2019 14:12:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> In-Reply-To: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 14:12:42 -0000 Hi all,=20 I do think that ECN is naturally better handled at the transport encapsulat= ion instead of the NSH itself.=20 Requiring the functionality to be handled at the transport encap (draft-iet= f-tsvwg-rfc6040update-shim) and NSH is redundant, IMO. I like the approach we set in the SFC architecture in which we separated se= rvice matters from transport ones. I'd vote for maintaining that separation= cleaner as it was set in the arch RFC. Thank you. =20 Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de IETF Secretariat > Envoy=E9=A0: jeudi 3 janvier 2019 06:11 > =C0=A0: sfc-chairs@ietf.org; draft-eastlake-sfc-nsh-ecn-support@ietf.org; > sfc@ietf.org > Objet=A0: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support = in > state "Candidate for WG Adoption" >=20 >=20 > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state > Candidate for WG Adoption (entered by Joel Halpern) >=20 > The document is available at > https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ >=20 > Comment: > This starts the WG call for adoption of this draft. > Please respond to the list, indicating support for this as a work item of= the > working group with this document as the basis for the work, or objection = to > the working group adopting this item as a working group draft. >=20 > The authors should confirm to the chairs and WG secretary that all IPR kn= own > to them relevant to this draft has been disclosed. >=20 > The working group adoption call will last 2 weeks, ending at the end of t= he > day on Thursday, January 17 2019 COB somewhere. >=20 > Thank you, > Joel >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Jan 17 06:49:50 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B46D1277CC; Thu, 17 Jan 2019 06:49:48 -0800 (PST) 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, FREEMAIL_FROM=0.001, 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=gmail.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 WK3z2cecKmtf; Thu, 17 Jan 2019 06:49:45 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 AAC181276D0; Thu, 17 Jan 2019 06:49:45 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id t13so11567831qtn.3; Thu, 17 Jan 2019 06:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eL9nwV6LGCisEe2P3E756kDzKMNeLN15m3n5VIXTI0A=; b=ep2UO49DVQlvJO+bv2CafrandefMAwjmPMfASlfVegrLIniK0xL2F7KYtGB2J0eksV vhC/sCycHJkndlPjCPbUFtiK6lAb3J6coCKdQhG5GZc1p0fCV4DvzjW5VseeNcTFEQ3C sldcKuNOQ4Llks4bpYEH62/T4xTbyCbsOM2j8NinseKCMuHqDEhYsqAil1aM1MVESU0z mM6eFVRbxAldePTiVm85ELozMrqXTCaPBAzIQGKdogHvTlm5j+E3C/IkHE7mk2l+6DXO qxE9qnPto/mEMquMT6KBrv9JKOBINuEnbW1xkuTqKqCvFbZSXKiZrUUrsfBNrQzys7QP VLcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eL9nwV6LGCisEe2P3E756kDzKMNeLN15m3n5VIXTI0A=; b=c47zLJfyNNxGOukyqLuvRN94WIgkOKE63jtz2pHBilwl3Md7aRPL1sfta0heE2a8jr DptD16F0ql36B3ZAgM4AnQf08IZ8xedu8m7gltMAy7nGWxwP1YtGSHTBvbILwSGb6AOB ZuFH3o7b62gMwEug9/hDpZWw7M7fMHLRJCmkwIq/DLZ370vo5AwaLQPA9F96Qr4DkaUH HPrEpvPP1UWsr+35YQ91aO+c7rcgxUGVy6p2QhZrsVohbiawl3kmuN7pPvPUgRxRJKlv AYKu6auV7Y9qJS+wJUBMaFLCNhJVsCaoGUQG/AKtwqfKYGaDFP0oVqlgGYE4zaeBi5UK I5wQ== X-Gm-Message-State: AJcUukcQShjjob9/oWQoFT3Y+WQ064NpA3wFiumUEmncevEzviER8awQ 0XOQgnPxpFvZBbYBfMw/Jrswlr0ik5dZY5n6HxY= X-Google-Smtp-Source: ALg8bN4QnKsxSYbVs9Mbk0sJBZLJLXkAerD0+th82gFYhPulay1urEkIo+IcIrnlID1PV6y9Gto+vGUNSjlZcK5rNpA= X-Received: by 2002:a0c:878d:: with SMTP id 13mr11476674qvj.8.1547736584671; Thu, 17 Jan 2019 06:49:44 -0800 (PST) MIME-Version: 1.0 References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Andrew G. Malis" Date: Thu, 17 Jan 2019 09:49:33 -0500 Message-ID: To: "BOUCADAIR Mohamed IMT/OLN" Cc: IETF Secretariat , "sfc-chairs@ietf.org" , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000055d691057fa881e6" Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 14:49:49 -0000 --00000000000055d691057fa881e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Med, Not all transports support ECN marking, for example NSH over MPLS. And even where the transport supports ECN marking, note the example in Figure 1 in the draft where the outer encapsulation can be stripped during SFF processing. In that case, the scope of the ECN marking is limited to individual SFF-SFF links. rather than end-to-end. Cheers, Andy On Thu, Jan 17, 2019 at 9:12 AM wrote: > Hi all, > > I do think that ECN is naturally better handled at the transport > encapsulation instead of the NSH itself. > > Requiring the functionality to be handled at the transport encap > (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redundant, IMO. > > I like the approach we set in the SFC architecture in which we separated > service matters from transport ones. I'd vote for maintaining that > separation cleaner as it was set in the arch RFC. > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : sfc [mailto:sfc-bounces@ietf.org] De la part de IETF Secretariat > > Envoy=C3=A9 : jeudi 3 janvier 2019 06:11 > > =C3=80 : sfc-chairs@ietf.org; draft-eastlake-sfc-nsh-ecn-support@ietf.o= rg; > > sfc@ietf.org > > Objet : [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support = in > > state "Candidate for WG Adoption" > > > > > > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state > > Candidate for WG Adoption (entered by Joel Halpern) > > > > The document is available at > > https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ > > > > Comment: > > This starts the WG call for adoption of this draft. > > Please respond to the list, indicating support for this as a work item > of the > > working group with this document as the basis for the work, or objectio= n > to > > the working group adopting this item as a working group draft. > > > > The authors should confirm to the chairs and WG secretary that all IPR > known > > to them relevant to this draft has been disclosed. > > > > The working group adoption call will last 2 weeks, ending at the end of > the > > day on Thursday, January 17 2019 COB somewhere. > > > > Thank you, > > Joel > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > --00000000000055d691057fa881e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Med,

Not all transports support ECN mar= king, for example NSH over MPLS.

And even where th= e transport supports ECN marking, note the example in Figure 1 in the draft= where the outer encapsulation can be stripped during SFF processing. In th= at case, the scope of the ECN marking is limited to individual SFF-SFF link= s. rather than end-to-end.

Cheers,
Andy<= /div>


O= n Thu, Jan 17, 2019 at 9:12 AM <mohamed.boucadair@orange.com> wrote:
Hi all,

I do think that ECN is naturally better handled at the transport encapsulat= ion instead of the NSH itself.

Requiring the functionality to be handled at the transport encap (draft-iet= f-tsvwg-rfc6040update-shim) and NSH is redundant, IMO.

I like the approach we set in the SFC architecture in which we separated se= rvice matters from transport ones. I'd vote for maintaining that separa= tion cleaner as it was set in the arch RFC.

Thank you.=C2=A0

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de IETF Secretariat
> Envoy=C3=A9=C2=A0: jeudi 3 janvier 2019 06:11
> =C3=80=C2=A0: sfc-chairs@ietf.org; draft-eastlake-sfc-nsh-ecn-support@ietf.org= ;
> sfc@ietf.org
> Objet=C2=A0: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-su= pport in
> state "Candidate for WG Adoption"
>
>
> The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state
> Candidate for WG Adoption (entered by Joel Halpern)
>
> The document is available at
> https://datatracker.ietf.or= g/doc/draft-eastlake-sfc-nsh-ecn-support/
>
> Comment:
> This starts the WG call for adoption of this draft.
> Please respond to the list, indicating support for this as a work item= of the
> working group with this document as the basis for the work, or objecti= on to
> the working group adopting this item as a working group draft.
>
> The authors should confirm to the chairs and WG secretary that all IPR= known
> to them relevant to this draft has been disclosed.
>
> The working group adoption call will last 2 weeks, ending at the end o= f the
> day on Thursday, January 17 2019 COB somewhere.
>
> Thank you,
> Joel
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
--00000000000055d691057fa881e6-- From nobody Thu Jan 17 07:02:13 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1530D1276D0; Thu, 17 Jan 2019 07:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 LL4iYU_HnjiI; Thu, 17 Jan 2019 07:02:03 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E3812896A; Thu, 17 Jan 2019 07:02:03 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 43gS3G20Ncz1y24; Thu, 17 Jan 2019 16:02:02 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 43gS3G12sFzDq7T; Thu, 17 Jan 2019 16:02:02 +0100 (CET) Received: from OPEXCAUBMA3.corporate.adroot.infra.ftgroup (10.114.13.64) by OPEXCLILM24.corporate.adroot.infra.ftgroup (10.114.31.17) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Jan 2019 16:02:02 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([fe80::90fe:7dc1:fb15:a02b%21]) with mapi id 14.03.0415.000; Thu, 17 Jan 2019 16:02:01 +0100 From: To: "Andrew G. Malis" CC: IETF Secretariat , "sfc-chairs@ietf.org" , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" Thread-Index: AQHUrnPkanVNkfk0u0me6dUnyAOrwqWzjbOQ Date: Thu, 17 Jan 2019 15:02:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA095B8OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 15:02:11 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EA095B8OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IEFu ZHJldyBHLiBNYWxpcyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29tXQ0KRW52b3nDqSA6IGpldWRp IDE3IGphbnZpZXIgMjAxOSAxNTo1MA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQpD YyA6IElFVEYgU2VjcmV0YXJpYXQ7IHNmYy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWVhc3RsYWtl LXNmYy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KT2JqZXQgOiBSZTog W3NmY10gVGhlIFNGQyBXRyBoYXMgcGxhY2VkIGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1 cHBvcnQgaW4gc3RhdGUgIkNhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb24iDQoNCk1lZCwNCg0KTm90 IGFsbCB0cmFuc3BvcnRzIHN1cHBvcnQgRUNOIG1hcmtpbmcsIGZvciBleGFtcGxlIE5TSCBvdmVy IE1QTFMuDQpbTWVkXSBJc27igJl0IHRoaXMgY292ZXJlZCBieSBSRkM1MTI5Pw0KDQpBbmQgZXZl biB3aGVyZSB0aGUgdHJhbnNwb3J0IHN1cHBvcnRzIEVDTiBtYXJraW5nLCBub3RlIHRoZSBleGFt cGxlIGluIEZpZ3VyZSAxIGluIHRoZSBkcmFmdCB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlv biBjYW4gYmUgc3RyaXBwZWQgZHVyaW5nIFNGRiBwcm9jZXNzaW5nLiBJbiB0aGF0IGNhc2UsIHRo ZSBzY29wZSBvZiB0aGUgRUNOIG1hcmtpbmcgaXMgbGltaXRlZCB0byBpbmRpdmlkdWFsIFNGRi1T RkYgbGlua3MuIHJhdGhlciB0aGFuIGVuZC10by1lbmQuDQoNCltNZWRdIFdoeSBjb3VsZG7igJl0 IFNGRiBwcmVzZXJ2ZSBFQ04gd2hlbiBkb2luZyBpdHMgdHJhbnNwb3J0IGRlY2FwL2VuY2FwPw0K DQoNCkNoZWVycywNCkFuZHkNCg0KDQpPbiBUaHUsIEphbiAxNywgMjAxOSBhdCA5OjEyIEFNIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPj4gd3JvdGU6DQpIaSBhbGwsDQoNCkkgZG8gdGhpbmsgdGhhdCBFQ04gaXMgbmF0dXJh bGx5IGJldHRlciBoYW5kbGVkIGF0IHRoZSB0cmFuc3BvcnQgZW5jYXBzdWxhdGlvbiBpbnN0ZWFk IG9mIHRoZSBOU0ggaXRzZWxmLg0KDQpSZXF1aXJpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgdG8gYmUg aGFuZGxlZCBhdCB0aGUgdHJhbnNwb3J0IGVuY2FwIChkcmFmdC1pZXRmLXRzdndnLXJmYzYwNDB1 cGRhdGUtc2hpbSkgYW5kIE5TSCBpcyByZWR1bmRhbnQsIElNTy4NCg0KSSBsaWtlIHRoZSBhcHBy b2FjaCB3ZSBzZXQgaW4gdGhlIFNGQyBhcmNoaXRlY3R1cmUgaW4gd2hpY2ggd2Ugc2VwYXJhdGVk IHNlcnZpY2UgbWF0dGVycyBmcm9tIHRyYW5zcG9ydCBvbmVzLiBJJ2Qgdm90ZSBmb3IgbWFpbnRh aW5pbmcgdGhhdCBzZXBhcmF0aW9uIGNsZWFuZXIgYXMgaXQgd2FzIHNldCBpbiB0aGUgYXJjaCBS RkMuDQoNClRoYW5rIHlvdS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+IERlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnPl0gRGUgbGEgcGFydCBkZSBJRVRGIFNlY3JldGFyaWF0DQo+ IEVudm95w6kgOiBqZXVkaSAzIGphbnZpZXIgMjAxOSAwNjoxMQ0KPiDDgCA6IHNmYy1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOnNmYy1jaGFpcnNAaWV0Zi5vcmc+OyBkcmFmdC1lYXN0bGFrZS1zZmMt bnNoLWVjbi1zdXBwb3J0QGlldGYub3JnPG1haWx0bzpkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVj bi1zdXBwb3J0QGlldGYub3JnPjsNCj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+IE9iamV0IDogW3NmY10gVGhlIFNGQyBXRyBoYXMgcGxhY2VkIGRyYWZ0LWVhc3RsYWtlLXNm Yy1uc2gtZWNuLXN1cHBvcnQgaW4NCj4gc3RhdGUgIkNhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb24i DQo+DQo+DQo+IFRoZSBTRkMgV0cgaGFzIHBsYWNlZCBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVj bi1zdXBwb3J0IGluIHN0YXRlDQo+IENhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb24gKGVudGVyZWQg YnkgSm9lbCBIYWxwZXJuKQ0KPg0KPiBUaGUgZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGF0DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNu LXN1cHBvcnQvDQo+DQo+IENvbW1lbnQ6DQo+IFRoaXMgc3RhcnRzIHRoZSBXRyBjYWxsIGZvciBh ZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KPiBQbGVhc2UgcmVzcG9uZCB0byB0aGUgbGlzdCwgaW5k aWNhdGluZyBzdXBwb3J0IGZvciB0aGlzIGFzIGEgd29yayBpdGVtIG9mIHRoZQ0KPiB3b3JraW5n IGdyb3VwIHdpdGggdGhpcyBkb2N1bWVudCBhcyB0aGUgYmFzaXMgZm9yIHRoZSB3b3JrLCBvciBv YmplY3Rpb24gdG8NCj4gdGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpbmcgdGhpcyBpdGVtIGFzIGEg d29ya2luZyBncm91cCBkcmFmdC4NCj4NCj4gVGhlIGF1dGhvcnMgc2hvdWxkIGNvbmZpcm0gdG8g dGhlIGNoYWlycyBhbmQgV0cgc2VjcmV0YXJ5IHRoYXQgYWxsIElQUiBrbm93bg0KPiB0byB0aGVt IHJlbGV2YW50IHRvIHRoaXMgZHJhZnQgaGFzIGJlZW4gZGlzY2xvc2VkLg0KPg0KPiBUaGUgd29y a2luZyBncm91cCBhZG9wdGlvbiBjYWxsIHdpbGwgbGFzdCAyIHdlZWtzLCBlbmRpbmcgYXQgdGhl IGVuZCBvZiB0aGUNCj4gZGF5IG9uIFRodXJzZGF5LCBKYW51YXJ5IDE3IDIwMTkgQ09CIHNvbWV3 aGVyZS4NCj4NCj4gVGhhbmsgeW91LA0KPiBKb2VsDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo= --_000_787AE7BB302AE849A7480A190F8B93302EA095B8OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIEFuZHksJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5QbGVhc2Ugc2VlIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmRy ZXcgRy4gTWFsaXMgW21haWx0bzphZ21hbGlzQGdtYWlsLmNvbV0NCjxicj4NCjxiPkVudm95w6km bmJzcDs6PC9iPiBqZXVkaSAxNyBqYW52aWVyIDIwMTkgMTU6NTA8YnI+DQo8Yj7DgCZuYnNwOzo8 L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IElFVEYg U2VjcmV0YXJpYXQ7IHNmYy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gt ZWNuLXN1cHBvcnRAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7Ojwv Yj4gUmU6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNlZCBkcmFmdC1lYXN0bGFrZS1zZmMtbnNo LWVjbi1zdXBwb3J0IGluIHN0YXRlICZxdW90O0NhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb24mcXVv dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TWVkLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IGFs bCB0cmFuc3BvcnRzIHN1cHBvcnQgRUNOIG1hcmtpbmcsIGZvciBleGFtcGxlIE5TSCBvdmVyIE1Q TFMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIElzbuKAmXQgdGhpcyBjb3ZlcmVkIGJ5IFJGQzUxMjk/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBldmVuIHdoZXJlIHRoZSB0cmFuc3Bv cnQgc3VwcG9ydHMgRUNOIG1hcmtpbmcsIG5vdGUgdGhlIGV4YW1wbGUgaW4gRmlndXJlIDEgaW4g dGhlIGRyYWZ0IHdoZXJlIHRoZSBvdXRlciBlbmNhcHN1bGF0aW9uIGNhbiBiZSBzdHJpcHBlZCBk dXJpbmcgU0ZGIHByb2Nlc3NpbmcuIEluIHRoYXQgY2FzZSwgdGhlIHNjb3BlIG9mIHRoZSBFQ04g bWFya2luZyBpcyBsaW1pdGVkIHRvIGluZGl2aWR1YWwgU0ZGLVNGRg0KIGxpbmtzLiByYXRoZXIg dGhhbiBlbmQtdG8tZW5kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gV2h5 IGNvdWxkbuKAmXQgU0ZGIHByZXNlcnZlIEVDTiB3aGVuIGRvaW5nIGl0cyB0cmFuc3BvcnQgZGVj YXAvZW5jYXA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSmFuIDE3LCAyMDE5IGF0IDk6MTIgQU0gJmx0Ozxh IGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsIDxicj4NCjxicj4NCkkgZG8g dGhpbmsgdGhhdCBFQ04gaXMgbmF0dXJhbGx5IGJldHRlciBoYW5kbGVkIGF0IHRoZSB0cmFuc3Bv cnQgZW5jYXBzdWxhdGlvbiBpbnN0ZWFkIG9mIHRoZSBOU0ggaXRzZWxmLg0KPGJyPg0KPGJyPg0K UmVxdWlyaW5nIHRoZSBmdW5jdGlvbmFsaXR5IHRvIGJlIGhhbmRsZWQgYXQgdGhlIHRyYW5zcG9y dCBlbmNhcCAoZHJhZnQtaWV0Zi10c3Z3Zy1yZmM2MDQwdXBkYXRlLXNoaW0pIGFuZCBOU0ggaXMg cmVkdW5kYW50LCBJTU8uPGJyPg0KPGJyPg0KSSBsaWtlIHRoZSBhcHByb2FjaCB3ZSBzZXQgaW4g dGhlIFNGQyBhcmNoaXRlY3R1cmUgaW4gd2hpY2ggd2Ugc2VwYXJhdGVkIHNlcnZpY2UgbWF0dGVy cyBmcm9tIHRyYW5zcG9ydCBvbmVzLiBJJ2Qgdm90ZSBmb3IgbWFpbnRhaW5pbmcgdGhhdCBzZXBh cmF0aW9uIGNsZWFuZXIgYXMgaXQgd2FzIHNldCBpbiB0aGUgYXJjaCBSRkMuPGJyPg0KPGJyPg0K VGhhbmsgeW91LiZuYnNwOyA8YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KTWVkPGJyPg0KPGJyPg0K Jmd0OyAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQomZ3Q7IERlJm5ic3A7OiBzZmMg W21haWx0bzo8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIERlIGxhIHBhcnQgZGUgSUVURiBTZWNyZXRh cmlhdDxicj4NCiZndDsgRW52b3nDqSZuYnNwOzogamV1ZGkgMyBqYW52aWVyIDIwMTkgMDY6MTE8 YnI+DQomZ3Q7IMOAJm5ic3A7OiA8YSBocmVmPSJtYWlsdG86c2ZjLWNoYWlyc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNmYy1jaGFpcnNAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRv OmRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5kcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnPC9hPjs8YnI+ DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmNA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBPYmpldCZuYnNwOzogW3NmY10gVGhlIFNGQyBXRyBoYXMg cGxhY2VkIGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnQgaW48YnI+DQomZ3Q7IHN0 YXRlICZxdW90O0NhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb24mcXVvdDs8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyBUaGUgU0ZDIFdHIGhhcyBwbGFjZWQgZHJhZnQtZWFzdGxha2Utc2Zj LW5zaC1lY24tc3VwcG9ydCBpbiBzdGF0ZTxicj4NCiZndDsgQ2FuZGlkYXRlIGZvciBXRyBBZG9w dGlvbiAoZW50ZXJlZCBieSBKb2VsIEhhbHBlcm4pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBk b2N1bWVudCBpcyBhdmFpbGFibGUgYXQ8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnQvIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1l YXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0LzwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgQ29t bWVudDo8YnI+DQomZ3Q7IFRoaXMgc3RhcnRzIHRoZSBXRyBjYWxsIGZvciBhZG9wdGlvbiBvZiB0 aGlzIGRyYWZ0Ljxicj4NCiZndDsgUGxlYXNlIHJlc3BvbmQgdG8gdGhlIGxpc3QsIGluZGljYXRp bmcgc3VwcG9ydCBmb3IgdGhpcyBhcyBhIHdvcmsgaXRlbSBvZiB0aGU8YnI+DQomZ3Q7IHdvcmtp bmcgZ3JvdXAgd2l0aCB0aGlzIGRvY3VtZW50IGFzIHRoZSBiYXNpcyBmb3IgdGhlIHdvcmssIG9y IG9iamVjdGlvbiB0bzxicj4NCiZndDsgdGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpbmcgdGhpcyBp dGVtIGFzIGEgd29ya2luZyBncm91cCBkcmFmdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGF1 dGhvcnMgc2hvdWxkIGNvbmZpcm0gdG8gdGhlIGNoYWlycyBhbmQgV0cgc2VjcmV0YXJ5IHRoYXQg YWxsIElQUiBrbm93bjxicj4NCiZndDsgdG8gdGhlbSByZWxldmFudCB0byB0aGlzIGRyYWZ0IGhh cyBiZWVuIGRpc2Nsb3NlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIHdvcmtpbmcgZ3JvdXAg YWRvcHRpb24gY2FsbCB3aWxsIGxhc3QgMiB3ZWVrcywgZW5kaW5nIGF0IHRoZSBlbmQgb2YgdGhl PGJyPg0KJmd0OyBkYXkgb24gVGh1cnNkYXksIEphbnVhcnkgMTcgMjAxOSBDT0Igc29tZXdoZXJl Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFuayB5b3UsPGJyPg0KJmd0OyBKb2VsPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86 c2ZjQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsg PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93302EA095B8OPEXCAUBMA2corp_-- From nobody Thu Jan 17 07:33:45 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE2B130DEF; Thu, 17 Jan 2019 07:33:43 -0800 (PST) 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, FREEMAIL_FROM=0.001, 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=gmail.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 NzFJJR5YVBOy; Thu, 17 Jan 2019 07:33:40 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 A532B130DEA; Thu, 17 Jan 2019 07:33:40 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id l11so11797865qtp.0; Thu, 17 Jan 2019 07:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V1l/DJmqFQNOCoS1GZtQSQXnUNTcOOZVQwlIVup77YI=; b=V8v1tBhQDdhcJjVm78aCGn3Ko0qfou/hw8dum/BUzvFqrEER5IG0mPOFPnyxP9z9H5 t9tTefUbpj8ck47znYZ6Jf1f03HMwQ3TxCmiU8e7uN7pCuE3yV7L/Pv+C9q6RW3xHQTO oQYUl7vY38hsobswtlZFkaSX9iOnfzc41ngJHZmCe4gk8CSzhdqT96ytTT4wRMNqQQUd zrUlhAA+bYlepcki/3g+FQwicXXARc9un87tWSR18SM9Nk4Ayvl02zhxzQvqrAJBHeCY XCQ58MIq/cf8sactQYeBjYT1qVe5ji3pbpqW5WzQVkZh2ChTUkIQe8Y+bI6gTjQL2YB3 +tww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V1l/DJmqFQNOCoS1GZtQSQXnUNTcOOZVQwlIVup77YI=; b=i2DDJN4oAj8bKtxBP7dqnLVt1QtQDv8lBOwRJpry4bef5Qlls6LNzOUWKHeH7Xzaqe ZJmI/tT2qiEbE1MeG9rlHrqH9OeqfspAE3V0vGjTHuDrwQq+65wV4wcOo8WuZ1sVRshB lHoHW4nPbLNs7J4GlAE2gN1i7l4reo+VgAJn7LC0uluVKW8mzhIVybZWl9jLV1xKUo2l 02hyJ0c/76cyM7FtgFnoVqaZVgjwTNNN8yL45jGv2xDw9f9/l5xFiXg0Lvg7QkB88KBk +EtPu++nInggWLny2OkedKMauXLTroPSGsmQBllxaemdv7lhYw0MzrEFZEmBTWIbpLXJ WFRA== X-Gm-Message-State: AJcUukftVNewJUwx0KL587a5FnWd6RKEJ1AmIHzo/6LzZWVjtAemuohO R9WQHjFd+HfovbPk4zfIcmCjzj2EK0JzpggNzg4tsQ== X-Google-Smtp-Source: ALg8bN6W32lYe95vhvKxCOt+hftAJYnadJ8/xcZ8TjKeXFPIwoRX5zQsYJFbuoq9ZF9L9vNqfM+IhX5Qi5gAwyTfkCE= X-Received: by 2002:a0c:c389:: with SMTP id o9mr11834746qvi.90.1547739219465; Thu, 17 Jan 2019 07:33:39 -0800 (PST) MIME-Version: 1.0 References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Andrew G. Malis" Date: Thu, 17 Jan 2019 10:33:28 -0500 Message-ID: To: "BOUCADAIR Mohamed IMT/OLN" Cc: IETF Secretariat , "sfc-chairs@ietf.org" , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000619b5a057fa91ed4" Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 15:33:44 -0000 --000000000000619b5a057fa91ed4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Med, Your point about RFC 5129 is correct, but I'm not personally aware of any implementations. And I was just using MPLS as an example, there may be others in the future as well. Your point about the SFF preserving ECN is implementation dependent, for example the SFF could have separate input and output interfaces without shared memory, or the transport encapsulation could change in different regions of the SFC domain. It's difficult to depend on SFFs being able to preserve transport-header-dependent information without that becoming a requirement in the SFC architecture. Cheers, Andy On Thu, Jan 17, 2019 at 10:02 AM wrote: > Hi Andy, > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* Andrew G. Malis [mailto:agmalis@gmail.com] > *Envoy=C3=A9 :* jeudi 17 janvier 2019 15:50 > *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > *Cc :* IETF Secretariat; sfc-chairs@ietf.org; > draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > *Objet :* Re: [sfc] The SFC WG has placed > draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" > > > > Med, > > > > Not all transports support ECN marking, for example NSH over MPLS. > > [Med] Isn=E2=80=99t this covered by RFC5129? > > > > And even where the transport supports ECN marking, note the example in > Figure 1 in the draft where the outer encapsulation can be stripped durin= g > SFF processing. In that case, the scope of the ECN marking is limited to > individual SFF-SFF links. rather than end-to-end. > > > > [Med] Why couldn=E2=80=99t SFF preserve ECN when doing its transport deca= p/encap? > > > > > > Cheers, > > Andy > > > > > > On Thu, Jan 17, 2019 at 9:12 AM wrote: > > Hi all, > > I do think that ECN is naturally better handled at the transport > encapsulation instead of the NSH itself. > > Requiring the functionality to be handled at the transport encap > (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redundant, IMO. > > I like the approach we set in the SFC architecture in which we separated > service matters from transport ones. I'd vote for maintaining that > separation cleaner as it was set in the arch RFC. > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : sfc [mailto:sfc-bounces@ietf.org] De la part de IETF Secretariat > > Envoy=C3=A9 : jeudi 3 janvier 2019 06:11 > > =C3=80 : sfc-chairs@ietf.org; draft-eastlake-sfc-nsh-ecn-support@ietf.o= rg; > > sfc@ietf.org > > Objet : [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support = in > > state "Candidate for WG Adoption" > > > > > > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state > > Candidate for WG Adoption (entered by Joel Halpern) > > > > The document is available at > > https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ > > > > Comment: > > This starts the WG call for adoption of this draft. > > Please respond to the list, indicating support for this as a work item > of the > > working group with this document as the basis for the work, or objectio= n > to > > the working group adopting this item as a working group draft. > > > > The authors should confirm to the chairs and WG secretary that all IPR > known > > to them relevant to this draft has been disclosed. > > > > The working group adoption call will last 2 weeks, ending at the end of > the > > day on Thursday, January 17 2019 COB somewhere. > > > > Thank you, > > Joel > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > --000000000000619b5a057fa91ed4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Med,

Your point about RFC 5129 is corre= ct, but I'm not personally aware of any implementations. And I was just= using MPLS as an example, there may be others in the future as well.
=

Your point about the SFF preserving ECN is implementati= on dependent, for example the SFF could have separate input and output inte= rfaces without shared memory, or the transport encapsulation could change i= n different regions of the SFC domain. It's difficult to depend on SFFs= being able to preserve transport-header-dependent information without that= becoming a requirement in the SFC architecture.

C= heers,
Andy


On Thu, Jan 17, 2019 at 10:02 AM <mohamed.boucadair@orange.com> wrote:<= br>

Hi Andy,=C2=A0

=C2=A0

Please see inline.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Andrew G. Malis [mailto:agmalis@gmail.com]
Envoy=C3=A9=C2=A0: jeudi 17 janvier 2019 15:50
=C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN
Cc=C2=A0: IETF Secretariat; sfc-chairs@ietf.org; draft-eastlake-sfc-nsh-ecn-= support@ietf.org; sfc= @ietf.org
Objet=C2=A0: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-= ecn-support in state "Candidate for WG Adoption"

=C2=A0

Med,

=C2=A0

Not all transports support ECN marking, for example = NSH over MPLS.

[Med] Isn=E2=80=99t this covered = by RFC5129?

=C2=A0

And even where the transport supports ECN marking, n= ote the example in Figure 1 in the draft where the outer encapsulation can = be stripped during SFF processing. In that case, the scope of the ECN marki= ng is limited to individual SFF-SFF links. rather than end-to-end.

=C2=A0

[Med] Why couldn=E2=80=99t SFF pr= eserve ECN when doing its transport decap/encap?

=C2=A0

=C2=A0

Cheers,

Andy

=C2=A0

=C2=A0

On Thu, Jan 17, 2019 at 9:12 AM <mohamed.boucadair@orange.= com> wrote:

Hi all,

I do think that ECN is naturally better handled at the transport encapsulat= ion instead of the NSH itself.

Requiring the functionality to be handled at the transport encap (draft-iet= f-tsvwg-rfc6040update-shim) and NSH is redundant, IMO.

I like the approach we set in the SFC architecture in which we separated se= rvice matters from transport ones. I'd vote for maintaining that separa= tion cleaner as it was set in the arch RFC.

Thank you.=C2=A0

Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de IETF Secretariat
> Envoy=C3=A9=C2=A0: jeudi 3 janvier 2019 06:11
> =C3=80=C2=A0: sfc-chairs@ietf.org; draft-eastlake-sfc-nsh-ecn-support@ietf.org;
> sfc@ietf.org
> Objet=C2=A0: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-su= pport in
> state "Candidate for WG Adoption"
>
>
> The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state
> Candidate for WG Adoption (entered by Joel Halpern)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ >
> Comment:
> This starts the WG call for adoption of this draft.
> Please respond to the list, indicating support for this as a work item= of the
> working group with this document as the basis for the work, or objecti= on to
> the working group adopting this item as a working group draft.
>
> The authors should confirm to the chairs and WG secretary that all IPR= known
> to them relevant to this draft has been disclosed.
>
> The working group adoption call will last 2 weeks, ending at the end o= f the
> day on Thursday, January 17 2019 COB somewhere.
>
> Thank you,
> Joel
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc

--000000000000619b5a057fa91ed4-- From nobody Fri Jan 18 01:15:45 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1229131190; Fri, 18 Jan 2019 01:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 h4ye22Z4j34V; Fri, 18 Jan 2019 01:15:39 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA691311C6; Fri, 18 Jan 2019 01:15:38 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 43gwK36pFkz1yMQ; Fri, 18 Jan 2019 10:15:35 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 43gwK35DMKzDq7V; Fri, 18 Jan 2019 10:15:35 +0100 (CET) Received: from OPEXCAUBM31.corporate.adroot.infra.ftgroup (10.114.13.26) by OPEXCLILM7E.corporate.adroot.infra.ftgroup (10.114.31.61) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 18 Jan 2019 10:15:35 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([fe80::34b6:11d0:147f:6560%21]) with mapi id 14.03.0415.000; Fri, 18 Jan 2019 10:15:35 +0100 From: To: "Andrew G. Malis" CC: "sfc-chairs@ietf.org" , IETF Secretariat , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" Thread-Index: AQHUrnoPE7kvArC/bUuvyP7DLY325KW0uhAQ Date: Fri, 18 Jan 2019 09:15:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA0A2A3OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 09:15:43 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EA0A2A3OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEFuZHJldyBHLiBN YWxpcw0KRW52b3nDqSA6IGpldWRpIDE3IGphbnZpZXIgMjAxOSAxNjozMw0Kw4AgOiBCT1VDQURB SVIgTW9oYW1lZCBUR0kvT0xODQpDYyA6IHNmYy1jaGFpcnNAaWV0Zi5vcmc7IElFVEYgU2VjcmV0 YXJpYXQ7IGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmc7IHNmY0Bp ZXRmLm9yZw0KT2JqZXQgOiBSZTogW3NmY10gVGhlIFNGQyBXRyBoYXMgcGxhY2VkIGRyYWZ0LWVh c3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnQgaW4gc3RhdGUgIkNhbmRpZGF0ZSBmb3IgV0cgQWRv cHRpb24iDQoNCk1lZCwNCg0KWW91ciBwb2ludCBhYm91dCBSRkMgNTEyOSBpcyBjb3JyZWN0LCBi dXQgSSdtIG5vdCBwZXJzb25hbGx5IGF3YXJlIG9mIGFueSBpbXBsZW1lbnRhdGlvbnMuIEFuZCBJ IHdhcyBqdXN0IHVzaW5nIE1QTFMgYXMgYW4gZXhhbXBsZSwgdGhlcmUgbWF5IGJlIG90aGVycyBp biB0aGUgZnV0dXJlIGFzIHdlbGwuDQoNCltNZWRdIEkgdW5kZXJzdG9vZCB0aGlzIHdhcyBhbiBl eGFtcGxlLCBidXQgc3RpbGwgdGhpcyBpcyBJTUhPIHN1cHBvc2VkIHRvIGJlIGhhbmRsZWQgYW1v bmcgdGhlIHNwaXJpdCBvZiB0aGUgZWZmb3J0IGxlZCBieSBCb2IgaW4gNjA0MCBhbmQgaXRzIGN1 cnJlbnQgJiBmdXR1cmVzIHVwZGF0ZXMuDQoNCllvdXIgcG9pbnQgYWJvdXQgdGhlIFNGRiBwcmVz ZXJ2aW5nIEVDTiBpcyBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQsIGZvciBleGFtcGxlIHRoZSBT RkYgY291bGQgaGF2ZSBzZXBhcmF0ZSBpbnB1dCBhbmQgb3V0cHV0IGludGVyZmFjZXMgd2l0aG91 dCBzaGFyZWQgbWVtb3J5LCBvciB0aGUgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24gY291bGQgY2hh bmdlIGluIGRpZmZlcmVudCByZWdpb25zIG9mIHRoZSBTRkMgZG9tYWluLg0KDQpbTWVkXSBJIGRv buKAmXQgdW5kZXJzdGFuZCB5b3VyIHBvaW50IGFib3V0IHNlcGFyYXRlIGlucHV0cy9vdXRwdXQg aW50ZXJmYWNlcyBhbmQgdGhlIGNoYW5nZSBvZiBlbmNhcCBzY2hlbWVzLiBMZXTigJlzIHB1dCBh c2lkZSBTRkMgZm9yIGEgbW9tZW50IGFuZCBjb25zaWRlciB0aGUgZXhhbXBsZSBvZiBhIExJU1Ag WFRSIHdoaWNoIGlzIHN1cHBvcnRpbmcgRUNOIGRpc3NlbWluYXRpb24vaGFuZGxpbmcuIFRoYXQg eFRSIG1heSBub3QgdXNlIHRoZSBzYW1lIGluL291dCBpbnRlcmZhY2VzLCBidXQgc3RpbGwgbmVl ZCB0byBhY2hpZXZlIHNvbWUgcHJvY2Vzc2luZyB3aGVuIGRvaW5nIGl0cyBlbmNhcC9kZWNhcC4N Cg0KSXQncyBkaWZmaWN1bHQgdG8gZGVwZW5kIG9uIFNGRnMgYmVpbmcgYWJsZSB0byBwcmVzZXJ2 ZSB0cmFuc3BvcnQtaGVhZGVyLWRlcGVuZGVudCBpbmZvcm1hdGlvbiB3aXRob3V0IHRoYXQgYmVj b21pbmcgYSByZXF1aXJlbWVudCBpbiB0aGUgU0ZDIGFyY2hpdGVjdHVyZS4NCg0KW01lZF0gSSBk b27igJl0IHRoaW5rIHRoYXQgd2UgY2FuIHRhZyBjb25nZXN0aW9uIG5vdGlmaWNhdGlvbiBhcyDi gJx0cmFuc3BvcnQtaGVhZGVyLWRlcGVuZGVudOKAnS4gVGhlcmUgYXJlIHdheXMgdG8gcGFzcyB0 aGF0IGluZm8gZXZlbiB3aGVuIHRoZSB0cmFuc3BvcnQgZW5jYXAgY2hhbmdlcy4NClRoaXMgaXMg SU1ITyBhbW9uZyB0aGluZ3MgdGhhdCB0aGUgV0cgaXMgc3VwcG9zZWQgdG8gY292ZXIgdW5kZXIg dGhpcyBpdGVtIGluIHRoZSBjaGFydGVyIChwbGVhc2Ugbm90ZSB0aGF0IHRob3NlIGFyZSBjbGVh cmluZyB0YWdlZCBhcyB0cmFuc3BvcnQgaXNzdWVzKToNCg0KPT0NCjQpIFRyYW5zcG9ydCBDb25z aWRlcmF0aW9ucyAtIFRoaXMgd2lsbCBjYXB0dXJlIHRoZSBleHBlY3RhdGlvbnMgU0ZDIHBsYWNl cyBvbiB0cmFuc3BvcnQgYmVoYXZpb3IsIGluY2x1ZGluZyBkZWFsaW5nIHdpdGggaXNzdWVzIHN1 Y2ggYXMgY29uZ2VzdGlvbiBpbmRpY2F0aW9ucyBhbmQgcmVzcG9uc2VzLg0KPT0NCg0KDQpDaGVl cnMsDQpBbmR5DQoNCg0KT24gVGh1LCBKYW4gMTcsIDIwMTkgYXQgMTA6MDIgQU0gPG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+ PiB3cm90ZToNCkhpIEFuZHksDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQN Cg0KRGUgOiBBbmRyZXcgRy4gTWFsaXMgW21haWx0bzphZ21hbGlzQGdtYWlsLmNvbTxtYWlsdG86 YWdtYWxpc0BnbWFpbC5jb20+XQ0KRW52b3nDqSA6IGpldWRpIDE3IGphbnZpZXIgMjAxOSAxNTo1 MA0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQpDYyA6IElFVEYgU2VjcmV0YXJpYXQ7 IHNmYy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1jaGFpcnNAaWV0Zi5vcmc+OyBkcmFmdC1l YXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnPG1haWx0bzpkcmFmdC1lYXN0bGFr ZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnPjsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbc2ZjXSBUaGUgU0ZDIFdHIGhhcyBwbGFjZWQgZHJhZnQt ZWFzdGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydCBpbiBzdGF0ZSAiQ2FuZGlkYXRlIGZvciBXRyBB ZG9wdGlvbiINCg0KTWVkLA0KDQpOb3QgYWxsIHRyYW5zcG9ydHMgc3VwcG9ydCBFQ04gbWFya2lu ZywgZm9yIGV4YW1wbGUgTlNIIG92ZXIgTVBMUy4NCltNZWRdIElzbuKAmXQgdGhpcyBjb3ZlcmVk IGJ5IFJGQzUxMjk/DQoNCkFuZCBldmVuIHdoZXJlIHRoZSB0cmFuc3BvcnQgc3VwcG9ydHMgRUNO IG1hcmtpbmcsIG5vdGUgdGhlIGV4YW1wbGUgaW4gRmlndXJlIDEgaW4gdGhlIGRyYWZ0IHdoZXJl IHRoZSBvdXRlciBlbmNhcHN1bGF0aW9uIGNhbiBiZSBzdHJpcHBlZCBkdXJpbmcgU0ZGIHByb2Nl c3NpbmcuIEluIHRoYXQgY2FzZSwgdGhlIHNjb3BlIG9mIHRoZSBFQ04gbWFya2luZyBpcyBsaW1p dGVkIHRvIGluZGl2aWR1YWwgU0ZGLVNGRiBsaW5rcy4gcmF0aGVyIHRoYW4gZW5kLXRvLWVuZC4N Cg0KW01lZF0gV2h5IGNvdWxkbuKAmXQgU0ZGIHByZXNlcnZlIEVDTiB3aGVuIGRvaW5nIGl0cyB0 cmFuc3BvcnQgZGVjYXAvZW5jYXA/DQoNCg0KQ2hlZXJzLA0KQW5keQ0KDQoNCk9uIFRodSwgSmFu IDE3LCAyMDE5IGF0IDk6MTIgQU0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIGFsbCwNCg0KSSBkbyB0 aGluayB0aGF0IEVDTiBpcyBuYXR1cmFsbHkgYmV0dGVyIGhhbmRsZWQgYXQgdGhlIHRyYW5zcG9y dCBlbmNhcHN1bGF0aW9uIGluc3RlYWQgb2YgdGhlIE5TSCBpdHNlbGYuDQoNClJlcXVpcmluZyB0 aGUgZnVuY3Rpb25hbGl0eSB0byBiZSBoYW5kbGVkIGF0IHRoZSB0cmFuc3BvcnQgZW5jYXAgKGRy YWZ0LWlldGYtdHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGltKSBhbmQgTlNIIGlzIHJlZHVuZGFudCwg SU1PLg0KDQpJIGxpa2UgdGhlIGFwcHJvYWNoIHdlIHNldCBpbiB0aGUgU0ZDIGFyY2hpdGVjdHVy ZSBpbiB3aGljaCB3ZSBzZXBhcmF0ZWQgc2VydmljZSBtYXR0ZXJzIGZyb20gdHJhbnNwb3J0IG9u ZXMuIEknZCB2b3RlIGZvciBtYWludGFpbmluZyB0aGF0IHNlcGFyYXRpb24gY2xlYW5lciBhcyBp dCB3YXMgc2V0IGluIHRoZSBhcmNoIFJGQy4NCg0KVGhhbmsgeW91Lg0KDQpDaGVlcnMsDQpNZWQN Cg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGUgOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+XSBEZSBsYSBwYXJ0 IGRlIElFVEYgU2VjcmV0YXJpYXQNCj4gRW52b3nDqSA6IGpldWRpIDMgamFudmllciAyMDE5IDA2 OjExDQo+IMOAIDogc2ZjLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWNoYWlyc0BpZXRmLm9y Zz47IGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmc+Ow0KPiBzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gT2JqZXQgOiBbc2ZjXSBUaGUgU0ZDIFdHIGhhcyBw bGFjZWQgZHJhZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydCBpbg0KPiBzdGF0ZSAiQ2Fu ZGlkYXRlIGZvciBXRyBBZG9wdGlvbiINCj4NCj4NCj4gVGhlIFNGQyBXRyBoYXMgcGxhY2VkIGRy YWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnQgaW4gc3RhdGUNCj4gQ2FuZGlkYXRlIGZv ciBXRyBBZG9wdGlvbiAoZW50ZXJlZCBieSBKb2VsIEhhbHBlcm4pDQo+DQo+IFRoZSBkb2N1bWVu dCBpcyBhdmFpbGFibGUgYXQNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydC8NCj4NCj4gQ29tbWVudDoNCj4gVGhpcyBz dGFydHMgdGhlIFdHIGNhbGwgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQo+IFBsZWFzZSBy ZXNwb25kIHRvIHRoZSBsaXN0LCBpbmRpY2F0aW5nIHN1cHBvcnQgZm9yIHRoaXMgYXMgYSB3b3Jr IGl0ZW0gb2YgdGhlDQo+IHdvcmtpbmcgZ3JvdXAgd2l0aCB0aGlzIGRvY3VtZW50IGFzIHRoZSBi YXNpcyBmb3IgdGhlIHdvcmssIG9yIG9iamVjdGlvbiB0bw0KPiB0aGUgd29ya2luZyBncm91cCBh ZG9wdGluZyB0aGlzIGl0ZW0gYXMgYSB3b3JraW5nIGdyb3VwIGRyYWZ0Lg0KPg0KPiBUaGUgYXV0 aG9ycyBzaG91bGQgY29uZmlybSB0byB0aGUgY2hhaXJzIGFuZCBXRyBzZWNyZXRhcnkgdGhhdCBh bGwgSVBSIGtub3duDQo+IHRvIHRoZW0gcmVsZXZhbnQgdG8gdGhpcyBkcmFmdCBoYXMgYmVlbiBk aXNjbG9zZWQuDQo+DQo+IFRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGNhbGwgd2lsbCBsYXN0 IDIgd2Vla3MsIGVuZGluZyBhdCB0aGUgZW5kIG9mIHRoZQ0KPiBkYXkgb24gVGh1cnNkYXksIEph bnVhcnkgMTcgMjAxOSBDT0Igc29tZXdoZXJlLg0KPg0KPiBUaGFuayB5b3UsDQo+IEpvZWwNCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2Zj IG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg== --_000_787AE7BB302AE849A7480A190F8B93302EA0A2A3OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lm b3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5Q cmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kg SFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpGUjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2NzA3MTk5OTE7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjU5MjIxNDMzOCAtOTk4MzQwNDU0 IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3 ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5IaSBBbmR5LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5QbGVh c2Ugc2VlIGlubGluZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gQW5kcmV3IEcuIE1hbGlzPGJyPg0KPGI+ RW52b3nDqSZuYnNwOzo8L2I+IGpldWRpIDE3IGphbnZpZXIgMjAxOSAxNjozMzxicj4NCjxiPsOA Jm5ic3A7OjwvYj4gQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjxicj4NCjxiPkNjJm5ic3A7Ojwv Yj4gc2ZjLWNoYWlyc0BpZXRmLm9yZzsgSUVURiBTZWNyZXRhcmlhdDsgZHJhZnQtZWFzdGxha2Ut c2ZjLW5zaC1lY24tc3VwcG9ydEBpZXRmLm9yZzsgc2ZjQGlldGYub3JnPGJyPg0KPGI+T2JqZXQm bmJzcDs6PC9iPiBSZTogW3NmY10gVGhlIFNGQyBXRyBoYXMgcGxhY2VkIGRyYWZ0LWVhc3RsYWtl LXNmYy1uc2gtZWNuLXN1cHBvcnQgaW4gc3RhdGUgJnF1b3Q7Q2FuZGlkYXRlIGZvciBXRyBBZG9w dGlvbiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5NZWQsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Zb3VyIHBvaW50IGFib3V0IFJGQyA1MTI5IGlzIGNvcnJlY3QsIGJ1dCBJJ20gbm90IHBlcnNv bmFsbHkgYXdhcmUgb2YgYW55IGltcGxlbWVudGF0aW9ucy4gQW5kIEkgd2FzIGp1c3QgdXNpbmcg TVBMUyBhcyBhbiBleGFtcGxlLCB0aGVyZSBtYXkgYmUgb3RoZXJzIGluIHRoZSBmdXR1cmUgYXMg d2VsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIEkgdW5kZXJzdG9vZCB0 aGlzIHdhcyBhbiBleGFtcGxlLCBidXQgc3RpbGwgdGhpcyBpcyBJTUhPIHN1cHBvc2VkIHRvIGJl IGhhbmRsZWQgYW1vbmcgdGhlIHNwaXJpdCBvZiB0aGUgZWZmb3J0IGxlZCBieSBCb2IgaW4gNjA0 MCBhbmQgaXRzIGN1cnJlbnQgJmFtcDsNCiBmdXR1cmVzIHVwZGF0ZXMuIDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Zb3VyIHBvaW50IGFib3V0IHRoZSBTRkYgcHJlc2VydmluZyBFQ04g aXMgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50LCBmb3IgZXhhbXBsZSB0aGUgU0ZGIGNvdWxkIGhh dmUgc2VwYXJhdGUgaW5wdXQgYW5kIG91dHB1dCBpbnRlcmZhY2VzIHdpdGhvdXQgc2hhcmVkIG1l bW9yeSwgb3IgdGhlIHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9uIGNvdWxkIGNoYW5nZSBpbiBkaWZm ZXJlbnQgcmVnaW9ucyBvZiB0aGUgU0ZDDQogZG9tYWluLjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltN ZWRdIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHlvdXIgcG9pbnQgYWJvdXQgc2VwYXJhdGUgaW5wdXRz L291dHB1dCBpbnRlcmZhY2VzIGFuZCB0aGUgY2hhbmdlIG9mIGVuY2FwIHNjaGVtZXMuIExldOKA mXMgcHV0IGFzaWRlIFNGQyBmb3IgYSBtb21lbnQgYW5kIGNvbnNpZGVyDQogdGhlIGV4YW1wbGUg b2YgYSBMSVNQIFhUUiB3aGljaCBpcyBzdXBwb3J0aW5nIEVDTiBkaXNzZW1pbmF0aW9uL2hhbmRs aW5nLiBUaGF0IHhUUiBtYXkgbm90IHVzZSB0aGUgc2FtZSBpbi9vdXQgaW50ZXJmYWNlcywgYnV0 IHN0aWxsIG5lZWQgdG8gYWNoaWV2ZSBzb21lIHByb2Nlc3Npbmcgd2hlbiBkb2luZyBpdHMgZW5j YXAvZGVjYXAuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JdCdzIGRpZmZp Y3VsdCB0byBkZXBlbmQgb24gU0ZGcyBiZWluZyBhYmxlIHRvIHByZXNlcnZlIHRyYW5zcG9ydC1o ZWFkZXItZGVwZW5kZW50IGluZm9ybWF0aW9uIHdpdGhvdXQgdGhhdCBiZWNvbWluZyBhIHJlcXVp cmVtZW50IGluIHRoZSBTRkMgYXJjaGl0ZWN0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVk XSBJIGRvbuKAmXQgdGhpbmsgdGhhdCB3ZSBjYW4gdGFnIGNvbmdlc3Rpb24gbm90aWZpY2F0aW9u IGFzIOKAnHRyYW5zcG9ydC1oZWFkZXItZGVwZW5kZW504oCdLiBUaGVyZSBhcmUgd2F5cyB0byBw YXNzIHRoYXQgaW5mbyBldmVuDQogd2hlbiB0aGUgdHJhbnNwb3J0IGVuY2FwIGNoYW5nZXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIGlzIElN SE8gYW1vbmcgdGhpbmdzIHRoYXQgdGhlIFdHIGlzIHN1cHBvc2VkIHRvIGNvdmVyIHVuZGVyIHRo aXMgaXRlbSBpbiB0aGUgY2hhcnRlciAocGxlYXNlIG5vdGUgdGhhdCB0aG9zZSBhcmUgY2xlYXJp bmcNCiB0YWdlZCBhcyB0cmFuc3BvcnQgaXNzdWVzKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPjQpIFRyYW5zcG9ydCBDb25zaWRlcmF0aW9ucyAtIFRoaXMgd2ls bCBjYXB0dXJlIHRoZSBleHBlY3RhdGlvbnMgU0ZDIHBsYWNlcyBvbiB0cmFuc3BvcnQgYmVoYXZp b3IsIGluY2x1ZGluZyBkZWFsaW5nIHdpdGggaXNzdWVzDQogc3VjaCBhcyBjb25nZXN0aW9uIGlu ZGljYXRpb25zIGFuZCByZXNwb25zZXMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PT08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVl cnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVGh1LCBKYW4gMTcsIDIwMTkgYXQgMTA6MDIgQU0gJmx0OzxhIGhyZWY9Im1haWx0bzpt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhp IEFuZHksJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UGxlYXNlIHNlZSBpbmxp bmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFuZHJldyBHLiBNYWxpcyBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzphZ21hbGlzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFnbWFsaXNA Z21haWwuY29tPC9hPl0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBqZXVkaSAxNyBqYW52 aWVyIDIwMTkgMTU6NTA8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIFRH SS9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IElFVEYgU2VjcmV0YXJpYXQ7IDxhIGhyZWY9Im1h aWx0bzpzZmMtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzZmMtY2hhaXJzQGll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1 cHBvcnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gt ZWNuLXN1cHBvcnRAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+DQpzZmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9i PiBSZTogW3NmY10gVGhlIFNGQyBXRyBoYXMgcGxhY2VkIGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gt ZWNuLXN1cHBvcnQgaW4gc3RhdGUgJnF1b3Q7Q2FuZGlkYXRlIGZvciBXRyBBZG9wdGlvbiZxdW90 Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+TWVkLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk5vdCBhbGwgdHJhbnNwb3J0cyBzdXBwb3J0IEVDTiBtYXJraW5nLCBmb3IgZXhhbXBsZSBOU0gg b3ZlciBNUExTLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIElzbuKAmXQgdGhpcyBjb3ZlcmVkIGJ5 IFJGQzUxMjk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmQgZXZlbiB3aGVy ZSB0aGUgdHJhbnNwb3J0IHN1cHBvcnRzIEVDTiBtYXJraW5nLCBub3RlIHRoZSBleGFtcGxlIGlu IEZpZ3VyZSAxIGluIHRoZSBkcmFmdCB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBjYW4g YmUgc3RyaXBwZWQgZHVyaW5nIFNGRiBwcm9jZXNzaW5nLiBJbiB0aGF0IGNhc2UsIHRoZQ0KIHNj b3BlIG9mIHRoZSBFQ04gbWFya2luZyBpcyBsaW1pdGVkIHRvIGluZGl2aWR1YWwgU0ZGLVNGRiBs aW5rcy4gcmF0aGVyIHRoYW4gZW5kLXRvLWVuZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5bTWVkXSBXaHkgY291bGRu4oCZdCBTRkYgcHJlc2VydmUgRUNOIHdoZW4gZG9pbmcg aXRzIHRyYW5zcG9ydCBkZWNhcC9lbmNhcD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGVlcnMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZHk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUs IEphbiAxNywgMjAxOSBhdCA5OjEyIEFNICZsdDs8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDo0Li44cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5IaSBhbGwsDQo8YnI+DQo8YnI+DQpJIGRvIHRoaW5rIHRoYXQgRUNOIGlzIG5hdHVyYWxs eSBiZXR0ZXIgaGFuZGxlZCBhdCB0aGUgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24gaW5zdGVhZCBv ZiB0aGUgTlNIIGl0c2VsZi4NCjxicj4NCjxicj4NClJlcXVpcmluZyB0aGUgZnVuY3Rpb25hbGl0 eSB0byBiZSBoYW5kbGVkIGF0IHRoZSB0cmFuc3BvcnQgZW5jYXAgKGRyYWZ0LWlldGYtdHN2d2ct cmZjNjA0MHVwZGF0ZS1zaGltKSBhbmQgTlNIIGlzIHJlZHVuZGFudCwgSU1PLjxicj4NCjxicj4N CkkgbGlrZSB0aGUgYXBwcm9hY2ggd2Ugc2V0IGluIHRoZSBTRkMgYXJjaGl0ZWN0dXJlIGluIHdo aWNoIHdlIHNlcGFyYXRlZCBzZXJ2aWNlIG1hdHRlcnMgZnJvbSB0cmFuc3BvcnQgb25lcy4gSSdk IHZvdGUgZm9yIG1haW50YWluaW5nIHRoYXQgc2VwYXJhdGlvbiBjbGVhbmVyIGFzIGl0IHdhcyBz ZXQgaW4gdGhlIGFyY2ggUkZDLjxicj4NCjxicj4NClRoYW5rIHlvdS4mbmJzcDsgPGJyPg0KPGJy Pg0KQ2hlZXJzLDxicj4NCk1lZDxicj4NCjxicj4NCiZndDsgLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tPGJyPg0KJmd0OyBEZSZuYnNwOzogc2ZjIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBEZSBsYSBwYXJ0IGRlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQomZ3Q7IEVudm95w6kmbmJz cDs6IGpldWRpIDMgamFudmllciAyMDE5IDA2OjExPGJyPg0KJmd0OyDDgCZuYnNwOzogPGEgaHJl Zj0ibWFpbHRvOnNmYy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZmMtY2hhaXJz QGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVj bi1zdXBwb3J0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtZWFzdGxha2Utc2ZjLW5z aC1lY24tc3VwcG9ydEBpZXRmLm9yZzwvYT47PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86c2Zj QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsgT2Jq ZXQmbmJzcDs6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNlZCBkcmFmdC1lYXN0bGFrZS1zZmMt bnNoLWVjbi1zdXBwb3J0IGluPGJyPg0KJmd0OyBzdGF0ZSAmcXVvdDtDYW5kaWRhdGUgZm9yIFdH IEFkb3B0aW9uJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIFNGQyBX RyBoYXMgcGxhY2VkIGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnQgaW4gc3RhdGU8 YnI+DQomZ3Q7IENhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb24gKGVudGVyZWQgYnkgSm9lbCBIYWxw ZXJuKTxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGF0PGJy Pg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1l YXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0LyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tc3VwcG9y dC88L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENvbW1lbnQ6PGJyPg0KJmd0OyBUaGlzIHN0YXJ0 cyB0aGUgV0cgY2FsbCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkcmFmdC48YnI+DQomZ3Q7IFBsZWFz ZSByZXNwb25kIHRvIHRoZSBsaXN0LCBpbmRpY2F0aW5nIHN1cHBvcnQgZm9yIHRoaXMgYXMgYSB3 b3JrIGl0ZW0gb2YgdGhlPGJyPg0KJmd0OyB3b3JraW5nIGdyb3VwIHdpdGggdGhpcyBkb2N1bWVu dCBhcyB0aGUgYmFzaXMgZm9yIHRoZSB3b3JrLCBvciBvYmplY3Rpb24gdG88YnI+DQomZ3Q7IHRo ZSB3b3JraW5nIGdyb3VwIGFkb3B0aW5nIHRoaXMgaXRlbSBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJh ZnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBhdXRob3JzIHNob3VsZCBjb25maXJtIHRvIHRo ZSBjaGFpcnMgYW5kIFdHIHNlY3JldGFyeSB0aGF0IGFsbCBJUFIga25vd248YnI+DQomZ3Q7IHRv IHRoZW0gcmVsZXZhbnQgdG8gdGhpcyBkcmFmdCBoYXMgYmVlbiBkaXNjbG9zZWQuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGNhbGwgd2lsbCBsYXN0IDIg d2Vla3MsIGVuZGluZyBhdCB0aGUgZW5kIG9mIHRoZTxicj4NCiZndDsgZGF5IG9uIFRodXJzZGF5 LCBKYW51YXJ5IDE3IDIwMTkgQ09CIHNvbWV3aGVyZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhh bmsgeW91LDxicj4NCiZndDsgSm9lbDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2ZjIG1haWxpbmcg bGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93302EA0A2A3OPEXCAUBMA2corp_-- From nobody Fri Jan 18 06:55:03 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF4F12D4EC; Fri, 18 Jan 2019 06:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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=joelhalpern.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 PNfLOXY5eFqB; Fri, 18 Jan 2019 06:54:55 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 D160812D4EA; Fri, 18 Jan 2019 06:54:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43h3rb3vx5zYk2y; Fri, 18 Jan 2019 06:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1547823295; bh=lU6UIyRiY2Zsuo7srppTtfA14NGC6CYW4UUdtHDHIUQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XHGoduWY6uw62USwNqucuFbqnJwesxkD/1JEr7UEvfDLiWFQ7wjUHs+Z74LJ5g+Ql Er5IuOAJ6p61/8rbMlCVnGPDIbV6AcSwMp89eW+zVONbGKt1UPw8vLZTPmxkBDkEUg cOBdvLbz695Jpqdtfzs+utyB7yCcmDKoU7mOIgec= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43h3rZ4hNvzYjn5; Fri, 18 Jan 2019 06:54:54 -0800 (PST) To: mohamed.boucadair@orange.com, "Andrew G. Malis" Cc: "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> Date: Fri, 18 Jan 2019 09:54:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 14:55:01 -0000 Let me try as an individual to paraphrase what I understand the document to be offering. That authors should feel free to comment further including if necessary telling me that I am confused. Consider an SFF that receives a packet with a transport ECN indication and an NSH header. That SFF removes the transport header. It then (usually) sends the packet via some other means to an SF, and gets the packet back. After which it sends it on to the next SFF with a new transport header carrying the NSH. Let us take as given that we want to support effective ECN. Then we need to somehow preserve the ECN information that the SFF receives. One way would be to insist that the SFF, when it receives the ECN information, has to rummage through to find the internal IP packet, and must update the internal ECN information therein. Ugg. IThat would be a pretty onerous requirement. Instead, the document suggests that the SFF transfer the marking to the NSH header, and then use that NSH marking when it generates the new transport header. This can then be used when the packet exits the NSH domain to propagate the information to the header (which is by definition exposed when the NSH header is removed.) Med, if I understand you properly you are suggesting that the SFF should somehow keep the information from the transport header associated with the packet, but not in the NSH header. In some SFF implementations, and with some ways of working with SFs, that is doable. Requiring that would limit the implementation and deployment choices. Yours, Joel On 1/18/19 4:15 AM, mohamed.boucadair@orange.com wrote: > Hi Andy, > > Please see inline. > > Cheers, > > Med > > *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* Andrew G. Malis > *Envoyé :* jeudi 17 janvier 2019 16:33 > *À :* BOUCADAIR Mohamed TGI/OLN > *Cc :* sfc-chairs@ietf.org; IETF Secretariat; > draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > *Objet :* Re: [sfc] The SFC WG has placed > draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" > > Med, > > Your point about RFC 5129 is correct, but I'm not personally aware of > any implementations. And I was just using MPLS as an example, there may > be others in the future as well. > > [Med] I understood this was an example, but still this is IMHO supposed > to be handled among the spirit of the effort led by Bob in 6040 and its > current & futures updates. > > Your point about the SFF preserving ECN is implementation dependent, for > example the SFF could have separate input and output interfaces without > shared memory, or the transport encapsulation could change in different > regions of the SFC domain. > > [Med] I don’t understand your point about separate inputs/output > interfaces and the change of encap schemes. Let’s put aside SFC for a > moment and consider the example of a LISP XTR which is supporting ECN > dissemination/handling. That xTR may not use the same in/out interfaces, > but still need to achieve some processing when doing its encap/decap. > > It's difficult to depend on SFFs being able to preserve > transport-header-dependent information without that becoming a > requirement in the SFC architecture. > > [Med] I don’t think that we can tag congestion notification as > “transport-header-dependent”. There are ways to pass that info even when > the transport encap changes. > > This is IMHO among things that the WG is supposed to cover under this > item in the charter (please note that those are clearing taged as > transport issues): > > == > > 4) Transport Considerations - This will capture the expectations SFC > places on transport behavior, including dealing with issues such as > congestion indications and responses. > > == > > Cheers, > > Andy > > On Thu, Jan 17, 2019 at 10:02 AM > wrote: > > Hi Andy, > > Please see inline. > > Cheers, > > Med > > *De :*Andrew G. Malis [mailto:agmalis@gmail.com > ] > *Envoyé :* jeudi 17 janvier 2019 15:50 > *À :* BOUCADAIR Mohamed TGI/OLN > *Cc :* IETF Secretariat; sfc-chairs@ietf.org > ; > draft-eastlake-sfc-nsh-ecn-support@ietf.org > ; sfc@ietf.org > > *Objet :* Re: [sfc] The SFC WG has placed > draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" > > Med, > > Not all transports support ECN marking, for example NSH over MPLS. > > [Med] Isn’t this covered by RFC5129? > > And even where the transport supports ECN marking, note the example > in Figure 1 in the draft where the outer encapsulation can be > stripped during SFF processing. In that case, the scope of the ECN > marking is limited to individual SFF-SFF links. rather than end-to-end. > > [Med] Why couldn’t SFF preserve ECN when doing its transport > decap/encap? > > Cheers, > > Andy > > On Thu, Jan 17, 2019 at 9:12 AM > wrote: > > Hi all, > > I do think that ECN is naturally better handled at the transport > encapsulation instead of the NSH itself. > > Requiring the functionality to be handled at the transport encap > (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redundant, IMO. > > I like the approach we set in the SFC architecture in which we > separated service matters from transport ones. I'd vote for > maintaining that separation cleaner as it was set in the arch RFC. > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : sfc [mailto:sfc-bounces@ietf.org > ] De la part de IETF Secretariat > > Envoyé : jeudi 3 janvier 2019 06:11 > > À : sfc-chairs@ietf.org ; > draft-eastlake-sfc-nsh-ecn-support@ietf.org > ; > > sfc@ietf.org > > Objet : [sfc] The SFC WG has placed > draft-eastlake-sfc-nsh-ecn-support in > > state "Candidate for WG Adoption" > > > > > > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state > > Candidate for WG Adoption (entered by Joel Halpern) > > > > The document is available at > > > https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-support/ > > > > Comment: > > This starts the WG call for adoption of this draft. > > Please respond to the list, indicating support for this as a > work item of the > > working group with this document as the basis for the work, > or objection to > > the working group adopting this item as a working group draft. > > > > The authors should confirm to the chairs and WG secretary > that all IPR known > > to them relevant to this draft has been disclosed. > > > > The working group adoption call will last 2 weeks, ending at > the end of the > > day on Thursday, January 17 2019 COB somewhere. > > > > Thank you, > > Joel > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Jan 18 11:19:57 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C41131304; Fri, 18 Jan 2019 11:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vPmlmK2MMSOp; Fri, 18 Jan 2019 11:19:53 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 C1B84131300; Fri, 18 Jan 2019 11:19:52 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id r200so11600671iod.11; Fri, 18 Jan 2019 11:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Gg+tvMwB1kDnkRkYsAralNEHI+8Aca8nN9fin/WnDZI=; b=nbUvLsvO2I3vd+CZ1xIozBcfdNjRvuXEybO4wxDPk05IRkKiRSUTzdk39MtC0gHFVd 5QGJkuHinqzniaj74QhkxKuRsdMacPMBP0zUtG1GFMtGLBNbxbCjc7OSWs91pSjQAW6H pcHxcIXcw4XPUFqhKVxOHgrnUCRnoY0tOcbVP89PF2nb0uZJliywtgK+kvmBu7KuaeMH LWUzbw9aEzfUlp9X1Gz6ft6AEdP9ElxmZmOwh2HP71zROsj9edIKDfdtOVgv0PynVmtz 7YNuNLkz+KSLO3wKkPObfrDAiGSy8xEMJ4hhXwnimE7Dzaxhf5gboBOzC45pFmQAClBe d5qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Gg+tvMwB1kDnkRkYsAralNEHI+8Aca8nN9fin/WnDZI=; b=ge2mgd8J/CVxcS/GTIoeLJPYZkf2MzCGF5sU9I3aFZH1HFPtjt/LKb2fWJClfBivf0 tz7uCSQ06y1NN7URSQiKNHK8eIR3CY+eCPv6b4cNm0NxRogfFQBPJIPdncBbQIQCm0Bq aV3UEuOAXrn+T5lW1uftTruQ8U7MHPuY3N7mRqtak1FzcBOnvJ+QNLhMCnEQZlRrgHXM P1n0j0lHJDTVliwunidbO9O0hEeL/PoGenBhlBUAdAZvVz8ZVj8uIswNsS/sYbabN2fc UNtFV8902t4fW4jgPZBosrpYeiAoMT8dRDjHUZHigfhbTFPltfsmmQ/uVzXQPW2CuDz3 awVA== X-Gm-Message-State: AJcUukcPyet/cC6qvyDHjKzFIAGlTj4kpbNtCQ7NMKYWhc7BLM1aapll YKQzu4CDtHOIOwkfV6dP3t2ME7pKI1E3HdHAxfU= X-Google-Smtp-Source: ALg8bN4sg/fSoDP0IbFtyr08TST/Mb6Gx4PDMTv446CcLSbxIBxC1aTv94pbh6J2FR55qwz3F7SdwzvoyP2A3KjRKq0= X-Received: by 2002:a6b:3945:: with SMTP id g66mr10993306ioa.131.1547839191847; Fri, 18 Jan 2019 11:19:51 -0800 (PST) MIME-Version: 1.0 References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> In-Reply-To: <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> From: Donald Eastlake Date: Fri, 18 Jan 2019 14:19:40 -0500 Message-ID: To: "Joel M. Halpern" Cc: mohamed.boucadair@orange.com, "Andrew G. Malis" , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 19:19:55 -0000 Hi Joel, I think your message correctly describes what the draft is doing. To me, carrying ECN in the NSH within the SFC domain is simpler and more robust than trying to use the outer or the inner transport headers. For example, should an SF or SF Proxy clear the outer transport ECN bits, with ECN being carried in the NSH, you just lose congestion management on the round trip from the SFF to that SF or SF Proxy. On the other hand, if you are depending on ECN in the outer transport header rather than the NSH (or in metadata where there is no outer transport header), then you lose congestion management across the entire SFC domain. Or if there is an SF or SF Proxy reached by a transport protocol that has no ECN support, you don't have to muck around finding the inner transport header to update. Thanks, Donald =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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Fri, Jan 18, 2019 at 9:55 AM Joel M. Halpern wrote= : > > > Let me try as an individual to paraphrase what I understand the document > to be offering. That authors should feel free to comment further > including if necessary telling me that I am confused. > > Consider an SFF that receives a packet with a transport ECN indication > and an NSH header. That SFF removes the transport header. It then > (usually) sends the packet via some other means to an SF, and gets the > packet back. After which it sends it on to the next SFF with a new > transport header carrying the NSH. > Let us take as given that we want to support effective ECN. > Then we need to somehow preserve the ECN information that the SFF receive= s. > > One way would be to insist that the SFF, when it receives the ECN > information, has to rummage through to find the internal IP packet, and > must update the internal ECN information therein. Ugg. IThat would be > a pretty onerous requirement. > > Instead, the document suggests that the SFF transfer the marking to the > NSH header, and then use that NSH marking when it generates the new > transport header. This can then be used when the packet exits the NSH > domain to propagate the information to the header (which is by > definition exposed when the NSH header is removed.) > > Med, if I understand you properly you are suggesting that the SFF should > somehow keep the information from the transport header associated with > the packet, but not in the NSH header. In some SFF implementations, and > with some ways of working with SFs, that is doable. Requiring that > would limit the implementation and deployment choices. > > > Yours, > Joel > > On 1/18/19 4:15 AM, mohamed.boucadair@orange.com wrote: > > Hi Andy, > > > > Please see inline. > > > > Cheers, > > > > Med > > > > *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* Andrew G. Malis > > *Envoy=C3=A9 :* jeudi 17 janvier 2019 16:33 > > *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > > *Cc :* sfc-chairs@ietf.org; IETF Secretariat; > > draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > > *Objet :* Re: [sfc] The SFC WG has placed > > draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" > > > > Med, > > > > Your point about RFC 5129 is correct, but I'm not personally aware of > > any implementations. And I was just using MPLS as an example, there may > > be others in the future as well. > > > > [Med] I understood this was an example, but still this is IMHO supposed > > to be handled among the spirit of the effort led by Bob in 6040 and its > > current & futures updates. > > > > Your point about the SFF preserving ECN is implementation dependent, fo= r > > example the SFF could have separate input and output interfaces without > > shared memory, or the transport encapsulation could change in different > > regions of the SFC domain. > > > > [Med] I don=E2=80=99t understand your point about separate inputs/outpu= t > > interfaces and the change of encap schemes. Let=E2=80=99s put aside SFC= for a > > moment and consider the example of a LISP XTR which is supporting ECN > > dissemination/handling. That xTR may not use the same in/out interfaces= , > > but still need to achieve some processing when doing its encap/decap. > > > > It's difficult to depend on SFFs being able to preserve > > transport-header-dependent information without that becoming a > > requirement in the SFC architecture. > > > > [Med] I don=E2=80=99t think that we can tag congestion notification as > > =E2=80=9Ctransport-header-dependent=E2=80=9D. There are ways to pass th= at info even when > > the transport encap changes. > > > > This is IMHO among things that the WG is supposed to cover under this > > item in the charter (please note that those are clearing taged as > > transport issues): > > > > =3D=3D > > > > 4) Transport Considerations - This will capture the expectations SFC > > places on transport behavior, including dealing with issues such as > > congestion indications and responses. > > > > =3D=3D > > > > Cheers, > > > > Andy > > > > On Thu, Jan 17, 2019 at 10:02 AM > > wrote: > > > > Hi Andy, > > > > Please see inline. > > > > Cheers, > > > > Med > > > > *De :*Andrew G. Malis [mailto:agmalis@gmail.com > > ] > > *Envoy=C3=A9 :* jeudi 17 janvier 2019 15:50 > > *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > > *Cc :* IETF Secretariat; sfc-chairs@ietf.org > > ; > > draft-eastlake-sfc-nsh-ecn-support@ietf.org > > ; sfc@ietf.org > > > > *Objet :* Re: [sfc] The SFC WG has placed > > draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adopt= ion" > > > > Med, > > > > Not all transports support ECN marking, for example NSH over MPLS. > > > > [Med] Isn=E2=80=99t this covered by RFC5129? > > > > And even where the transport supports ECN marking, note the example > > in Figure 1 in the draft where the outer encapsulation can be > > stripped during SFF processing. In that case, the scope of the ECN > > marking is limited to individual SFF-SFF links. rather than end-to-= end. > > > > [Med] Why couldn=E2=80=99t SFF preserve ECN when doing its transpor= t > > decap/encap? > > > > Cheers, > > > > Andy > > > > On Thu, Jan 17, 2019 at 9:12 AM > > wrote: > > > > Hi all, > > > > I do think that ECN is naturally better handled at the transpor= t > > encapsulation instead of the NSH itself. > > > > Requiring the functionality to be handled at the transport enca= p > > (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redundant, IMO= . > > > > I like the approach we set in the SFC architecture in which we > > separated service matters from transport ones. I'd vote for > > maintaining that separation cleaner as it was set in the arch R= FC. > > > > Thank you. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : sfc [mailto:sfc-bounces@ietf.org > > ] De la part de IETF Secretariat > > > Envoy=C3=A9 : jeudi 3 janvier 2019 06:11 > > > =C3=80 : sfc-chairs@ietf.org ; > > draft-eastlake-sfc-nsh-ecn-support@ietf.org > > ; > > > sfc@ietf.org > > > Objet : [sfc] The SFC WG has placed > > draft-eastlake-sfc-nsh-ecn-support in > > > state "Candidate for WG Adoption" > > > > > > > > > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in = state > > > Candidate for WG Adoption (entered by Joel Halpern) > > > > > > The document is available at > > > > > https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn-sup= port/ > > > > > > Comment: > > > This starts the WG call for adoption of this draft. > > > Please respond to the list, indicating support for this as a > > work item of the > > > working group with this document as the basis for the work, > > or objection to > > > the working group adopting this item as a working group draf= t. > > > > > > The authors should confirm to the chairs and WG secretary > > that all IPR known > > > to them relevant to this draft has been disclosed. > > > > > > The working group adoption call will last 2 weeks, ending at > > the end of the > > > day on Thursday, January 17 2019 COB somewhere. > > > > > > Thank you, > > > Joel > > > > > > _______________________________________________ > > > sfc mailing list > > > sfc@ietf.org > > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Mon Jan 21 16:05:54 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6639128D0C; Mon, 21 Jan 2019 16:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" 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 2GBZ94IWHc4J; Mon, 21 Jan 2019 16:05:50 -0800 (PST) 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 DAFCA128CF3; Mon, 21 Jan 2019 16:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:From: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=GoFO0cJ/COn+AugqtaSwI8vii482OPyAKsCIgQph7mc=; b=cu7SI3t8f0XaKUnw1RMKGLJ0y hGkTO7dEVduEjuNhVgfYWsoUgJFs6fAucCGXlmMWd2FQ/bzs0bxBCMcZr32NdSyhIK9aCQtS9Gh/I shfJz51BMm21jWfHXSk5hI6QSUK9V0pGVJbvC1Q51FKE+kJZH0GGpeYwQoCRUNT8ZNtBEIhYwrAPc XoDP9SlrqpFpq9mDLM7XJiniotDd0kaCg6R6X77joQ3S0jrIE4S1JhTb0Y4jpzti1xFt6Eimu2BvR UKjZA/p5GMrwfsgfxOU5zmrgBMLpRwyAz02bhxOBKrXHcyCLy4u+qlnKutW8KPeKn+MKa/RmeUnJO d0t6Ak3EQ==; Received: from 35.0.208.46.dyn.plus.net ([46.208.0.35]:45454 helo=[192.168.0.4]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gljZb-0006EM-1C; Tue, 22 Jan 2019 00:05:47 +0000 From: Bob Briscoe To: Tal Mizrahi Cc: Donald Eastlake , sfc-chairs@ietf.org, draft-eastlake-sfc-nsh-ecn-support@ietf.org, sfc@ietf.org References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <4f7963fc-0157-8587-eeb5-48d63a3de7f8@bobbriscoe.net> Message-ID: Date: Tue, 22 Jan 2019 00:05:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <4f7963fc-0157-8587-eeb5-48d63a3de7f8@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------4063BEA16E0E6373F6990724" 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: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 00:05:53 -0000 This is a multi-part message in MIME format. --------------4063BEA16E0E6373F6990724 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Tal, I've conferred with my co-authors, and I can confirm that there is no need for a separate L4S mode, as incorrectly described around Table 2 in draft-02. It was actually me who wrote the incorrect text and table in the first place - my co-authors are wholly innocent, cos I'm the one developing the L4S experiment (L4S = Low Latency Low Loss Scalable throughput)! So thanks for asking how the two approaches interoperate, which made me notice this. The answer to your question is that L4S doesn't need any change to how congestion signals are propagated. L4S is purely a different AQM algorithm at network nodes and a different response algorithm at the source. As far as encap and decap are concerned, the tunnelling behaviours specified in RFC6040 and followed in the sfc-nsh-ecn draft inherently work for L4S just as well as for standard RFC3168 ECN. That's all the SFC WG needs to know. However, if you want to know a little more about how L4S works, the source distinguishes its packets by setting them to ECT(1), which an L4S node classifies into a distinct L4S queue. Any network node that doesn't support L4S will just handle these packets as if ECT(0) and ECT(1) mean the same (as required by the original ECN spec [RFC3168]). And the source has to detect such behaviour and respond accordingly [draft-ietf-tsvwg-ecn-l4s-id]. We will be correcting the text as follows: CURRENT: Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD set it to ECT(0), in order to indicate that the NSH encapsulation is an ECN-Capable Transport.It MAY instead be set to ECT(1) if the NSH domain supports the experimental L4S capability [RFC8311 ], [ecnL4S ]. ... +-----------------+-------------------------------+ | Incoming Header |Departing NSH and Outer Headers| | (also equal to +---------------+---------------+ | departing Inner | Classic ECN | L4S ECN | | Header) | Mode | Mode | +-----------------+---------------+---------------+ | Not-ECT | ECT(0) | ECT(1) | | ECT(0) | ECT(0) | ECT(0) | | ECT(1) | ECT(1) | ECT(1) | | CE | CE | CE | +-----------------+---------------+---------------+ PROPOSED: Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD set it to ECT(0).This indicates that, even though the end-to-end transport is not ECN-capable, the egress and ingress of the SFC domain are acting as an ECN-capable transport. This approach will inherently support all known variants of ECN, including the experimental L4S capability [RFC8311 ], [ecnL4S ]. ... +-----------------+---------------+ | Incoming Header |Departing NSH | | (also equal to |& Outer Headers| | departing Inner | | | Header) | | +-----------------+---------------+ | Not-ECT | ECT(0) | | ECT(0) | ECT(0) | | ECT(1) | ECT(1) | | CE | CE | +-----------------+---------------+ On 15/01/2019 22:53, Bob Briscoe wrote: >>> - "It MAY instead be set to ECT(1) if the NSH domain supports the experimental L4S capability [RFC8311], [ecnL4S]." >>> This sentence is confusing from an implementer's perspective. Does the "MAY" here allow interoperability between the two approaches (RFC3168/ RFC8311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are expected to be implemented as defined in [RFC3168] or as in [RFC8311], or a combination of both. >> I agree we need to clarify that. > Let me get back to you on this one. I have to admit that I can't > remember why we catered for L4S in the way written around table 2. > I've checked back, and I actually wrote this part myself, but it looks > wrong to me, which would be embarrassing. However, I need to check > with my co-authors to confirm that. > > Whatever, thanks for picking this up. > > > Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------4063BEA16E0E6373F6990724 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Tal,

I've conferred with my co-authors, and I can confirm that there is no need for a separate L4S mode, as incorrectly described around Table 2 in draft-02. It was actually me who wrote the incorrect text and table in the first place - my co-authors are wholly innocent, cos I'm the one developing the L4S experiment (L4S = Low Latency Low Loss Scalable throughput)! So thanks for asking how the two approaches interoperate, which made me notice this.

The answer to your question is that L4S doesn't need any change to how congestion signals are propagated. L4S is purely a different AQM algorithm at network nodes and a different response algorithm at the source. As far as encap and decap are concerned, the tunnelling behaviours specified in RFC6040 and followed in the sfc-nsh-ecn draft inherently work for L4S just as well as for standard RFC3168 ECN. That's all the SFC WG needs to know.

However, if you want to know a little more about how L4S works, the source distinguishes its packets by setting them to ECT(1), which an L4S node classifies into a distinct L4S queue. Any network node that doesn't support L4S will just handle these packets as if ECT(0) and ECT(1) mean the same (as required by the original ECN spec [RFC3168]). And the source has to detect such behaviour and respond accordingly [draft-ietf-tsvwg-ecn-l4s-id].

We will be correcting the text as follows:

CURRENT:
   Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD
   set it to ECT(0), in order to indicate that the NSH encapsulation is
   an ECN-Capable Transport. It MAY instead be set to ECT(1) if the NSH
   domain supports the experimental L4S capability [RFC8311], [ecnL4S]. 
...

            +-----------------+-------------------------------+
            | Incoming Header |Departing NSH and Outer Headers|
            | (also equal to  +---------------+---------------+
            | departing Inner |  Classic ECN  |    L4S ECN    |
            |     Header)     |     Mode      |     Mode      |
            +-----------------+---------------+---------------+
            |    Not-ECT      |   ECT(0)      |    ECT(1)     |
            |     ECT(0)      |   ECT(0)      |    ECT(0)     |
            |     ECT(1)      |   ECT(1)      |    ECT(1)     |
            |       CE        |     CE        |      CE       |
            +-----------------+---------------+---------------+
PROPOSED:

   Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD
   set it to ECT(0). This indicates that, even though the end-to-end 
   transport is not ECN-capable, the egress and ingress of the SFC
   domain are acting as an ECN-capable transport. This approach will
   inherently support all known variants of ECN, including the 
   experimental L4S capability [RFC8311], [ecnL4S]. 
... 

            +-----------------+---------------+
            | Incoming Header |Departing NSH  |
            | (also equal to  |& Outer Headers|
            | departing Inner |               |
            |     Header)     |               |
            +-----------------+---------------+
            |    Not-ECT      |   ECT(0)      |
            |     ECT(0)      |   ECT(0)      |
            |     ECT(1)      |   ECT(1)      |
            |       CE        |     CE        |
            +-----------------+---------------+


On 15/01/2019 22:53, Bob Briscoe wrote:
- "It MAY instead be set to ECT(1) if the NSH domain supports the experimental L4S capability [RFC8311], [ecnL4S]."
  This sentence is confusing from an implementer's perspective. Does the "MAY" here allow interoperability between the two approaches (RFC3168/ RFC8311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are expected to be implemented as defined in [RFC3168] or as in [RFC8311], or a combination of both.

I agree we need to clarify that.
Let me get back to you on this one. I have to admit that I can't remember why we catered for L4S in the way written around table 2. I've checked back, and I actually wrote this part myself, but it looks wrong to me, which would be embarrassing. However, I need to check with my co-authors to confirm that.

Whatever, thanks for picking this up.


Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------4063BEA16E0E6373F6990724-- From nobody Mon Jan 21 22:25:40 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1961310CC; Mon, 21 Jan 2019 22:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 o_23N_IUU9JN; Mon, 21 Jan 2019 22:25:36 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687FF1310BD; Mon, 21 Jan 2019 22:25:36 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 43kJM26cTDz4wP9; Tue, 22 Jan 2019 07:25:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 43kJM25k1LzFpWY; Tue, 22 Jan 2019 07:25:34 +0100 (CET) Received: from OPEXCAUBM7F.corporate.adroot.infra.ftgroup (10.114.13.98) by OPEXCLILM21.corporate.adroot.infra.ftgroup (10.114.31.2) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 22 Jan 2019 07:25:34 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0415.000; Tue, 22 Jan 2019 07:25:34 +0100 From: To: "Joel M. Halpern" , "Andrew G. Malis" CC: "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" Thread-Index: AQHUrz3IGP3fzgvWYEmb2hoCi5/DcKW606+w Date: Tue, 22 Jan 2019 06:25:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> In-Reply-To: <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 06:25:39 -0000 SGkgSm9lbCwgDQoNCldoYXQgbWFrZXMgRUNOIHNwZWNpZmljIGluIHRoaXMgcmVnYXJkcyBjb21w YXJlZCB0byBEU0NQIG1hcmtpbmcgcHJlc2VydmF0aW9uPyANCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpvZWwgTS4gSGFscGVybiBbbWFp bHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+IEVudm95w6nCoDogdmVuZHJlZGkgMTggamFudmll ciAyMDE5IDE1OjU1DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IEFuZHJldyBH LiBNYWxpcw0KPiBDY8KgOiBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYu b3JnOyBzZmNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBs YWNlZCBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0IGluDQo+IHN0YXRlICJDYW5k aWRhdGUgZm9yIFdHIEFkb3B0aW9uIg0KPiANCj4gPGNoYWlyIGhhdCBvZmY+DQo+IExldCBtZSB0 cnkgYXMgYW4gaW5kaXZpZHVhbCB0byBwYXJhcGhyYXNlIHdoYXQgSSB1bmRlcnN0YW5kIHRoZSBk b2N1bWVudA0KPiB0byBiZSBvZmZlcmluZy4gIFRoYXQgYXV0aG9ycyBzaG91bGQgZmVlbCBmcmVl IHRvIGNvbW1lbnQgZnVydGhlcg0KPiBpbmNsdWRpbmcgaWYgbmVjZXNzYXJ5IHRlbGxpbmcgbWUg dGhhdCBJIGFtIGNvbmZ1c2VkLg0KPiANCj4gQ29uc2lkZXIgYW4gU0ZGIHRoYXQgcmVjZWl2ZXMg YSBwYWNrZXQgd2l0aCBhIHRyYW5zcG9ydCBFQ04gaW5kaWNhdGlvbg0KPiBhbmQgYW4gTlNIIGhl YWRlci4gIFRoYXQgU0ZGIHJlbW92ZXMgdGhlIHRyYW5zcG9ydCBoZWFkZXIuICBJdCB0aGVuDQo+ ICh1c3VhbGx5KSBzZW5kcyB0aGUgcGFja2V0IHZpYSBzb21lIG90aGVyIG1lYW5zIHRvIGFuIFNG LCBhbmQgZ2V0cyB0aGUNCj4gcGFja2V0IGJhY2suICBBZnRlciB3aGljaCBpdCBzZW5kcyBpdCBv biB0byB0aGUgbmV4dCBTRkYgd2l0aCBhIG5ldw0KPiB0cmFuc3BvcnQgaGVhZGVyIGNhcnJ5aW5n IHRoZSBOU0guDQo+IExldCB1cyB0YWtlIGFzIGdpdmVuIHRoYXQgd2Ugd2FudCB0byBzdXBwb3J0 IGVmZmVjdGl2ZSBFQ04uDQo+IFRoZW4gd2UgbmVlZCB0byBzb21laG93IHByZXNlcnZlIHRoZSBF Q04gaW5mb3JtYXRpb24gdGhhdCB0aGUgU0ZGIHJlY2VpdmVzLg0KPiANCj4gT25lIHdheSB3b3Vs ZCBiZSB0byBpbnNpc3QgdGhhdCB0aGUgU0ZGLCB3aGVuIGl0IHJlY2VpdmVzIHRoZSBFQ04NCj4g aW5mb3JtYXRpb24sIGhhcyB0byBydW1tYWdlIHRocm91Z2ggdG8gZmluZCB0aGUgaW50ZXJuYWwg SVAgcGFja2V0LCBhbmQNCj4gbXVzdCB1cGRhdGUgdGhlIGludGVybmFsIEVDTiBpbmZvcm1hdGlv biB0aGVyZWluLiAgVWdnLiAgSVRoYXQgd291bGQgYmUNCj4gYSBwcmV0dHkgb25lcm91cyByZXF1 aXJlbWVudC4NCj4gDQo+IEluc3RlYWQsIHRoZSBkb2N1bWVudCBzdWdnZXN0cyB0aGF0IHRoZSBT RkYgdHJhbnNmZXIgdGhlIG1hcmtpbmcgdG8gdGhlDQo+IE5TSCBoZWFkZXIsIGFuZCB0aGVuIHVz ZSB0aGF0IE5TSCBtYXJraW5nIHdoZW4gaXQgZ2VuZXJhdGVzIHRoZSBuZXcNCj4gdHJhbnNwb3J0 IGhlYWRlci4gIFRoaXMgY2FuIHRoZW4gYmUgdXNlZCB3aGVuIHRoZSBwYWNrZXQgZXhpdHMgdGhl IE5TSA0KPiBkb21haW4gdG8gcHJvcGFnYXRlIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgaGVhZGVy ICh3aGljaCBpcyBieQ0KPiBkZWZpbml0aW9uIGV4cG9zZWQgd2hlbiB0aGUgTlNIIGhlYWRlciBp cyByZW1vdmVkLikNCj4gDQo+IE1lZCwgaWYgSSB1bmRlcnN0YW5kIHlvdSBwcm9wZXJseSB5b3Ug YXJlIHN1Z2dlc3RpbmcgdGhhdCB0aGUgU0ZGIHNob3VsZA0KPiBzb21laG93IGtlZXAgdGhlIGlu Zm9ybWF0aW9uIGZyb20gdGhlIHRyYW5zcG9ydCBoZWFkZXIgYXNzb2NpYXRlZCB3aXRoDQo+IHRo ZSBwYWNrZXQsIGJ1dCBub3QgaW4gdGhlIE5TSCBoZWFkZXIuICBJbiBzb21lIFNGRiBpbXBsZW1l bnRhdGlvbnMsIGFuZA0KPiB3aXRoIHNvbWUgd2F5cyBvZiB3b3JraW5nIHdpdGggU0ZzLCB0aGF0 IGlzIGRvYWJsZS4gIFJlcXVpcmluZyB0aGF0DQo+IHdvdWxkIGxpbWl0IHRoZSBpbXBsZW1lbnRh dGlvbiBhbmQgZGVwbG95bWVudCBjaG9pY2VzLg0KPiANCj4gPGNoYWlyIGhhdCBzb21ld2hlcmU+ DQo+IFlvdXJzLA0KPiBKb2VsDQo+IA0KPiBPbiAxLzE4LzE5IDQ6MTUgQU0sIG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gSGkgQW5keSwNCj4gPg0KPiA+IFBsZWFzZSBz ZWUgaW5saW5lLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+DQo+ID4gTWVkDQo+ID4NCj4gPiAqRGXC oDoqc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddICpEZSBsYSBwYXJ0IGRlKiBBbmRy ZXcgRy4gTWFsaXMNCj4gPiAqRW52b3nDqcKgOiogamV1ZGkgMTcgamFudmllciAyMDE5IDE2OjMz DQo+ID4gKsOAwqA6KiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+ID4gKkNjwqA6KiBzZmMt Y2hhaXJzQGlldGYub3JnOyBJRVRGIFNlY3JldGFyaWF0Ow0KPiA+IGRyYWZ0LWVhc3RsYWtlLXNm Yy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiA+ICpPYmpldMKgOiog UmU6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNlZA0KPiA+IGRyYWZ0LWVhc3RsYWtlLXNmYy1u c2gtZWNuLXN1cHBvcnQgaW4gc3RhdGUgIkNhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb24iDQo+ID4N Cj4gPiBNZWQsDQo+ID4NCj4gPiBZb3VyIHBvaW50IGFib3V0IFJGQyA1MTI5IGlzIGNvcnJlY3Qs IGJ1dCBJJ20gbm90IHBlcnNvbmFsbHkgYXdhcmUgb2YNCj4gPiBhbnkgaW1wbGVtZW50YXRpb25z LiBBbmQgSSB3YXMganVzdCB1c2luZyBNUExTIGFzIGFuIGV4YW1wbGUsIHRoZXJlIG1heQ0KPiA+ IGJlIG90aGVycyBpbiB0aGUgZnV0dXJlIGFzIHdlbGwuDQo+ID4NCj4gPiBbTWVkXSBJIHVuZGVy c3Rvb2QgdGhpcyB3YXMgYW4gZXhhbXBsZSwgYnV0IHN0aWxsIHRoaXMgaXMgSU1ITyBzdXBwb3Nl ZA0KPiA+IHRvIGJlIGhhbmRsZWQgYW1vbmcgdGhlIHNwaXJpdCBvZiB0aGUgZWZmb3J0IGxlZCBi eSBCb2IgaW4gNjA0MCBhbmQgaXRzDQo+ID4gY3VycmVudCAmIGZ1dHVyZXMgdXBkYXRlcy4NCj4g Pg0KPiA+IFlvdXIgcG9pbnQgYWJvdXQgdGhlIFNGRiBwcmVzZXJ2aW5nIEVDTiBpcyBpbXBsZW1l bnRhdGlvbiBkZXBlbmRlbnQsIGZvcg0KPiA+IGV4YW1wbGUgdGhlIFNGRiBjb3VsZCBoYXZlIHNl cGFyYXRlIGlucHV0IGFuZCBvdXRwdXQgaW50ZXJmYWNlcyB3aXRob3V0DQo+ID4gc2hhcmVkIG1l bW9yeSwgb3IgdGhlIHRyYW5zcG9ydCBlbmNhcHN1bGF0aW9uIGNvdWxkIGNoYW5nZSBpbiBkaWZm ZXJlbnQNCj4gPiByZWdpb25zIG9mIHRoZSBTRkMgZG9tYWluLg0KPiA+DQo+ID4gW01lZF0gSSBk b27igJl0IHVuZGVyc3RhbmQgeW91ciBwb2ludCBhYm91dCBzZXBhcmF0ZSBpbnB1dHMvb3V0cHV0 DQo+ID4gaW50ZXJmYWNlcyBhbmQgdGhlIGNoYW5nZSBvZiBlbmNhcCBzY2hlbWVzLiBMZXTigJlz IHB1dCBhc2lkZSBTRkMgZm9yIGENCj4gPiBtb21lbnQgYW5kIGNvbnNpZGVyIHRoZSBleGFtcGxl IG9mIGEgTElTUCBYVFIgd2hpY2ggaXMgc3VwcG9ydGluZyBFQ04NCj4gPiBkaXNzZW1pbmF0aW9u L2hhbmRsaW5nLiBUaGF0IHhUUiBtYXkgbm90IHVzZSB0aGUgc2FtZSBpbi9vdXQgaW50ZXJmYWNl cywNCj4gPiBidXQgc3RpbGwgbmVlZCB0byBhY2hpZXZlIHNvbWUgcHJvY2Vzc2luZyB3aGVuIGRv aW5nIGl0cyBlbmNhcC9kZWNhcC4NCj4gPg0KPiA+IEl0J3MgZGlmZmljdWx0IHRvIGRlcGVuZCBv biBTRkZzIGJlaW5nIGFibGUgdG8gcHJlc2VydmUNCj4gPiB0cmFuc3BvcnQtaGVhZGVyLWRlcGVu ZGVudCBpbmZvcm1hdGlvbiB3aXRob3V0IHRoYXQgYmVjb21pbmcgYQ0KPiA+IHJlcXVpcmVtZW50 IGluIHRoZSBTRkMgYXJjaGl0ZWN0dXJlLg0KPiA+DQo+ID4gW01lZF0gSSBkb27igJl0IHRoaW5r IHRoYXQgd2UgY2FuIHRhZyBjb25nZXN0aW9uIG5vdGlmaWNhdGlvbiBhcw0KPiA+IOKAnHRyYW5z cG9ydC1oZWFkZXItZGVwZW5kZW504oCdLiBUaGVyZSBhcmUgd2F5cyB0byBwYXNzIHRoYXQgaW5m byBldmVuIHdoZW4NCj4gPiB0aGUgdHJhbnNwb3J0IGVuY2FwIGNoYW5nZXMuDQo+ID4NCj4gPiBU aGlzIGlzIElNSE8gYW1vbmcgdGhpbmdzIHRoYXQgdGhlIFdHIGlzIHN1cHBvc2VkIHRvIGNvdmVy IHVuZGVyIHRoaXMNCj4gPiBpdGVtIGluIHRoZSBjaGFydGVyIChwbGVhc2Ugbm90ZSB0aGF0IHRo b3NlIGFyZSBjbGVhcmluZyB0YWdlZCBhcw0KPiA+IHRyYW5zcG9ydCBpc3N1ZXMpOg0KPiA+DQo+ ID4gPT0NCj4gPg0KPiA+IDQpIFRyYW5zcG9ydCBDb25zaWRlcmF0aW9ucyAtIFRoaXMgd2lsbCBj YXB0dXJlIHRoZSBleHBlY3RhdGlvbnMgU0ZDDQo+ID4gcGxhY2VzIG9uIHRyYW5zcG9ydCBiZWhh dmlvciwgaW5jbHVkaW5nIGRlYWxpbmcgd2l0aCBpc3N1ZXMgc3VjaCBhcw0KPiA+IGNvbmdlc3Rp b24gaW5kaWNhdGlvbnMgYW5kIHJlc3BvbnNlcy4NCj4gPg0KPiA+ID09DQo+ID4NCj4gPiBDaGVl cnMsDQo+ID4NCj4gPiBBbmR5DQo+ID4NCj4gPiBPbiBUaHUsIEphbiAxNywgMjAxOSBhdCAxMDow MiBBTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+IDxtYWlsdG86bW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gICAgIEhpIEFuZHksDQo+ID4N Cj4gPiAgICAgUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4NCj4gPiAgICAgQ2hlZXJzLA0KPiA+DQo+ ID4gICAgIE1lZA0KPiA+DQo+ID4gICAgICpEZcKgOipBbmRyZXcgRy4gTWFsaXMgW21haWx0bzph Z21hbGlzQGdtYWlsLmNvbQ0KPiA+ICAgICA8bWFpbHRvOmFnbWFsaXNAZ21haWwuY29tPl0NCj4g PiAgICAgKkVudm95w6nCoDoqIGpldWRpIDE3IGphbnZpZXIgMjAxOSAxNTo1MA0KPiA+ICAgICAq w4DCoDoqIEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gPiAgICAgKkNjwqA6KiBJRVRGIFNl Y3JldGFyaWF0OyBzZmMtY2hhaXJzQGlldGYub3JnDQo+ID4gICAgIDxtYWlsdG86c2ZjLWNoYWly c0BpZXRmLm9yZz47DQo+ID4gICAgIGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnRA aWV0Zi5vcmcNCj4gPiAgICAgPG1haWx0bzpkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBw b3J0QGlldGYub3JnPjsgc2ZjQGlldGYub3JnDQo+ID4gICAgIDxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KPiA+ICAgICAqT2JqZXTCoDoqIFJlOiBbc2ZjXSBUaGUgU0ZDIFdHIGhhcyBwbGFjZWQNCj4g PiAgICAgZHJhZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydCBpbiBzdGF0ZSAiQ2FuZGlk YXRlIGZvciBXRyBBZG9wdGlvbiINCj4gPg0KPiA+ICAgICBNZWQsDQo+ID4NCj4gPiAgICAgTm90 IGFsbCB0cmFuc3BvcnRzIHN1cHBvcnQgRUNOIG1hcmtpbmcsIGZvciBleGFtcGxlIE5TSCBvdmVy IE1QTFMuDQo+ID4NCj4gPiAgICAgW01lZF0gSXNu4oCZdCB0aGlzIGNvdmVyZWQgYnkgUkZDNTEy OT8NCj4gPg0KPiA+ICAgICBBbmQgZXZlbiB3aGVyZSB0aGUgdHJhbnNwb3J0IHN1cHBvcnRzIEVD TiBtYXJraW5nLCBub3RlIHRoZSBleGFtcGxlDQo+ID4gICAgIGluIEZpZ3VyZSAxIGluIHRoZSBk cmFmdCB3aGVyZSB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiBjYW4gYmUNCj4gPiAgICAgc3RyaXBw ZWQgZHVyaW5nIFNGRiBwcm9jZXNzaW5nLiBJbiB0aGF0IGNhc2UsIHRoZSBzY29wZSBvZiB0aGUg RUNODQo+ID4gICAgIG1hcmtpbmcgaXMgbGltaXRlZCB0byBpbmRpdmlkdWFsIFNGRi1TRkYgbGlu a3MuIHJhdGhlciB0aGFuIGVuZC10by1lbmQuDQo+ID4NCj4gPiAgICAgW01lZF0gV2h5IGNvdWxk buKAmXQgU0ZGIHByZXNlcnZlIEVDTiB3aGVuIGRvaW5nIGl0cyB0cmFuc3BvcnQNCj4gPiAgICAg ZGVjYXAvZW5jYXA/DQo+ID4NCj4gPiAgICAgQ2hlZXJzLA0KPiA+DQo+ID4gICAgIEFuZHkNCj4g Pg0KPiA+ICAgICBPbiBUaHUsIEphbiAxNywgMjAxOSBhdCA5OjEyIEFNIDxtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tDQo+ID4gICAgIDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gICAgICAgICBIaSBhbGwsDQo+ID4NCj4gPiAgICAgICAg IEkgZG8gdGhpbmsgdGhhdCBFQ04gaXMgbmF0dXJhbGx5IGJldHRlciBoYW5kbGVkIGF0IHRoZSB0 cmFuc3BvcnQNCj4gPiAgICAgICAgIGVuY2Fwc3VsYXRpb24gaW5zdGVhZCBvZiB0aGUgTlNIIGl0 c2VsZi4NCj4gPg0KPiA+ICAgICAgICAgUmVxdWlyaW5nIHRoZSBmdW5jdGlvbmFsaXR5IHRvIGJl IGhhbmRsZWQgYXQgdGhlIHRyYW5zcG9ydCBlbmNhcA0KPiA+ICAgICAgICAgKGRyYWZ0LWlldGYt dHN2d2ctcmZjNjA0MHVwZGF0ZS1zaGltKSBhbmQgTlNIIGlzIHJlZHVuZGFudCwgSU1PLg0KPiA+ DQo+ID4gICAgICAgICBJIGxpa2UgdGhlIGFwcHJvYWNoIHdlIHNldCBpbiB0aGUgU0ZDIGFyY2hp dGVjdHVyZSBpbiB3aGljaCB3ZQ0KPiA+ICAgICAgICAgc2VwYXJhdGVkIHNlcnZpY2UgbWF0dGVy cyBmcm9tIHRyYW5zcG9ydCBvbmVzLiBJJ2Qgdm90ZSBmb3INCj4gPiAgICAgICAgIG1haW50YWlu aW5nIHRoYXQgc2VwYXJhdGlvbiBjbGVhbmVyIGFzIGl0IHdhcyBzZXQgaW4gdGhlIGFyY2ggUkZD Lg0KPiA+DQo+ID4gICAgICAgICBUaGFuayB5b3UuDQo+ID4NCj4gPiAgICAgICAgIENoZWVycywN Cj4gPiAgICAgICAgIE1lZA0KPiA+DQo+ID4gICAgICAgICAgPiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gPiAgICAgICAgICA+IERlwqA6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnDQo+ID4gICAgICAgICA8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0gRGUgbGEg cGFydCBkZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4gICAgICAgICAgPiBFbnZvecOpwqA6IGpldWRp IDMgamFudmllciAyMDE5IDA2OjExDQo+ID4gICAgICAgICAgPiDDgMKgOiBzZmMtY2hhaXJzQGll dGYub3JnIDxtYWlsdG86c2ZjLWNoYWlyc0BpZXRmLm9yZz47DQo+ID4gICAgICAgICBkcmFmdC1l YXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnDQo+ID4gICAgICAgICA8bWFpbHRv OmRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmc+Ow0KPiA+ICAgICAg ICAgID4gc2ZjQGlldGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+ICAgICAgICAgID4g T2JqZXTCoDogW3NmY10gVGhlIFNGQyBXRyBoYXMgcGxhY2VkDQo+ID4gICAgICAgICBkcmFmdC1l YXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0IGluDQo+ID4gICAgICAgICAgPiBzdGF0ZSAiQ2Fu ZGlkYXRlIGZvciBXRyBBZG9wdGlvbiINCj4gPiAgICAgICAgICA+DQo+ID4gICAgICAgICAgPg0K PiA+ICAgICAgICAgID4gVGhlIFNGQyBXRyBoYXMgcGxhY2VkIGRyYWZ0LWVhc3RsYWtlLXNmYy1u c2gtZWNuLXN1cHBvcnQgaW4NCj4gc3RhdGUNCj4gPiAgICAgICAgICA+IENhbmRpZGF0ZSBmb3Ig V0cgQWRvcHRpb24gKGVudGVyZWQgYnkgSm9lbCBIYWxwZXJuKQ0KPiA+ICAgICAgICAgID4NCj4g PiAgICAgICAgICA+IFRoZSBkb2N1bWVudCBpcyBhdmFpbGFibGUgYXQNCj4gPiAgICAgICAgICA+ DQo+ID4gICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1lYXN0 bGFrZS1zZmMtbnNoLWVjbi0NCj4gc3VwcG9ydC8NCj4gPiAgICAgICAgICA+DQo+ID4gICAgICAg ICAgPiBDb21tZW50Og0KPiA+ICAgICAgICAgID4gVGhpcyBzdGFydHMgdGhlIFdHIGNhbGwgZm9y IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQo+ID4gICAgICAgICAgPiBQbGVhc2UgcmVzcG9uZCB0 byB0aGUgbGlzdCwgaW5kaWNhdGluZyBzdXBwb3J0IGZvciB0aGlzIGFzIGENCj4gPiAgICAgICAg IHdvcmsgaXRlbSBvZiB0aGUNCj4gPiAgICAgICAgICA+IHdvcmtpbmcgZ3JvdXAgd2l0aCB0aGlz IGRvY3VtZW50IGFzIHRoZSBiYXNpcyBmb3IgdGhlIHdvcmssDQo+ID4gICAgICAgICBvciBvYmpl Y3Rpb24gdG8NCj4gPiAgICAgICAgICA+IHRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW5nIHRoaXMg aXRlbSBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQuDQo+ID4gICAgICAgICAgPg0KPiA+ICAgICAg ICAgID4gVGhlIGF1dGhvcnMgc2hvdWxkIGNvbmZpcm0gdG8gdGhlIGNoYWlycyBhbmQgV0cgc2Vj cmV0YXJ5DQo+ID4gICAgICAgICB0aGF0IGFsbCBJUFIga25vd24NCj4gPiAgICAgICAgICA+IHRv IHRoZW0gcmVsZXZhbnQgdG8gdGhpcyBkcmFmdCBoYXMgYmVlbiBkaXNjbG9zZWQuDQo+ID4gICAg ICAgICAgPg0KPiA+ICAgICAgICAgID4gVGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gY2FsbCB3 aWxsIGxhc3QgMiB3ZWVrcywgZW5kaW5nIGF0DQo+ID4gICAgICAgICB0aGUgZW5kIG9mIHRoZQ0K PiA+ICAgICAgICAgID4gZGF5IG9uIFRodXJzZGF5LCBKYW51YXJ5IDE3IDIwMTkgQ09CIHNvbWV3 aGVyZS4NCj4gPiAgICAgICAgICA+DQo+ID4gICAgICAgICAgPiBUaGFuayB5b3UsDQo+ID4gICAg ICAgICAgPiBKb2VsDQo+ID4gICAgICAgICAgPg0KPiA+ICAgICAgICAgID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiAgICAgICAgICA+IHNmYyBt YWlsaW5nIGxpc3QNCj4gPiAgICAgICAgICA+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRm Lm9yZz4NCj4gPiAgICAgICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+ID4NCg== From nobody Tue Jan 22 00:14:18 2019 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DBD130E8E; Tue, 22 Jan 2019 00:14:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <154814485028.22740.6704677566070992561@ietfa.amsl.com> Date: Tue, 22 Jan 2019 00:14:10 -0800 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-serviceid-header-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 08:14:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Service Function Chaining: Subscriber and Policy Identification Variable-Length Network Service Header (NSH) Context Headers Authors : Behcet Sarikaya Dirk von Hugo Mohamed Boucadair Filename : draft-ietf-sfc-serviceid-header-01.txt Pages : 9 Date : 2019-01-22 Abstract: This document discusses how to inform Service Functions about subscriber- and service-related information for the sake of policy enforcement and appropriate service function chaining operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sfc-serviceid-header-01 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-serviceid-header-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-serviceid-header-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 Jan 22 04:30:50 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB56130F3F; Tue, 22 Jan 2019 04:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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=joelhalpern.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 9AjJbcO-Qo6C; Tue, 22 Jan 2019 04:30:47 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 81235130EFF; Tue, 22 Jan 2019 04:30:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43kSSR148Pz1VCpV; Tue, 22 Jan 2019 04:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1548160247; bh=BV1pd55rm5Aeeb2n8bzN8Pg+ezRs7Dou9F6VD8QuWOw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=P3I0WnvvfP//L50VGjKTSK4C3QitZ7DMWkU2uszbf8n1JF0sqsls32mdHJaYZ6wZJ 1jibO7BluCodiFhq3ioGGb39RWJxezRBVj0gDgcDKUknqolD/H/OTbxjcBh70h7vQi 8ZMvpNmuwo44DAX8CKhHqY4x2eV7lBOszmpSzII8= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43kSSQ1Jkfz1V3sH; Tue, 22 Jan 2019 04:30:46 -0800 (PST) To: mohamed.boucadair@orange.com, "Andrew G. Malis" Cc: "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: Date: Tue, 22 Jan 2019 07:30:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 12:30:49 -0000 (again: speaking personally) DSCP behavior is VERY different from ECN behavior in terms of intermediate router modification. DSCPs may get rewritten at certain specific places, but not generally at interior routers. So mapping from the interior packet DSCP to the exterior packet DSCP and IEEE marking is normal and safe. there is no need to reverse the process. ECN marking needs to reverse the process due to the fact that individual routers are expected to change the marking based on local conditions. At least thaat is how I understand it, Joel On 1/22/19 1:25 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > What makes ECN specific in this regards compared to DSCP marking preservation? > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : vendredi 18 janvier 2019 15:55 >> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis >> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in >> state "Candidate for WG Adoption" >> >> >> Let me try as an individual to paraphrase what I understand the document >> to be offering. That authors should feel free to comment further >> including if necessary telling me that I am confused. >> >> Consider an SFF that receives a packet with a transport ECN indication >> and an NSH header. That SFF removes the transport header. It then >> (usually) sends the packet via some other means to an SF, and gets the >> packet back. After which it sends it on to the next SFF with a new >> transport header carrying the NSH. >> Let us take as given that we want to support effective ECN. >> Then we need to somehow preserve the ECN information that the SFF receives. >> >> One way would be to insist that the SFF, when it receives the ECN >> information, has to rummage through to find the internal IP packet, and >> must update the internal ECN information therein. Ugg. IThat would be >> a pretty onerous requirement. >> >> Instead, the document suggests that the SFF transfer the marking to the >> NSH header, and then use that NSH marking when it generates the new >> transport header. This can then be used when the packet exits the NSH >> domain to propagate the information to the header (which is by >> definition exposed when the NSH header is removed.) >> >> Med, if I understand you properly you are suggesting that the SFF should >> somehow keep the information from the transport header associated with >> the packet, but not in the NSH header. In some SFF implementations, and >> with some ways of working with SFs, that is doable. Requiring that >> would limit the implementation and deployment choices. >> >> >> Yours, >> Joel >> >> On 1/18/19 4:15 AM, mohamed.boucadair@orange.com wrote: >>> Hi Andy, >>> >>> Please see inline. >>> >>> Cheers, >>> >>> Med >>> >>> *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* Andrew G. Malis >>> *Envoyé :* jeudi 17 janvier 2019 16:33 >>> *À :* BOUCADAIR Mohamed TGI/OLN >>> *Cc :* sfc-chairs@ietf.org; IETF Secretariat; >>> draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>> *Objet :* Re: [sfc] The SFC WG has placed >>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" >>> >>> Med, >>> >>> Your point about RFC 5129 is correct, but I'm not personally aware of >>> any implementations. And I was just using MPLS as an example, there may >>> be others in the future as well. >>> >>> [Med] I understood this was an example, but still this is IMHO supposed >>> to be handled among the spirit of the effort led by Bob in 6040 and its >>> current & futures updates. >>> >>> Your point about the SFF preserving ECN is implementation dependent, for >>> example the SFF could have separate input and output interfaces without >>> shared memory, or the transport encapsulation could change in different >>> regions of the SFC domain. >>> >>> [Med] I don’t understand your point about separate inputs/output >>> interfaces and the change of encap schemes. Let’s put aside SFC for a >>> moment and consider the example of a LISP XTR which is supporting ECN >>> dissemination/handling. That xTR may not use the same in/out interfaces, >>> but still need to achieve some processing when doing its encap/decap. >>> >>> It's difficult to depend on SFFs being able to preserve >>> transport-header-dependent information without that becoming a >>> requirement in the SFC architecture. >>> >>> [Med] I don’t think that we can tag congestion notification as >>> “transport-header-dependent”. There are ways to pass that info even when >>> the transport encap changes. >>> >>> This is IMHO among things that the WG is supposed to cover under this >>> item in the charter (please note that those are clearing taged as >>> transport issues): >>> >>> == >>> >>> 4) Transport Considerations - This will capture the expectations SFC >>> places on transport behavior, including dealing with issues such as >>> congestion indications and responses. >>> >>> == >>> >>> Cheers, >>> >>> Andy >>> >>> On Thu, Jan 17, 2019 at 10:02 AM >> > wrote: >>> >>> Hi Andy, >>> >>> Please see inline. >>> >>> Cheers, >>> >>> Med >>> >>> *De :*Andrew G. Malis [mailto:agmalis@gmail.com >>> ] >>> *Envoyé :* jeudi 17 janvier 2019 15:50 >>> *À :* BOUCADAIR Mohamed TGI/OLN >>> *Cc :* IETF Secretariat; sfc-chairs@ietf.org >>> ; >>> draft-eastlake-sfc-nsh-ecn-support@ietf.org >>> ; sfc@ietf.org >>> >>> *Objet :* Re: [sfc] The SFC WG has placed >>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" >>> >>> Med, >>> >>> Not all transports support ECN marking, for example NSH over MPLS. >>> >>> [Med] Isn’t this covered by RFC5129? >>> >>> And even where the transport supports ECN marking, note the example >>> in Figure 1 in the draft where the outer encapsulation can be >>> stripped during SFF processing. In that case, the scope of the ECN >>> marking is limited to individual SFF-SFF links. rather than end-to-end. >>> >>> [Med] Why couldn’t SFF preserve ECN when doing its transport >>> decap/encap? >>> >>> Cheers, >>> >>> Andy >>> >>> On Thu, Jan 17, 2019 at 9:12 AM >> > wrote: >>> >>> Hi all, >>> >>> I do think that ECN is naturally better handled at the transport >>> encapsulation instead of the NSH itself. >>> >>> Requiring the functionality to be handled at the transport encap >>> (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redundant, IMO. >>> >>> I like the approach we set in the SFC architecture in which we >>> separated service matters from transport ones. I'd vote for >>> maintaining that separation cleaner as it was set in the arch RFC. >>> >>> Thank you. >>> >>> Cheers, >>> Med >>> >>> > -----Message d'origine----- >>> > De : sfc [mailto:sfc-bounces@ietf.org >>> ] De la part de IETF Secretariat >>> > Envoyé : jeudi 3 janvier 2019 06:11 >>> > À : sfc-chairs@ietf.org ; >>> draft-eastlake-sfc-nsh-ecn-support@ietf.org >>> ; >>> > sfc@ietf.org >>> > Objet : [sfc] The SFC WG has placed >>> draft-eastlake-sfc-nsh-ecn-support in >>> > state "Candidate for WG Adoption" >>> > >>> > >>> > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in >> state >>> > Candidate for WG Adoption (entered by Joel Halpern) >>> > >>> > The document is available at >>> > >>> https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn- >> support/ >>> > >>> > Comment: >>> > This starts the WG call for adoption of this draft. >>> > Please respond to the list, indicating support for this as a >>> work item of the >>> > working group with this document as the basis for the work, >>> or objection to >>> > the working group adopting this item as a working group draft. >>> > >>> > The authors should confirm to the chairs and WG secretary >>> that all IPR known >>> > to them relevant to this draft has been disclosed. >>> > >>> > The working group adoption call will last 2 weeks, ending at >>> the end of the >>> > day on Thursday, January 17 2019 COB somewhere. >>> > >>> > Thank you, >>> > Joel >>> > >>> > _______________________________________________ >>> > sfc mailing list >>> > sfc@ietf.org >>> > https://www.ietf.org/mailman/listinfo/sfc >>> From nobody Tue Jan 22 06:58:14 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E552124D68; Tue, 22 Jan 2019 06:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 n6XprEsferj4; Tue, 22 Jan 2019 06:58:10 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 F0D64126CC7; Tue, 22 Jan 2019 06:58:09 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id t33so27826003qtt.4; Tue, 22 Jan 2019 06:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AzfFZqot1YSM9bBqhiXSN3EbhnevfYwyPzAagn2Cumo=; b=kM6WkNcY2muQW075IecC1iqOt6pNSNpYdK73qoVEpYlzCc7C8kFcmgsRah3xWiARvz TOWijakym0QZUzFk2ZWdsTTeN7pFm2qhBdzaMHvTK2/9WS4pI/fPYfVuLwcRxH4NvxjG hCNMY7wk++16gouAHp64Dyc30lM02gP/GxLuO9nGgH7jAYyvn9yUEw8z3s9v2GkkkqRk lmbLVR1s8NtghcaIeW+C9gIgfzI9v7PA/9rQKUG6Rb/CIeqHghR64muWzj/Ku/akAoYn Tb2NlmH5SHQLnwRxpbCu/UeVBfqu6qh5d9VqHip+aCXmx3l3wP+0Ri23YEhxfryQ6vyo WpEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AzfFZqot1YSM9bBqhiXSN3EbhnevfYwyPzAagn2Cumo=; b=J3qiwBZk1YMUe+Z3z34QDSVsX+bbDIofRSwkLCmy9RLgH0i2bB3KyoRnv/hjyFPm10 vBjqER0y0+znk0Taf4EjhJFhXKJJf+iG43PtRcaz7ZaZDTmb6itEGUbLOO3Y7f3sAVvc cPYX1ZNaFC0DVFlG/6aQkUzNtZwFQmnEATPb6CSjHhcx9TpGUIyejWoDOw53FHcBN+E5 6SUiP2XxVlHRMsPZVLfSB2cNchr3FzKzGzGyUYABvBIROJQGAa8GlJYSVdDVUqe848II SGfFEurXrU/MilRUT0YPcu8AmFFLCDEyHAJS/53ctEne4Fy7LT9CU+2lg/7nUOlDmD/3 801Q== X-Gm-Message-State: AJcUukdx5PD0FVG0TX5WVzS7pMuRIi8uDpNiV+euCdqzjDFR3V+MJcNt duY6aRZXsvjjbC5Xe1SHcIeF+g7yxokz7thpixZKFggp X-Google-Smtp-Source: ALg8bN4U+8KTTANsunqqFHTJ7U081XiMLfceWsmfgsBzR5cvcn1uh+GHkedgFeGB047KED+Kp279oByrX+QNzoV9cho= X-Received: by 2002:a0c:b0db:: with SMTP id p27mr30335457qvc.73.1548169088992; Tue, 22 Jan 2019 06:58:08 -0800 (PST) MIME-Version: 1.0 References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <4f7963fc-0157-8587-eeb5-48d63a3de7f8@bobbriscoe.net> In-Reply-To: From: Tal Mizrahi Date: Tue, 22 Jan 2019 16:57:57 +0200 Message-ID: To: Bob Briscoe Cc: Donald Eastlake , sfc-chairs@ietf.org, draft-eastlake-sfc-nsh-ecn-support@ietf.org, sfc@ietf.org Content-Type: multipart/alternative; boundary="0000000000009a0b5105800d34b7" Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 14:58:12 -0000 --0000000000009a0b5105800d34b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bob, Many thanks for the clarification. Cheers, Tal. On Tue, Jan 22, 2019 at 2:05 AM Bob Briscoe wrote: > Tal, > > I've conferred with my co-authors, and I can confirm that there is no nee= d > for a separate L4S mode, as incorrectly described around Table 2 in > draft-02. It was actually me who wrote the incorrect text and table in th= e > first place - my co-authors are wholly innocent, cos I'm the one developi= ng > the L4S experiment (L4S =3D Low Latency Low Loss Scalable throughput)! So > thanks for asking how the two approaches interoperate, which made me noti= ce > this. > > The answer to your question is that L4S doesn't need any change to how > congestion signals are propagated. L4S is purely a different AQM algorith= m > at network nodes and a different response algorithm at the source. As far > as encap and decap are concerned, the tunnelling behaviours specified in > RFC6040 and followed in the sfc-nsh-ecn draft inherently work for L4S jus= t > as well as for standard RFC3168 ECN. That's all the SFC WG needs to know. > > However, if you want to know a little more about how L4S works, the sourc= e > distinguishes its packets by setting them to ECT(1), which an L4S node > classifies into a distinct L4S queue. Any network node that doesn't suppo= rt > L4S will just handle these packets as if ECT(0) and ECT(1) mean the same > (as required by the original ECN spec [RFC3168]). And the source has to > detect such behaviour and respond accordingly > [draft-ietf-tsvwg-ecn-l4s-id]. > > We will be correcting the text as follows: > > CURRENT: > > Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD > set it to ECT(0), in order to indicate that the NSH encapsulation is > an ECN-Capable Transport. It MAY instead be set to ECT(1) if the NSH > domain supports the experimental L4S capability [RFC8311 ], [ecnL4S ]. > ... > > +-----------------+-------------------------------+ > | Incoming Header |Departing NSH and Outer Headers| > | (also equal to +---------------+---------------+ > | departing Inner | Classic ECN | L4S ECN | > | Header) | Mode | Mode | > +-----------------+---------------+---------------+ > | Not-ECT | ECT(0) | ECT(1) | > | ECT(0) | ECT(0) | ECT(0) | > | ECT(1) | ECT(1) | ECT(1) | > | CE | CE | CE | > +-----------------+---------------+---------------+ > > PROPOSED: > > Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD > set it to ECT(0). This indicates that, even though the end-to-end > transport is not ECN-capable, the egress and ingress of the SFC > domain are acting as an ECN-capable transport. This approach will > inherently support all known variants of ECN, including the > experimental L4S capability [RFC8311 ], [ecnL4S ]. > ... > > +-----------------+---------------+ > | Incoming Header |Departing NSH | > | (also equal to |& Outer Headers| > | departing Inner | | > | Header) | | > +-----------------+---------------+ > | Not-ECT | ECT(0) | > | ECT(0) | ECT(0) | > | ECT(1) | ECT(1) | > | CE | CE | > +-----------------+---------------+ > > > > On 15/01/2019 22:53, Bob Briscoe wrote: > > - "It MAY instead be set to ECT(1) if the NSH domain supports the experim= ental L4S capability [RFC8311], [ecnL4S]." > This sentence is confusing from an implementer's perspective. Does the = "MAY" here allow interoperability between the two approaches (RFC3168/ RFC8= 311)? Please clarify in the draft whether ECN-in-NSH-aware nodes are expect= ed to be implemented as defined in [RFC3168] or as in [RFC8311], or a combi= nation of both. > > I agree we need to clarify that. > > Let me get back to you on this one. I have to admit that I can't remember > why we catered for L4S in the way written around table 2. I've checked > back, and I actually wrote this part myself, but it looks wrong to me, > which would be embarrassing. However, I need to check with my co-authors = to > confirm that. > > Whatever, thanks for picking this up. > > > Bob > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --0000000000009a0b5105800d34b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob,

Many thanks for the clarificati= on.

Cheers,
Tal.

On Tue, Jan 22, 20= 19 at 2:05 AM Bob Briscoe <in@bobbr= iscoe.net> wrote:
=20 =20 =20
Tal,

I've conferred with my co-authors, and I can confirm that there is no need for a separate L4S mode, as incorrectly described around Table 2 in draft-02. It was actually me who wrote the incorrect text and table in the first place - my co-authors are wholly innocent, cos I'm the one developing the L4S experiment (L4S =3D Low Latency = Low Loss Scalable throughput)! So thanks for asking how the two approaches interoperate, which made me notice this.

The answer to your question is that L4S doesn't need any change to how congestion signals are propagated. L4S is purely a different AQM algorithm at network nodes and a different response algorithm at the source. As far as encap and decap are concerned, the tunnelling behaviours specified in RFC6040 and followed in the sfc-nsh-ecn draft inherently work for L4S just as well as for standard RFC3168 ECN. That's all the SFC WG needs to know.

However, if you want to know a little more about how L4S works, the source distinguishes its packets by setting them to ECT(1), which an L4S node classifies into a distinct L4S queue. Any network node that doesn't support L4S will just handle these packets as if ECT(0) and ECT(1) mean the same (as required by the original ECN spec [RFC3168]). And the source has to detect such behaviour and respond accordingly [draft-ietf-tsvwg-ecn-l4s-id].

We will be correcting the text as follows:

CURRENT:
   Then, if the resul=
ting NSH ECN field is Not-ECT, the ingress SHOULD
   set it to ECT(0), in order to indicate that the NSH encapsulation is
   an ECN-Capable Transport. It MAY instead be set =
to ECT(1) if the NSH
   domain supports the experimental L4S capability [RFC8311], [ecnL4S].=20
...

            +--------=
---------+-------------------------------+
            | Incoming Header |Departing NSH and Outer Headers|
            | (also equal to  +---------------+---------------+
            | departing Inner |  Classic ECN  |    L4S ECN    |
            |     Header)     |     Mode      |     Mode      |
            +-----------------+---------------+---------------+
            |    Not-ECT      |   ECT(0)      |    ECT(1)     |
            |     ECT(0)      |   ECT(0)      |    ECT(0)     |
            |     ECT(1)      |   ECT(1)      |    ECT(1)     |
            |       CE        |     CE        |      CE       |
            +-----------------+---------------+---------------+
PROPOSED:

   Then, if the resul=
ting NSH ECN field is Not-ECT, the ingress SHOULD
   set it to ECT(0). This indicates that, even thou=
gh the end-to-end=20
   transport is not ECN-capable, the egress and ingress of the SFC
   domain are acting as an ECN-capable transport. This approach will
   inherently support all known variants of ECN, including the=20
   experimental L4S capability [RFC8311], [ec=
nL4S].=20
...=C2=A0

            +--------=
---------+---------------+
            | Incoming Header |Departing NSH  |
            | (also equal to  |& Outer Headers|
            | departing Inner |               |
            |     Header)     |               |
            +-----------------+---------------+
            |    Not-ECT      |   ECT(0)      |
            |     ECT(0)      |   ECT(0)      |
            |     ECT(1)      |   ECT(1)      |
            |       CE        |     CE        |
            +-----------------+---------------+


On 15/01/2019= 22:53, Bob Briscoe wrote:
- "I=
t MAY instead be set to ECT(1) if the NSH domain supports the experimental =
L4S capability [RFC8311], [ecnL4S]."
  This sentence is confusing from an implementer's perspective. Does th=
e "MAY" here allow interoperability between the two approaches (R=
FC3168/ RFC8311)? Please clarify in the draft whether ECN-in-NSH-aware node=
s are expected to be implemented as defined in [RFC3168] or as in [RFC8311]=
, or a combination of both.

I agree we =
need to clarify that.
Let me get back to you on this one. I have to admit that I can't remember why we catered for L4S in the way written around table 2. I've checked back, and I actually wrote this part myself, but it looks wrong to me, which would be embarrassing. However, I need to check with my co-authors to confirm that.

Whatever, thanks for picking this up.


Bob

--=
=20
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--0000000000009a0b5105800d34b7-- From nobody Tue Jan 22 08:41:11 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50863130F90 for ; Tue, 22 Jan 2019 08:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 lr544oAvlINs for ; Tue, 22 Jan 2019 08:41:06 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC298130FB2 for ; Tue, 22 Jan 2019 08:41:05 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 43kZ1D1k2tz5w1m for ; Tue, 22 Jan 2019 17:41:04 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 43kZ1C4MnzzDq7V for ; Tue, 22 Jan 2019 17:41:03 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0415.000; Tue, 22 Jan 2019 17:41:03 +0100 From: To: "sfc@ietf.org" Thread-Topic: WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane Thread-Index: AdSxidEM7Qn4dvOISTK6d6Rfr3vfGQA5zR0Q Date: Tue, 22 Jan 2019 16:41:03 +0000 Message-ID: <12156_1548175263_5C47479F_12156_428_1_9E32478DFA9976438E7A22F69B08FF924B791F33@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <18744_1548075971_5C45C3C3_18744_88_1_9E32478DFA9976438E7A22F69B08FF924B7915D3@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <18744_1548075971_5C45C3C3_18744_88_1_9E32478DFA9976438E7A22F69B08FF924B7915D3@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF924B791F33OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 16:41:09 -0000 --_000_9E32478DFA9976438E7A22F69B08FF924B791F33OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, FYI, in BESS we have started the WGLC for draft-ietf-bess-nsh-bgp-control-p= lane. Feel free to comment on our BESS mailing list. Brgds, Stephane, co-chair of BESS. From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Monday, January 21, 2019 14:06 To: bess@ietf.org Cc: bess-chairs@ietf.org Subject: WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-cont= rol-plane Hello Working Group, This email starts a three weeks Working Group Last Call on draft-ietf-bess= -nsh-bgp-control-plane [1]. This poll runs until *the 4th of February*. We are also polling for knowledge of any undisclosed IPR that applies to th= is Document, to ensure that IPR has been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an Author or a Contributor of this Document please res= pond to this email and indicate whether or not you are aware of any relevan= t undisclosed IPR. The Document won't progress without answers from all the= Authors and Contributors. We have several IPRs already disclosed. If you are not listed as an Author or a Contributor, then please explicitly= respond only if you are aware of any IPR that has not yet been disclosed i= n conformance with IETF rules. We are also polling for any existing implementation as per [2]. Thank you, Stephane & Matthew [1] https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-pl= ane/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjq= Dpw ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF924B791F33OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

FYI, in BESS we have s= tarted the WGLC for draft-ietf-bess-nsh-bgp-control-plane.

Feel free to comment o= n our BESS mailing list.

 

Brgds,

 

Stephane, co-chair of = BESS.

 

From: stephane= .litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Monday, January 21, 2019 14:06
To: bess@ietf.org
Cc: bess-chairs@ietf.org
Subject: WGLC, IPR and implementation poll for draft-ietf-bess-nsh-b= gp-control-plane

 

Hello Working Group,

   

This email starts a three weeks Working Group Las= t Call on  draft-ietf-bess-nsh-bgp-control-plane [1].

 

This poll runs until *the 4th of February*.<= /o:p>

 

We are also polling for knowledge of any undisclo= sed IPR that applies to this Document, to ensure that IPR has been disclose= d in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for= more details).

If you are listed as an Author or a Contributor o= f this Document please respond to this email and indicate whether or not yo= u are aware of any relevant undisclosed IPR. The Document won't progress wi= thout answers from all the Authors and Contributors.

 

We have several IPRs already disclosed.

 

If you are not listed as an Author or a Contribut= or, then please explicitly respond only if you are aware of any IPR that ha= s not yet been disclosed in conformance with IETF rules.

 

We are also polling for any existing implementati= on as per [2].

   

    Thank you,

    Stephane & Matthew

 

    [1] https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/=

 

    [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<= o:p>

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF924B791F33OPEXCLILMA4corp_-- From nobody Tue Jan 22 10:15:13 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC7D130DC4 for ; Tue, 22 Jan 2019 10:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.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 dq3JuW-HehVN for ; Tue, 22 Jan 2019 10:15:08 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 CCCD1131002 for ; Tue, 22 Jan 2019 10:15:07 -0800 (PST) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0MI7GlF032585; Tue, 22 Jan 2019 10:15:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=u+Puz/1TVrMboeK9PBNakidTP4LFXubVgaiAFDVhIDg=; b=Q5jy2kcTwsYcCAPWxOTfaBCMcytzfpV8EnZbM8Yam5QG36XXMWOBHd3CHznTdo4cu0UB ZSzItkNRt0i61nVWSsKosKozMAZg4isqaeuPy6NK4okhj97Owtqgg/8FLeq2VERj6BQ8 6b33lupL72gG0HkEj1CyojRepjniE8d3Z1bU7G0n6qsJIwR279N0efhlSHwEcGVY/t2g +Mmtyc0PXDa1Tpw/e9J10rFgtMvFV2hU7R2yG/K+5dkbhuJlNBwhIiKUmdvj62T4saT3 uS+YYgN+/1xD+p7ZHreLgsTe58se9zUFMcCh5beABepFzJvDiY+Gk3EEldQ+gaSrlteQ LQ== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp2056.outbound.protection.outlook.com [104.47.34.56]) by mx0b-00273201.pphosted.com with ESMTP id 2q63m9ghjt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Jan 2019 10:15:05 -0800 Received: from BL0PR05MB5025.namprd05.prod.outlook.com (20.177.241.152) by BL0PR05MB5346.namprd05.prod.outlook.com (10.167.233.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.14; Tue, 22 Jan 2019 18:15:03 +0000 Received: from BL0PR05MB5025.namprd05.prod.outlook.com ([fe80::6df4:7f22:5304:5216]) by BL0PR05MB5025.namprd05.prod.outlook.com ([fe80::6df4:7f22:5304:5216%5]) with mapi id 15.20.1558.016; Tue, 22 Jan 2019 18:15:03 +0000 From: John E Drake To: "stephane.litkowski@orange.com" , "sfc@ietf.org" Thread-Topic: WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane Thread-Index: AdSxidEM7Qn4dvOISTK6d6Rfr3vfGQA5zR0QAANWhkA= Date: Tue, 22 Jan 2019 18:15:03 +0000 Message-ID: References: <18744_1548075971_5C45C3C3_18744_88_1_9E32478DFA9976438E7A22F69B08FF924B7915D3@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <12156_1548175263_5C47479F_12156_428_1_9E32478DFA9976438E7A22F69B08FF924B791F33@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <12156_1548175263_5C47479F_12156_428_1_9E32478DFA9976438E7A22F69B08FF924B791F33@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR05MB5346; 6:9mv2kzjrR8eet3eXFpIofrgn9No/H8zA9CYtMnO27cr/rqjS/pU/7GJ8Ne9E1mD39qh2nbI8eldhCuuT9d/uNRXEIoUatdO1yK3Yu3+a8RRdhN9vRpGBZh3wpzOYpwewBm4TzWGDTbst2vO62Qg3G+ugCxiBj8JLTpOQ5OjAHNKfLGAylwh+TNlkcMHal5PIMRAShcqYnOt8D73p1vt3wWda9Fql7SlKRmcK2agnqRLqZBERfrUokQC+Oq+DQl3z4+U/DDVMt6bZY/lj0pn+AnMqSAjH1h8TTTR8YAwJB9ZLQBrD1/E9OPUgPewc5/7d25j3PxxbN4KeXrBk/TVCo8ZD/rmFb8DxSF7vhqzcUWDcjCMfLdg1VChf7K/PshcGj+zM7YcWoiMdLPq2e/GJWU9vEwD8Wl/PfQTVbgH0Yeenr4eqYBsrOLKOeRuDcJIGfjFOvh5bdF5VLMpMksTv8w==; 5:3iAeKdYUkJcVKC0sZaBdbo+ePYM5L/1v5OtWgD4tjkomiy8yjgcMT8gJfh/wex2foAmWS59ck5tixWfMwC7FkZ6eOMhvj5Z88A4bq88GI2s/hCH4g1Rr218AJ7guCxPSxZKIvQ70AeD57kFYPgC8CuB0g0uZrPxsHBBOfaoQA/Hd3uZHT6IaUvRQW7hYeCKT3Af3jF0jLisOkRmhXO+pcA==; 7:whoqga1v6uLX2Yph4hzG5yzeuIkYOl65jkq+UJc70udHK7MMFPcbNYP9N2a10Gftpf6b5i6IQ7icBDMd8pXE5PhB8pWkmJi0aFRVivs/qvNvasPbJ3aahNlgtv2KnvmOhVG/am7j1KT6Gf09miTROg== x-ms-office365-filtering-correlation-id: 8d731dcc-bf08-4abb-390f-08d6809587ae x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BL0PR05MB5346; x-ms-traffictypediagnostic: BL0PR05MB5346: x-microsoft-antispam-prvs: x-forefront-prvs: 0925081676 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(366004)(376002)(396003)(346002)(199004)(189003)(69234005)(26005)(86362001)(6246003)(186003)(606006)(476003)(8936002)(14454004)(105586002)(966005)(2906002)(478600001)(236005)(7696005)(11346002)(55016002)(97736004)(486006)(74316002)(7736002)(446003)(66066001)(316002)(25786009)(8676002)(102836004)(110136005)(71190400001)(71200400001)(6436002)(53546011)(6506007)(5024004)(256004)(81156014)(2501003)(99286004)(33656002)(6306002)(9686003)(76176011)(790700001)(6116002)(3846002)(106356001)(68736007)(81166006)(229853002)(54896002)(14444005)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR05MB5346; H:BL0PR05MB5025.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: gKMYM86zAdQBeNNtg0lq7jjttiXotq+9CZNfNp8N5dHFgJ+MvZLHqE5oe4DlR8zkb9en4AsHOhMqzn29KXOIacDB6O4jeOz8SG9Z6QNcbClBKSfvlUjh+FcbfJcxGvvWUQJvGoJaCDHIiaauNGQm052tK3gd2LdhrRdhw3bQO9MDCDb3iicdtDc2YZ8ZB7S/2oSItqKsZipgMdQvIY56vdRoEk94LfrDrcC9JxwvS2DmH+iOIoCIaq83kwqnpym12b2jRpTsITxb45MYVZvY3v0Rc9kfEFojtX8Pb4rIRZBsabLOEUXFQBuHvsD1vvc/d25pc2IvBGlldJao+viyE4lDDV6CEqeIINDW7OJh4RIp2/EKiFSXS3EQCx+ymjQNG9+KNAHn5L73z95mI3Q2mfjmu/P4ByoH8kYCRvypq4A= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR05MB50254F313CEE00D0E3B5B98FC7980BL0PR05MB5025namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 8d731dcc-bf08-4abb-390f-08d6809587ae X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2019 18:15:03.2609 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5346 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901220139 Archived-At: Subject: Re: [sfc] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 18:15:12 -0000 --_000_BL0PR05MB50254F313CEE00D0E3B5B98FC7980BL0PR05MB5025namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Yours Irrespectively, John From: sfc On Behalf Of stephane.litkowski@orange.com Sent: Tuesday, January 22, 2019 11:41 AM To: sfc@ietf.org Subject: [sfc] FW: WGLC, IPR and implementation poll for draft-ietf-bess-ns= h-bgp-control-plane Hi WG, FYI, in BESS we have started the WGLC for draft-ietf-bess-nsh-bgp-control-p= lane. Feel free to comment on our BESS mailing list. Brgds, Stephane, co-chair of BESS. From: stephane..litkowski@orange.com= [mailto:stephane.litkowski@orange.com] Sent: Monday, January 21, 2019 14:06 To: bess@ietf.org Cc: bess-chairs@ietf.org Subject: WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-cont= rol-plane Hello Working Group, This email starts a three weeks Working Group Last Call on draft-ietf-bess= -nsh-bgp-control-plane [1]. This poll runs until *the 4th of February*. We are also polling for knowledge of any undisclosed IPR that applies to th= is Document, to ensure that IPR has been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an Author or a Contributor of this Document please res= pond to this email and indicate whether or not you are aware of any relevan= t undisclosed IPR. The Document won't progress without answers from all the= Authors and Contributors. We have several IPRs already disclosed. If you are not listed as an Author or a Contributor, then please explicitly= respond only if you are aware of any IPR that has not yet been disclosed i= n conformance with IETF rules. We are also polling for any existing implementation as per [2]. Thank you, Stephane & Matthew [1] https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-pl= ane/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjq= Dpw ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_BL0PR05MB50254F313CEE00D0E3B5B98FC7980BL0PR05MB5025namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

Yours Irrespectively,

 

John

 

From: sfc <sfc-bounces@ietf.org> On = Behalf Of stephane.litkowski@orange.com
Sent: Tuesday, January 22, 2019 11:41 AM
To: sfc@ietf.org
Subject: [sfc] FW: WGLC, IPR and implementation poll for draft-ietf-= bess-nsh-bgp-control-plane

 

Hi WG,

 

FYI, in BESS we have s= tarted the WGLC for draft-ietf-bess-nsh-bgp-control-plane.

Feel free to comment o= n our BESS mailing list.

 

Brgds,

 

Stephane, co-chair of = BESS.

 

From: stephane..litkowski@orang= e.com [mailto:stephane= .litkowski@orange.com]
Sent: Monday, January 21, 2019 14:06
To: bess@ietf.org
Cc: bess-chairs@ietf.org=
Subject: WGLC, IPR and implementation poll for draft-ietf-bess-nsh-b= gp-control-plane

 

Hello Working Group,

   

This email starts a three weeks Working Group Las= t Call on  draft-ietf-bess-nsh-bgp-control-plane [1].

 

This poll runs until *the 4th of February*.<= /o:p>

 

We are also polling for knowledge of any undisclo= sed IPR that applies to this Document, to ensure that IPR has been disclose= d in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for= more details).

If you are listed as an Author or a Contributor o= f this Document please respond to this email and indicate whether or not yo= u are aware of any relevant undisclosed IPR. The Document won't progress wi= thout answers from all the Authors and Contributors.

 

We have several IPRs already disclosed.

 

If you are not listed as an Author or a Contribut= or, then please explicitly respond only if you are aware of any IPR that ha= s not yet been disclosed in conformance with IETF rules.

 

We are also polling for any existing implementati= on as per [2].

   

    Thank you,

    Stephane & Matthew

 

    [1] https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/=

 

    [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<= o:p>

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_BL0PR05MB50254F313CEE00D0E3B5B98FC7980BL0PR05MB5025namp_-- From nobody Tue Jan 22 11:19:24 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2212E130F79 for ; Tue, 22 Jan 2019 11:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 jAYDtO0-3KIi for ; Tue, 22 Jan 2019 11:19:21 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 004E7130F1B for ; Tue, 22 Jan 2019 11:19:20 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x0MJH6NJ031273; Tue, 22 Jan 2019 14:19:20 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2q67pfkbe0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Jan 2019 14:19:19 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0MJJIfC003515; Tue, 22 Jan 2019 14:19:18 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x0MJJEW1003474; Tue, 22 Jan 2019 14:19:15 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id CDD8A4039448; Tue, 22 Jan 2019 19:19:14 +0000 (GMT) Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (unknown [130.9.129.149]) by zlp27128.vci.att.com (Service) with ESMTPS id B782B4039447; Tue, 22 Jan 2019 19:19:14 +0000 (GMT) Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.110]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0415.000; Tue, 22 Jan 2019 14:19:14 -0500 From: "UTTARO, JAMES" To: John E Drake , "stephane.litkowski@orange.com" , "sfc@ietf.org" Thread-Topic: WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane Thread-Index: AdSxidEM7Qn4dvOISTK6d6Rfr3vfGQA5zR0QAANWhkAAAjyckA== Date: Tue, 22 Jan 2019 19:19:14 +0000 Message-ID: References: <18744_1548075971_5C45C3C3_18744_88_1_9E32478DFA9976438E7A22F69B08FF924B7915D3@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <12156_1548175263_5C47479F_12156_428_1_9E32478DFA9976438E7A22F69B08FF924B791F33@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.65.151.163] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F4D7F5A95MISOUT7MSGUSRCD_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901220145 Archived-At: Subject: Re: [sfc] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 19:19:23 -0000 --_000_B17A6910EEDD1F45980687268941550F4D7F5A95MISOUT7MSGUSRCD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Thanks, Jim Uttaro From: sfc On Behalf Of John E Drake Sent: Tuesday, January 22, 2019 1:15 PM To: stephane.litkowski@orange.com; sfc@ietf.org Subject: Re: [sfc] WGLC, IPR and implementation poll for draft-ietf-bess-ns= h-bgp-control-plane Support Yours Irrespectively, John From: sfc > On Behalf Of = stephane.litkowski@orange.com Sent: Tuesday, January 22, 2019 11:41 AM To: sfc@ietf.org Subject: [sfc] FW: WGLC, IPR and implementation poll for draft-ietf-bess-ns= h-bgp-control-plane Hi WG, FYI, in BESS we have started the WGLC for draft-ietf-bess-nsh-bgp-control-p= lane. Feel free to comment on our BESS mailing list. Brgds, Stephane, co-chair of BESS. From: stephane..litkowski@orange.com= [mailto:stephane..litkowski@orange.com] Sent: Monday, January 21, 2019 14:06 To: bess@ietf.org Cc: bess-chairs@ietf.org Subject: WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-cont= rol-plane Hello Working Group, This email starts a three weeks Working Group Last Call on draft-ietf-bess= -nsh-bgp-control-plane [1]. This poll runs until *the 4th of February*. We are also polling for knowledge of any undisclosed IPR that applies to th= is Document, to ensure that IPR has been disclosed in compliance with IETF = IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an Author or a Contributor of this Document please res= pond to this email and indicate whether or not you are aware of any relevan= t undisclosed IPR. The Document won't progress without answers from all the= Authors and Contributors. We have several IPRs already disclosed. If you are not listed as an Author or a Contributor, then please explicitly= respond only if you are aware of any IPR that has not yet been disclosed i= n conformance with IETF rules. We are also polling for any existing implementation as per [2]. Thank you, Stephane & Matthew [1] https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-pl= ane/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjq= Dpw ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_B17A6910EEDD1F45980687268941550F4D7F5A95MISOUT7MSGUSRCD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

Thanks,

  &nbs= p;           Jim Uttaro

 

From: sfc <sfc-bounces@ietf.org> On = Behalf Of John E Drake
Sent: Tuesday, January 22, 2019 1:15 PM
To: stephane.litkowski@orange.com; sfc@ietf.org
Subject: Re: [sfc] WGLC, IPR and implementation poll for draft-ietf-= bess-nsh-bgp-control-plane

 

Support

 

Yours Irrespectively,

 

John

 

From: sfc <sfc-bounces@ietf.org> On Behalf Of stepha= ne.litkowski@orange.com
Sent: Tuesday, January 22, 2019 11:41 AM
To: sfc@ietf.org
Subject: [sfc] FW: WGLC, IPR and implementation poll for draft-ietf-= bess-nsh-bgp-control-plane

 

Hi WG,

 

FYI, in BESS we have s= tarted the WGLC for draft-ietf-bess-nsh-bgp-control-plane.

Feel free to comment o= n our BESS mailing list.

 

Brgds,

 

Stephane, co-chair of = BESS.

 

From: stephane..litkowski@orang= e.com [mailto:stephane= ..litkowski@orange.com]
Sent: Monday, January 21, 2019 14:06
To: bess@ietf.org
Cc: bess-chairs@ietf.org=
Subject: WGLC, IPR and implementation poll for draft-ietf-bess-nsh-b= gp-control-plane

 

Hello Working Group,

   

This email starts a three weeks Working Group Las= t Call on  draft-ietf-bess-nsh-bgp-control-plane [1].

 

This poll runs until *the 4th of February*.<= /o:p>

 

We are also polling for knowledge of any undisclo= sed IPR that applies to this Document, to ensure that IPR has been disclose= d in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for= more details).

If you are listed as an Author or a Contributor o= f this Document please respond to this email and indicate whether or not yo= u are aware of any relevant undisclosed IPR. The Document won't progress wi= thout answers from all the Authors and Contributors.

 

We have several IPRs already disclosed.

 

If you are not listed as an Author or a Contribut= or, then please explicitly respond only if you are aware of any IPR that ha= s not yet been disclosed in conformance with IETF rules.

 

We are also polling for any existing implementati= on as per [2].

   

    Thank you,

    Stephane & Matthew

 

    [1] https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/=

 

    [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw<= o:p>

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_B17A6910EEDD1F45980687268941550F4D7F5A95MISOUT7MSGUSRCD_-- From nobody Tue Jan 22 22:22:58 2019 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E44C130DFA; Tue, 22 Jan 2019 22:22:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: martin.vigoureux@nokia.com, tal.mizrahi.phd@gmail.com, sfc-chairs@ietf.org, sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154822457647.13175.11898836000808295251.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2019 22:22:56 -0800 Archived-At: Subject: [sfc] sfc - New Meeting Session Request for IETF 104 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 06:22:57 -0000 A new meeting session request has just been submitted by Tal Mizrahi, a Secretary of the sfc working group. --------------------------------------------------------- Working Group Name: Service Function Chaining Area Name: Routing Area Session Requester: Tal Mizrahi Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: bess idr i2nsf ippm mpls spring rtgwg lisp ntp teas People who must be present: Joel M. Halpern Jim Guichard Martin Vigoureux Tal Mizrahi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 23 05:37:45 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216AD12DF71; Wed, 23 Jan 2019 05:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hsOXslp-O7K2; Wed, 23 Jan 2019 05:37:40 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889CC12F1A2; Wed, 23 Jan 2019 05:37:40 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 43l5v64QxyzFqb1; Wed, 23 Jan 2019 14:37:38 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 43l5v639L6zBrLf; Wed, 23 Jan 2019 14:37:38 +0100 (CET) Received: from OPEXCAUBM5E.corporate.adroot.infra.ftgroup (10.114.13.82) by OPEXCLILM7F.corporate.adroot.infra.ftgroup (10.114.31.60) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 23 Jan 2019 14:37:38 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([fe80::849f:f804:b713:d99a%21]) with mapi id 14.03.0415.000; Wed, 23 Jan 2019 14:37:37 +0100 From: To: "Joel M. Halpern" , "Andrew G. Malis" CC: "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" Thread-Index: AQHUsl5GMzWxkj4FXEaGF7rAdp1P+6W81mRw Date: Wed, 23 Jan 2019 13:37:37 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 13:37:43 -0000 SGkgSm9lbCwNCg0KVGhlIHBvaW50IEpvZWwgaXMgU0ZGcyBoYXMgdG8gcHJlc2VydmUgd2hhdGV2 ZXIgRFNDUCBtYXJraW5nIHdoZW4gZW5jYXBzdWxhdGluZy9lbmNhcHN1bGF0aW9uIChpbmNsdWRp bmcgY2FzZXMgd2hlcmUgdHJhbnNwb3J0IGVuY2FwIGNoYW5nZXMpLg0KDQpJZiB5b3Ugd2lsbCwg d2UgY2FuIGRlc2NyaWJlIHRoZSBzY2VuYXJpbyB1c2luZyB5b3VyIHdvcmRzOiAgDQoNCj09PT09 PT0NCkNvbnNpZGVyIGFuIFNGRiB0aGF0IHJlY2VpdmVzIGEgcGFja2V0IHdpdGggYSB0cmFuc3Bv cnQgRFNDUCBtYXJraW5nDQphbmQgYW4gTlNIIGhlYWRlci4gIFRoYXQgU0ZGIHJlbW92ZXMgdGhl IHRyYW5zcG9ydCBoZWFkZXIuICBJdCB0aGVuDQoodXN1YWxseSkgc2VuZHMgdGhlIHBhY2tldCB2 aWEgc29tZSBvdGhlciBtZWFucyB0byBhbiBTRiwgYW5kIGdldHMgdGhlDQpwYWNrZXQgYmFjay4g IEFmdGVyIHdoaWNoIGl0IHNlbmRzIGl0IG9uIHRvIHRoZSBuZXh0IFNGRiB3aXRoIGEgbmV3DQp0 cmFuc3BvcnQgaGVhZGVyIGNhcnJ5aW5nIHRoZSBOU0guDQpMZXQgdXMgdGFrZSBhcyBnaXZlbiB0 aGF0IHdlIHdhbnQgdG8gc3VwcG9ydCBEU0NQIG1hcmtpbmcgcHJlc2VydmF0aW9uLg0KVGhlbiB3 ZSBuZWVkIHRvIHNvbWVob3cgcHJlc2VydmUgdGhlIERTQ1AgaW5mb3JtYXRpb24gdGhhdCB0aGUg U0ZGDQpyZWNlaXZlcy4NCj09PT09PT09PT0NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBq b2VsaGFscGVybi5jb21dDQo+IEVudm95w6nCoDogbWFyZGkgMjIgamFudmllciAyMDE5IDEzOjMx DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IEFuZHJldyBHLiBNYWxpcw0KPiBD Y8KgOiBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnOyBzZmNAaWV0 Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNlZCBkcmFmdC1l YXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0IGluDQo+IHN0YXRlICJDYW5kaWRhdGUgZm9yIFdH IEFkb3B0aW9uIg0KPiANCj4gKGFnYWluOiBzcGVha2luZyBwZXJzb25hbGx5KQ0KPiBEU0NQIGJl aGF2aW9yIGlzIFZFUlkgZGlmZmVyZW50IGZyb20gRUNOIGJlaGF2aW9yIGluIHRlcm1zIG9mDQo+ IGludGVybWVkaWF0ZSByb3V0ZXIgbW9kaWZpY2F0aW9uLiAgRFNDUHMgbWF5IGdldCByZXdyaXR0 ZW4gYXQgY2VydGFpbg0KPiBzcGVjaWZpYyBwbGFjZXMsIGJ1dCBub3QgZ2VuZXJhbGx5IGF0IGlu dGVyaW9yIHJvdXRlcnMuICBTbyBtYXBwaW5nIGZyb20NCj4gdGhlIGludGVyaW9yIHBhY2tldCBE U0NQIHRvIHRoZSBleHRlcmlvciBwYWNrZXQgRFNDUCBhbmQgSUVFRSBtYXJraW5nIGlzDQo+IG5v cm1hbCBhbmQgc2FmZS4gIHRoZXJlIGlzIG5vIG5lZWQgdG8gcmV2ZXJzZSB0aGUgcHJvY2Vzcy4g IEVDTiBtYXJraW5nDQo+IG5lZWRzIHRvIHJldmVyc2UgdGhlIHByb2Nlc3MgZHVlIHRvIHRoZSBm YWN0IHRoYXQgaW5kaXZpZHVhbCByb3V0ZXJzIGFyZQ0KPiBleHBlY3RlZCB0byBjaGFuZ2UgdGhl IG1hcmtpbmcgYmFzZWQgb24gbG9jYWwgY29uZGl0aW9ucy4NCj4gDQo+IEF0IGxlYXN0IHRoYWF0 IGlzIGhvdyBJIHVuZGVyc3RhbmQgaXQsDQo+IEpvZWwNCj4gDQo+IE9uIDEvMjIvMTkgMToyNSBB TSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPiBIaSBKb2VsLA0KPiA+ DQo+ID4gV2hhdCBtYWtlcyBFQ04gc3BlY2lmaWMgaW4gdGhpcyByZWdhcmRzIGNvbXBhcmVkIHRv IERTQ1AgbWFya2luZw0KPiBwcmVzZXJ2YXRpb24/DQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVk DQo+ID4NCj4gPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+IERlwqA6IEpvZWwg TS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+ID4+IEVudm95w6nCoDog dmVuZHJlZGkgMTggamFudmllciAyMDE5IDE1OjU1DQo+ID4+IMOAwqA6IEJPVUNBREFJUiBNb2hh bWVkIFRHSS9PTE47IEFuZHJldyBHLiBNYWxpcw0KPiA+PiBDY8KgOiBkcmFmdC1lYXN0bGFrZS1z ZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gPj4gT2JqZXTCoDog UmU6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNlZCBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVj bi1zdXBwb3J0DQo+IGluDQo+ID4+IHN0YXRlICJDYW5kaWRhdGUgZm9yIFdHIEFkb3B0aW9uIg0K PiA+Pg0KPiA+PiA8Y2hhaXIgaGF0IG9mZj4NCj4gPj4gTGV0IG1lIHRyeSBhcyBhbiBpbmRpdmlk dWFsIHRvIHBhcmFwaHJhc2Ugd2hhdCBJIHVuZGVyc3RhbmQgdGhlIGRvY3VtZW50DQo+ID4+IHRv IGJlIG9mZmVyaW5nLiAgVGhhdCBhdXRob3JzIHNob3VsZCBmZWVsIGZyZWUgdG8gY29tbWVudCBm dXJ0aGVyDQo+ID4+IGluY2x1ZGluZyBpZiBuZWNlc3NhcnkgdGVsbGluZyBtZSB0aGF0IEkgYW0g Y29uZnVzZWQuDQo+ID4+DQo+ID4+IENvbnNpZGVyIGFuIFNGRiB0aGF0IHJlY2VpdmVzIGEgcGFj a2V0IHdpdGggYSB0cmFuc3BvcnQgRUNOIGluZGljYXRpb24NCj4gPj4gYW5kIGFuIE5TSCBoZWFk ZXIuICBUaGF0IFNGRiByZW1vdmVzIHRoZSB0cmFuc3BvcnQgaGVhZGVyLiAgSXQgdGhlbg0KPiA+ PiAodXN1YWxseSkgc2VuZHMgdGhlIHBhY2tldCB2aWEgc29tZSBvdGhlciBtZWFucyB0byBhbiBT RiwgYW5kIGdldHMgdGhlDQo+ID4+IHBhY2tldCBiYWNrLiAgQWZ0ZXIgd2hpY2ggaXQgc2VuZHMg aXQgb24gdG8gdGhlIG5leHQgU0ZGIHdpdGggYSBuZXcNCj4gPj4gdHJhbnNwb3J0IGhlYWRlciBj YXJyeWluZyB0aGUgTlNILg0KPiA+PiBMZXQgdXMgdGFrZSBhcyBnaXZlbiB0aGF0IHdlIHdhbnQg dG8gc3VwcG9ydCBlZmZlY3RpdmUgRUNOLg0KPiA+PiBUaGVuIHdlIG5lZWQgdG8gc29tZWhvdyBw cmVzZXJ2ZSB0aGUgRUNOIGluZm9ybWF0aW9uIHRoYXQgdGhlIFNGRg0KPiByZWNlaXZlcy4NCj4g Pj4NCj4gPj4gT25lIHdheSB3b3VsZCBiZSB0byBpbnNpc3QgdGhhdCB0aGUgU0ZGLCB3aGVuIGl0 IHJlY2VpdmVzIHRoZSBFQ04NCj4gPj4gaW5mb3JtYXRpb24sIGhhcyB0byBydW1tYWdlIHRocm91 Z2ggdG8gZmluZCB0aGUgaW50ZXJuYWwgSVAgcGFja2V0LCBhbmQNCj4gPj4gbXVzdCB1cGRhdGUg dGhlIGludGVybmFsIEVDTiBpbmZvcm1hdGlvbiB0aGVyZWluLiAgVWdnLiAgSVRoYXQgd291bGQg YmUNCj4gPj4gYSBwcmV0dHkgb25lcm91cyByZXF1aXJlbWVudC4NCj4gPj4NCj4gPj4gSW5zdGVh ZCwgdGhlIGRvY3VtZW50IHN1Z2dlc3RzIHRoYXQgdGhlIFNGRiB0cmFuc2ZlciB0aGUgbWFya2lu ZyB0byB0aGUNCj4gPj4gTlNIIGhlYWRlciwgYW5kIHRoZW4gdXNlIHRoYXQgTlNIIG1hcmtpbmcg d2hlbiBpdCBnZW5lcmF0ZXMgdGhlIG5ldw0KPiA+PiB0cmFuc3BvcnQgaGVhZGVyLiAgVGhpcyBj YW4gdGhlbiBiZSB1c2VkIHdoZW4gdGhlIHBhY2tldCBleGl0cyB0aGUgTlNIDQo+ID4+IGRvbWFp biB0byBwcm9wYWdhdGUgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBoZWFkZXIgKHdoaWNoIGlzIGJ5 DQo+ID4+IGRlZmluaXRpb24gZXhwb3NlZCB3aGVuIHRoZSBOU0ggaGVhZGVyIGlzIHJlbW92ZWQu KQ0KPiA+Pg0KPiA+PiBNZWQsIGlmIEkgdW5kZXJzdGFuZCB5b3UgcHJvcGVybHkgeW91IGFyZSBz dWdnZXN0aW5nIHRoYXQgdGhlIFNGRiBzaG91bGQNCj4gPj4gc29tZWhvdyBrZWVwIHRoZSBpbmZv cm1hdGlvbiBmcm9tIHRoZSB0cmFuc3BvcnQgaGVhZGVyIGFzc29jaWF0ZWQgd2l0aA0KPiA+PiB0 aGUgcGFja2V0LCBidXQgbm90IGluIHRoZSBOU0ggaGVhZGVyLiAgSW4gc29tZSBTRkYgaW1wbGVt ZW50YXRpb25zLCBhbmQNCj4gPj4gd2l0aCBzb21lIHdheXMgb2Ygd29ya2luZyB3aXRoIFNGcywg dGhhdCBpcyBkb2FibGUuICBSZXF1aXJpbmcgdGhhdA0KPiA+PiB3b3VsZCBsaW1pdCB0aGUgaW1w bGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgY2hvaWNlcy4NCj4gPj4NCj4gPj4gPGNoYWlyIGhh dCBzb21ld2hlcmU+DQo+ID4+IFlvdXJzLA0KPiA+PiBKb2VsDQo+ID4+DQo+ID4+IE9uIDEvMTgv MTkgNDoxNSBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPj4+IEhp IEFuZHksDQo+ID4+Pg0KPiA+Pj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4+Pg0KPiA+Pj4gQ2hl ZXJzLA0KPiA+Pj4NCj4gPj4+IE1lZA0KPiA+Pj4NCj4gPj4+ICpEZcKgOipzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10gKkRlIGxhIHBhcnQgZGUqIEFuZHJldyBHLiBNYWxpcw0KPiA+ Pj4gKkVudm95w6nCoDoqIGpldWRpIDE3IGphbnZpZXIgMjAxOSAxNjozMw0KPiA+Pj4gKsOAwqA6 KiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+ID4+PiAqQ2PCoDoqIHNmYy1jaGFpcnNAaWV0 Zi5vcmc7IElFVEYgU2VjcmV0YXJpYXQ7DQo+ID4+PiBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVj bi1zdXBwb3J0QGlldGYub3JnOyBzZmNAaWV0Zi5vcmcNCj4gPj4+ICpPYmpldMKgOiogUmU6IFtz ZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNlZA0KPiA+Pj4gZHJhZnQtZWFzdGxha2Utc2ZjLW5zaC1l Y24tc3VwcG9ydCBpbiBzdGF0ZSAiQ2FuZGlkYXRlIGZvciBXRyBBZG9wdGlvbiINCj4gPj4+DQo+ ID4+PiBNZWQsDQo+ID4+Pg0KPiA+Pj4gWW91ciBwb2ludCBhYm91dCBSRkMgNTEyOSBpcyBjb3Jy ZWN0LCBidXQgSSdtIG5vdCBwZXJzb25hbGx5IGF3YXJlIG9mDQo+ID4+PiBhbnkgaW1wbGVtZW50 YXRpb25zLiBBbmQgSSB3YXMganVzdCB1c2luZyBNUExTIGFzIGFuIGV4YW1wbGUsIHRoZXJlIG1h eQ0KPiA+Pj4gYmUgb3RoZXJzIGluIHRoZSBmdXR1cmUgYXMgd2VsbC4NCj4gPj4+DQo+ID4+PiBb TWVkXSBJIHVuZGVyc3Rvb2QgdGhpcyB3YXMgYW4gZXhhbXBsZSwgYnV0IHN0aWxsIHRoaXMgaXMg SU1ITyBzdXBwb3NlZA0KPiA+Pj4gdG8gYmUgaGFuZGxlZCBhbW9uZyB0aGUgc3Bpcml0IG9mIHRo ZSBlZmZvcnQgbGVkIGJ5IEJvYiBpbiA2MDQwIGFuZCBpdHMNCj4gPj4+IGN1cnJlbnQgJiBmdXR1 cmVzIHVwZGF0ZXMuDQo+ID4+Pg0KPiA+Pj4gWW91ciBwb2ludCBhYm91dCB0aGUgU0ZGIHByZXNl cnZpbmcgRUNOIGlzIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudCwgZm9yDQo+ID4+PiBleGFtcGxl IHRoZSBTRkYgY291bGQgaGF2ZSBzZXBhcmF0ZSBpbnB1dCBhbmQgb3V0cHV0IGludGVyZmFjZXMg d2l0aG91dA0KPiA+Pj4gc2hhcmVkIG1lbW9yeSwgb3IgdGhlIHRyYW5zcG9ydCBlbmNhcHN1bGF0 aW9uIGNvdWxkIGNoYW5nZSBpbiBkaWZmZXJlbnQNCj4gPj4+IHJlZ2lvbnMgb2YgdGhlIFNGQyBk b21haW4uDQo+ID4+Pg0KPiA+Pj4gW01lZF0gSSBkb27igJl0IHVuZGVyc3RhbmQgeW91ciBwb2lu dCBhYm91dCBzZXBhcmF0ZSBpbnB1dHMvb3V0cHV0DQo+ID4+PiBpbnRlcmZhY2VzIGFuZCB0aGUg Y2hhbmdlIG9mIGVuY2FwIHNjaGVtZXMuIExldOKAmXMgcHV0IGFzaWRlIFNGQyBmb3IgYQ0KPiA+ Pj4gbW9tZW50IGFuZCBjb25zaWRlciB0aGUgZXhhbXBsZSBvZiBhIExJU1AgWFRSIHdoaWNoIGlz IHN1cHBvcnRpbmcgRUNODQo+ID4+PiBkaXNzZW1pbmF0aW9uL2hhbmRsaW5nLiBUaGF0IHhUUiBt YXkgbm90IHVzZSB0aGUgc2FtZSBpbi9vdXQgaW50ZXJmYWNlcywNCj4gPj4+IGJ1dCBzdGlsbCBu ZWVkIHRvIGFjaGlldmUgc29tZSBwcm9jZXNzaW5nIHdoZW4gZG9pbmcgaXRzIGVuY2FwL2RlY2Fw Lg0KPiA+Pj4NCj4gPj4+IEl0J3MgZGlmZmljdWx0IHRvIGRlcGVuZCBvbiBTRkZzIGJlaW5nIGFi bGUgdG8gcHJlc2VydmUNCj4gPj4+IHRyYW5zcG9ydC1oZWFkZXItZGVwZW5kZW50IGluZm9ybWF0 aW9uIHdpdGhvdXQgdGhhdCBiZWNvbWluZyBhDQo+ID4+PiByZXF1aXJlbWVudCBpbiB0aGUgU0ZD IGFyY2hpdGVjdHVyZS4NCj4gPj4+DQo+ID4+PiBbTWVkXSBJIGRvbuKAmXQgdGhpbmsgdGhhdCB3 ZSBjYW4gdGFnIGNvbmdlc3Rpb24gbm90aWZpY2F0aW9uIGFzDQo+ID4+PiDigJx0cmFuc3BvcnQt aGVhZGVyLWRlcGVuZGVudOKAnS4gVGhlcmUgYXJlIHdheXMgdG8gcGFzcyB0aGF0IGluZm8gZXZl biB3aGVuDQo+ID4+PiB0aGUgdHJhbnNwb3J0IGVuY2FwIGNoYW5nZXMuDQo+ID4+Pg0KPiA+Pj4g VGhpcyBpcyBJTUhPIGFtb25nIHRoaW5ncyB0aGF0IHRoZSBXRyBpcyBzdXBwb3NlZCB0byBjb3Zl ciB1bmRlciB0aGlzDQo+ID4+PiBpdGVtIGluIHRoZSBjaGFydGVyIChwbGVhc2Ugbm90ZSB0aGF0 IHRob3NlIGFyZSBjbGVhcmluZyB0YWdlZCBhcw0KPiA+Pj4gdHJhbnNwb3J0IGlzc3Vlcyk6DQo+ ID4+Pg0KPiA+Pj4gPT0NCj4gPj4+DQo+ID4+PiA0KSBUcmFuc3BvcnQgQ29uc2lkZXJhdGlvbnMg LSBUaGlzIHdpbGwgY2FwdHVyZSB0aGUgZXhwZWN0YXRpb25zIFNGQw0KPiA+Pj4gcGxhY2VzIG9u IHRyYW5zcG9ydCBiZWhhdmlvciwgaW5jbHVkaW5nIGRlYWxpbmcgd2l0aCBpc3N1ZXMgc3VjaCBh cw0KPiA+Pj4gY29uZ2VzdGlvbiBpbmRpY2F0aW9ucyBhbmQgcmVzcG9uc2VzLg0KPiA+Pj4NCj4g Pj4+ID09DQo+ID4+Pg0KPiA+Pj4gQ2hlZXJzLA0KPiA+Pj4NCj4gPj4+IEFuZHkNCj4gPj4+DQo+ ID4+PiBPbiBUaHUsIEphbiAxNywgMjAxOSBhdCAxMDowMiBBTSA8bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbQ0KPiA+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4g d3JvdGU6DQo+ID4+Pg0KPiA+Pj4gICAgICBIaSBBbmR5LA0KPiA+Pj4NCj4gPj4+ICAgICAgUGxl YXNlIHNlZSBpbmxpbmUuDQo+ID4+Pg0KPiA+Pj4gICAgICBDaGVlcnMsDQo+ID4+Pg0KPiA+Pj4g ICAgICBNZWQNCj4gPj4+DQo+ID4+PiAgICAgICpEZcKgOipBbmRyZXcgRy4gTWFsaXMgW21haWx0 bzphZ21hbGlzQGdtYWlsLmNvbQ0KPiA+Pj4gICAgICA8bWFpbHRvOmFnbWFsaXNAZ21haWwuY29t Pl0NCj4gPj4+ICAgICAgKkVudm95w6nCoDoqIGpldWRpIDE3IGphbnZpZXIgMjAxOSAxNTo1MA0K PiA+Pj4gICAgICAqw4DCoDoqIEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gPj4+ICAgICAg KkNjwqA6KiBJRVRGIFNlY3JldGFyaWF0OyBzZmMtY2hhaXJzQGlldGYub3JnDQo+ID4+PiAgICAg IDxtYWlsdG86c2ZjLWNoYWlyc0BpZXRmLm9yZz47DQo+ID4+PiAgICAgIGRyYWZ0LWVhc3RsYWtl LXNmYy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmcNCj4gPj4+ICAgICAgPG1haWx0bzpkcmFmdC1l YXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnPjsgc2ZjQGlldGYub3JnDQo+ID4+ PiAgICAgIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+Pj4gICAgICAqT2JqZXTCoDoqIFJlOiBb c2ZjXSBUaGUgU0ZDIFdHIGhhcyBwbGFjZWQNCj4gPj4+ICAgICAgZHJhZnQtZWFzdGxha2Utc2Zj LW5zaC1lY24tc3VwcG9ydCBpbiBzdGF0ZSAiQ2FuZGlkYXRlIGZvciBXRw0KPiBBZG9wdGlvbiIN Cj4gPj4+DQo+ID4+PiAgICAgIE1lZCwNCj4gPj4+DQo+ID4+PiAgICAgIE5vdCBhbGwgdHJhbnNw b3J0cyBzdXBwb3J0IEVDTiBtYXJraW5nLCBmb3IgZXhhbXBsZSBOU0ggb3ZlciBNUExTLg0KPiA+ Pj4NCj4gPj4+ICAgICAgW01lZF0gSXNu4oCZdCB0aGlzIGNvdmVyZWQgYnkgUkZDNTEyOT8NCj4g Pj4+DQo+ID4+PiAgICAgIEFuZCBldmVuIHdoZXJlIHRoZSB0cmFuc3BvcnQgc3VwcG9ydHMgRUNO IG1hcmtpbmcsIG5vdGUgdGhlIGV4YW1wbGUNCj4gPj4+ICAgICAgaW4gRmlndXJlIDEgaW4gdGhl IGRyYWZ0IHdoZXJlIHRoZSBvdXRlciBlbmNhcHN1bGF0aW9uIGNhbiBiZQ0KPiA+Pj4gICAgICBz dHJpcHBlZCBkdXJpbmcgU0ZGIHByb2Nlc3NpbmcuIEluIHRoYXQgY2FzZSwgdGhlIHNjb3BlIG9m IHRoZSBFQ04NCj4gPj4+ICAgICAgbWFya2luZyBpcyBsaW1pdGVkIHRvIGluZGl2aWR1YWwgU0ZG LVNGRiBsaW5rcy4gcmF0aGVyIHRoYW4gZW5kLXRvLQ0KPiBlbmQuDQo+ID4+Pg0KPiA+Pj4gICAg ICBbTWVkXSBXaHkgY291bGRu4oCZdCBTRkYgcHJlc2VydmUgRUNOIHdoZW4gZG9pbmcgaXRzIHRy YW5zcG9ydA0KPiA+Pj4gICAgICBkZWNhcC9lbmNhcD8NCj4gPj4+DQo+ID4+PiAgICAgIENoZWVy cywNCj4gPj4+DQo+ID4+PiAgICAgIEFuZHkNCj4gPj4+DQo+ID4+PiAgICAgIE9uIFRodSwgSmFu IDE3LCAyMDE5IGF0IDk6MTIgQU0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPj4+ ICAgICAgPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+ID4+ Pg0KPiA+Pj4gICAgICAgICAgSGkgYWxsLA0KPiA+Pj4NCj4gPj4+ICAgICAgICAgIEkgZG8gdGhp bmsgdGhhdCBFQ04gaXMgbmF0dXJhbGx5IGJldHRlciBoYW5kbGVkIGF0IHRoZSB0cmFuc3BvcnQN Cj4gPj4+ICAgICAgICAgIGVuY2Fwc3VsYXRpb24gaW5zdGVhZCBvZiB0aGUgTlNIIGl0c2VsZi4N Cj4gPj4+DQo+ID4+PiAgICAgICAgICBSZXF1aXJpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgdG8gYmUg aGFuZGxlZCBhdCB0aGUgdHJhbnNwb3J0IGVuY2FwDQo+ID4+PiAgICAgICAgICAoZHJhZnQtaWV0 Zi10c3Z3Zy1yZmM2MDQwdXBkYXRlLXNoaW0pIGFuZCBOU0ggaXMgcmVkdW5kYW50LCBJTU8uDQo+ ID4+Pg0KPiA+Pj4gICAgICAgICAgSSBsaWtlIHRoZSBhcHByb2FjaCB3ZSBzZXQgaW4gdGhlIFNG QyBhcmNoaXRlY3R1cmUgaW4gd2hpY2ggd2UNCj4gPj4+ICAgICAgICAgIHNlcGFyYXRlZCBzZXJ2 aWNlIG1hdHRlcnMgZnJvbSB0cmFuc3BvcnQgb25lcy4gSSdkIHZvdGUgZm9yDQo+ID4+PiAgICAg ICAgICBtYWludGFpbmluZyB0aGF0IHNlcGFyYXRpb24gY2xlYW5lciBhcyBpdCB3YXMgc2V0IGlu IHRoZSBhcmNoDQo+IFJGQy4NCj4gPj4+DQo+ID4+PiAgICAgICAgICBUaGFuayB5b3UuDQo+ID4+ Pg0KPiA+Pj4gICAgICAgICAgQ2hlZXJzLA0KPiA+Pj4gICAgICAgICAgTWVkDQo+ID4+Pg0KPiA+ Pj4gICAgICAgICAgID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+PiAgICAgICAg ICAgPiBEZcKgOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZw0KPiA+Pj4gICAgICAg ICAgPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz5dIERlIGxhIHBhcnQgZGUgSUVURiBTZWNy ZXRhcmlhdA0KPiA+Pj4gICAgICAgICAgID4gRW52b3nDqcKgOiBqZXVkaSAzIGphbnZpZXIgMjAx OSAwNjoxMQ0KPiA+Pj4gICAgICAgICAgID4gw4DCoDogc2ZjLWNoYWlyc0BpZXRmLm9yZyA8bWFp bHRvOnNmYy1jaGFpcnNAaWV0Zi5vcmc+Ow0KPiA+Pj4gICAgICAgICAgZHJhZnQtZWFzdGxha2Ut c2ZjLW5zaC1lY24tc3VwcG9ydEBpZXRmLm9yZw0KPiA+Pj4gICAgICAgICAgPG1haWx0bzpkcmFm dC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnPjsNCj4gPj4+ICAgICAgICAg ICA+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4+ICAgICAgICAgICA+ IE9iamV0wqA6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNlZA0KPiA+Pj4gICAgICAgICAgZHJh ZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydCBpbg0KPiA+Pj4gICAgICAgICAgID4gc3Rh dGUgIkNhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb24iDQo+ID4+PiAgICAgICAgICAgPg0KPiA+Pj4g ICAgICAgICAgID4NCj4gPj4+ICAgICAgICAgICA+IFRoZSBTRkMgV0cgaGFzIHBsYWNlZCBkcmFm dC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0IGluDQo+ID4+IHN0YXRlDQo+ID4+PiAgICAg ICAgICAgPiBDYW5kaWRhdGUgZm9yIFdHIEFkb3B0aW9uIChlbnRlcmVkIGJ5IEpvZWwgSGFscGVy bikNCj4gPj4+ICAgICAgICAgICA+DQo+ID4+PiAgICAgICAgICAgPiBUaGUgZG9jdW1lbnQgaXMg YXZhaWxhYmxlIGF0DQo+ID4+PiAgICAgICAgICAgPg0KPiA+Pj4gICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tDQo+ID4+ IHN1cHBvcnQvDQo+ID4+PiAgICAgICAgICAgPg0KPiA+Pj4gICAgICAgICAgID4gQ29tbWVudDoN Cj4gPj4+ICAgICAgICAgICA+IFRoaXMgc3RhcnRzIHRoZSBXRyBjYWxsIGZvciBhZG9wdGlvbiBv ZiB0aGlzIGRyYWZ0Lg0KPiA+Pj4gICAgICAgICAgID4gUGxlYXNlIHJlc3BvbmQgdG8gdGhlIGxp c3QsIGluZGljYXRpbmcgc3VwcG9ydCBmb3IgdGhpcyBhcyBhDQo+ID4+PiAgICAgICAgICB3b3Jr IGl0ZW0gb2YgdGhlDQo+ID4+PiAgICAgICAgICAgPiB3b3JraW5nIGdyb3VwIHdpdGggdGhpcyBk b2N1bWVudCBhcyB0aGUgYmFzaXMgZm9yIHRoZSB3b3JrLA0KPiA+Pj4gICAgICAgICAgb3Igb2Jq ZWN0aW9uIHRvDQo+ID4+PiAgICAgICAgICAgPiB0aGUgd29ya2luZyBncm91cCBhZG9wdGluZyB0 aGlzIGl0ZW0gYXMgYSB3b3JraW5nIGdyb3VwDQo+IGRyYWZ0Lg0KPiA+Pj4gICAgICAgICAgID4N Cj4gPj4+ICAgICAgICAgICA+IFRoZSBhdXRob3JzIHNob3VsZCBjb25maXJtIHRvIHRoZSBjaGFp cnMgYW5kIFdHIHNlY3JldGFyeQ0KPiA+Pj4gICAgICAgICAgdGhhdCBhbGwgSVBSIGtub3duDQo+ ID4+PiAgICAgICAgICAgPiB0byB0aGVtIHJlbGV2YW50IHRvIHRoaXMgZHJhZnQgaGFzIGJlZW4g ZGlzY2xvc2VkLg0KPiA+Pj4gICAgICAgICAgID4NCj4gPj4+ICAgICAgICAgICA+IFRoZSB3b3Jr aW5nIGdyb3VwIGFkb3B0aW9uIGNhbGwgd2lsbCBsYXN0IDIgd2Vla3MsIGVuZGluZyBhdA0KPiA+ Pj4gICAgICAgICAgdGhlIGVuZCBvZiB0aGUNCj4gPj4+ICAgICAgICAgICA+IGRheSBvbiBUaHVy c2RheSwgSmFudWFyeSAxNyAyMDE5IENPQiBzb21ld2hlcmUuDQo+ID4+PiAgICAgICAgICAgPg0K PiA+Pj4gICAgICAgICAgID4gVGhhbmsgeW91LA0KPiA+Pj4gICAgICAgICAgID4gSm9lbA0KPiA+ Pj4gICAgICAgICAgID4NCj4gPj4+ICAgICAgICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiAgICAgICAgICAgPiBzZmMgbWFpbGluZyBs aXN0DQo+ID4+PiAgICAgICAgICAgPiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+ID4+PiAgICAgICAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPiA+Pj4NCg== From nobody Wed Jan 23 06:46:29 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A593E12426E for ; Wed, 23 Jan 2019 06:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.042 X-Spam-Level: X-Spam-Status: No, score=-0.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 2usW4EPw3plG for ; Wed, 23 Jan 2019 06:46:24 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740051.outbound.protection.outlook.com [40.107.74.51]) (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 30FE7123FFD for ; Wed, 23 Jan 2019 06:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yRGXWDlI6jYM+E33jnZpMAzXdpwQe38qbLZ4MkqWEDU=; b=hfVXkasnf775jFaT+Na0WgKbykCAP2NNcPuI1/kdPQ5QFDHZtp5Omyc+RF+3eJj59ofR/DyWya0g5naMaQ0m0N4ezDTQeFnxw0xiwAiPUzEH07uDU/qK0aOnkTY98CSpsBLa8AwaB1UAMwKtymP5yDS4ZLjzRlit8uk3CRAViJI= Received: from BYAPR18MB2856.namprd18.prod.outlook.com (20.179.58.82) by BYAPR18MB2696.namprd18.prod.outlook.com (20.178.207.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.16; Wed, 23 Jan 2019 14:46:20 +0000 Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::905a:f184:97ad:5f79]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::905a:f184:97ad:5f79%4]) with mapi id 15.20.1558.016; Wed, 23 Jan 2019 14:46:20 +0000 From: Keyur Patel To: John E Drake CC: "stephane.litkowski@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane Thread-Index: AdSxidEM7Qn4dvOISTK6d6Rfr3vfGQA5zR0QAANWhkAAKwHfCA== Date: Wed, 23 Jan 2019 14:46:20 +0000 Message-ID: <5E2744C7-0804-4A24-BDF6-15046AE489D9@arrcus.com> References: <18744_1548075971_5C45C3C3_18744_88_1_9E32478DFA9976438E7A22F69B08FF924B7915D3@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <12156_1548175263_5C47479F_12156_428_1_9E32478DFA9976438E7A22F69B08FF924B791F33@OPEXCLILMA4.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [2600:387:6:80d::9e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR18MB2696; 6:8qHHNXg9hxiDAQjdDpm9fOSTLtJVZUzhs853TtTsy08zpk3u4Y+pqEk2WeuSkpTPZlirakKjlORyP7BEi0JNAH3FPwRVsHKWmJh7YKnHhVOY2f9fTRv0bh1Z19D8G1wJDGn17y+eAirmH6VQadmtiebWwbvnWfr7I/kFTvzSm4LKKTRWABO2c+LMLsXgF/tdJwXQd/4RJ2nXeC05bgPCQrsK/SeqTIggN1F+POJnzpvXKvOLhQbyQToqsOa6BWmPggEUQf1qmPNzsf2EKaweElL//dWHGqJ/zkJG+vgI3Xj8GqtgMl+cVxZP9MtjONj3bqcu5uxcv6v/h1pyIcgc2SXC52OaatbGbvfwEK4iuq6VkfTkG9aRG6SSGKdP+7vujasSGPWla12nqmuD4SPJBTplncXfiuoZHgvRxuOETghA9nDzEWF2gKWDyGZzYQU/oEZzRDH9HbaP++jjO5TSug==; 5:IseQAaufpQ9Faj218RsPBX7fatPIxcHCxyUWspKErfaOBiYWWpc7qrl56hB6ZccO+KZ4QoAdcJWsLJLG0nG7R1tNGjrKJga2zWxF+UE23KNovDQWQtRjMQE6hK/Lhncy7goudcl72m1cq+uN+wsmXSvB4LuOWWFfp6DNoSpZrhaBjZPYxR43usLg908RjWcJqLhnuUPf7Ys1c7lWJSHlZg==; 7:+/DDJ2NqHOAHGavhiZH4CC6ZaR794ziu9FT6Fp0/bCfZMzKyL8gtgC2ryuv2I2IwKJ9fCJp+6H9mKg5N7Rp2pzxrAZXoylm5CYo3QmSgaR2TIrfDbkf2Ism8Sian3DxcoR3qT9nLHc87KCeACIuG1w== x-ms-office365-filtering-correlation-id: 2e8d3cd9-fc20-4e87-ce8e-08d6814189a3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600110)(711020)(4605077)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR18MB2696; x-ms-traffictypediagnostic: BYAPR18MB2696: x-microsoft-antispam-prvs: x-forefront-prvs: 0926B0E013 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39830400003)(346002)(366004)(136003)(396003)(199004)(189003)(69234005)(54896002)(6512007)(6306002)(76176011)(53936002)(71190400001)(71200400001)(2906002)(106356001)(790700001)(7736002)(82746002)(36756003)(14444005)(256004)(5024004)(6486002)(6436002)(229853002)(186003)(446003)(11346002)(83716004)(2616005)(46003)(236005)(33656002)(476003)(486006)(4326008)(316002)(81156014)(81166006)(102836004)(97736004)(966005)(54906003)(6246003)(99286004)(508600001)(606006)(86362001)(14454004)(6506007)(53546011)(8676002)(8936002)(25786009)(1941001)(105586002)(6116002)(9886003)(6916009)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2696; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:3; MX:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: oTg2yf6prndgKrMz564XXe+FP+mBVhH9TkEjssXhMU+xTLAUu16Mt8e5O/cIpv0h+b5BBTlcwLqP9kQ7cYWfJBAegnJYOnCwfcBbefOC/ycC2I+9xQfyMg7XvURwaMgVCXazX19ZciWSXh+xCsWohax5jgO3T8ssDF/oiH4key4jvByWRCFS0Q67J57CNK9sAJDOCfj20lUQsTLJoAAI2jxh+3NUmB3IOOIJRKdG7pSwBLLK1mdFiQj8oof8X9CnaqcHSpRVaU7rPYk/ngTFnTtU6xxhCElDOeefOKMdwSnVlHbQuwgwSXB2dhwl6a3HN+tZkzrqaGoFfRr+u80TJkqbEgBv70bywcGgLjNO2gGtIBA1b1L1AeCZiXRIFMKpaDFej47JfFEkUsGv0J1A6qOWmhpCcrvyy7F5XWyw2dg= Content-Type: multipart/alternative; boundary="_000_5E2744C708044A24BDF615046AE489D9arrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e8d3cd9-fc20-4e87-ce8e-08d6814189a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2019 14:46:20.0264 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2696 Archived-At: Subject: Re: [sfc] WGLC, IPR and implementation poll for draft-ietf-bess-nsh-bgp-control-plane X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 14:46:28 -0000 --_000_5E2744C708044A24BDF615046AE489D9arrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCwNCg0KUmVnYXJkcywNCktleXVyDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24g SmFuIDIyLCAyMDE5LCBhdCAxMDoxNSBBTSwgSm9obiBFIERyYWtlIDxqZHJha2VAanVuaXBlci5u ZXQ8bWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KDQpTdXBwb3J0DQoNCllvdXJz IElycmVzcGVjdGl2ZWx5LA0KDQpKb2huDQoNCkZyb206IHNmYyA8c2ZjLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIHN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4N ClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjIsIDIwMTkgMTE6NDEgQU0NClRvOiBzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzZmNdIEZXOiBXR0xDLCBJUFIgYW5k IGltcGxlbWVudGF0aW9uIHBvbGwgZm9yIGRyYWZ0LWlldGYtYmVzcy1uc2gtYmdwLWNvbnRyb2wt cGxhbmUNCg0KSGkgV0csDQoNCkZZSSwgaW4gQkVTUyB3ZSBoYXZlIHN0YXJ0ZWQgdGhlIFdHTEMg Zm9yIGRyYWZ0LWlldGYtYmVzcy1uc2gtYmdwLWNvbnRyb2wtcGxhbmUuDQpGZWVsIGZyZWUgdG8g Y29tbWVudCBvbiBvdXIgQkVTUyBtYWlsaW5nIGxpc3QuDQoNCkJyZ2RzLA0KDQpTdGVwaGFuZSwg Y28tY2hhaXIgb2YgQkVTUy4NCg0KRnJvbTogc3RlcGhhbmUuLmxpdGtvd3NraUBvcmFuZ2UuY29t PG1haWx0bzpzdGVwaGFuZS4ubGl0a293c2tpQG9yYW5nZS5jb20+IFttYWlsdG86c3RlcGhhbmUu LmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNv bT5dDQpTZW50OiBNb25kYXksIEphbnVhcnkgMjEsIDIwMTkgMTQ6MDYNClRvOiBiZXNzQGlldGYu b3JnPG1haWx0bzpiZXNzQGlldGYub3JnPg0KQ2M6IGJlc3MtY2hhaXJzQGlldGYub3JnPG1haWx0 bzpiZXNzLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFdHTEMsIElQUiBhbmQgaW1wbGVtZW50 YXRpb24gcG9sbCBmb3IgZHJhZnQtaWV0Zi1iZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFuZQ0KDQoN CkhlbGxvIFdvcmtpbmcgR3JvdXAsDQoNCg0KDQpUaGlzIGVtYWlsIHN0YXJ0cyBhIHRocmVlIHdl ZWtzIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIG9uICBkcmFmdC1pZXRmLWJlc3MtbnNoLWJncC1j b250cm9sLXBsYW5lIFsxXS4NCg0KDQoNClRoaXMgcG9sbCBydW5zIHVudGlsICp0aGUgNHRoIG9m IEZlYnJ1YXJ5Ki4NCg0KDQoNCldlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRnZSBvZiBh bnkgdW5kaXNjbG9zZWQgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIERvY3VtZW50LCB0byBlbnN1 cmUgdGhhdCBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQ UiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRh aWxzKS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYW4gQXV0aG9yIG9yIGEgQ29udHJpYnV0b3Ig b2YgdGhpcyBEb2N1bWVudCBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIGFuZCBpbmRpY2F0 ZSB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCB1bmRpc2Nsb3Nl ZCBJUFIuIFRoZSBEb2N1bWVudCB3b24ndCBwcm9ncmVzcyB3aXRob3V0IGFuc3dlcnMgZnJvbSBh bGwgdGhlIEF1dGhvcnMgYW5kIENvbnRyaWJ1dG9ycy4NCg0KDQoNCldlIGhhdmUgc2V2ZXJhbCBJ UFJzIGFscmVhZHkgZGlzY2xvc2VkLg0KDQoNCg0KSWYgeW91IGFyZSBub3QgbGlzdGVkIGFzIGFu IEF1dGhvciBvciBhIENvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQg b25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRp c2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNCg0KDQpXZSBhcmUgYWxz byBwb2xsaW5nIGZvciBhbnkgZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gYXMgcGVyIFsyXS4NCg0K DQoNCiAgICBUaGFuayB5b3UsDQoNCiAgICBTdGVwaGFuZSAmIE1hdHRoZXcNCg0KDQoNCiAgICBb MV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZXNzLW5zaC1i Z3AtY29udHJvbC1wbGFuZS88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEYmVz cy0yRG5zaC0yRGJncC0yRGNvbnRyb2wtMkRwbGFuZV8mZD1Ed01GQWcmYz1IQWtZdWg2M3JzdWhy NlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9Q1JCMnRKaVFlUGswY1QtaDVMR2hFV0gt c194WFh1cDNIenZCU01SajVWRSZtPW9pZnh5MUNSX1gyaGF5dUgxRWtjRFdTU3A4VjRGZEwxT2Vy bDhqT0IyRE0mcz0zNDMxOGliQU5yLUxxWkRUem0tQmQ5WXFjc3hVWmN2ZEgtMFRkdkFXZkNJJmU9 Pg0KDQoNCg0KICAgIFsyXSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Jl c3MvY0czWDF0VHFiX3ZQQzRyZzU2U0Vka2pxRHB3PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fbWFpbGFyY2hpdmUuaWV0Zi5vcmdfYXJjaF9tc2df YmVzc19jRzNYMXRUcWItNUZ2UEM0cmc1NlNFZGtqcURwdyZkPUR3TUZBZyZjPUhBa1l1aDYzcnN1 aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj1DUkIydEppUWVQazBjVC1oNUxHaEVX SC1zX3hYWHVwM0h6dkJTTVJqNVZFJm09b2lmeHkxQ1JfWDJoYXl1SDFFa2NEV1NTcDhWNEZkTDFP ZXJsOGpPQjJETSZzPW1yS3R0dDRIX3lkbUh2Tlh3VVA2SWpCX0RvYjJSYURFNTBLQkp0dU8wTUEm ZT0+DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5r IHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5 b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpz ZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= --_000_5E2744C708044A24BDF615046AE489D9arrcuscom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpT dXBwb3J0LA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+S2V5 dXI8YnI+DQo8YnI+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiIGRpcj0ibHRyIj5TZW50 IGZyb20gbXkgaVBob25lPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQpPbiBKYW4gMjIsIDIw MTksIGF0IDEwOjE1IEFNLCBKb2huIEUgRHJha2UgJmx0OzxhIGhyZWY9Im1haWx0bzpqZHJha2VA anVuaXBlci5uZXQiPmpkcmFrZUBqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxtZXRh IG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1l ZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5N c29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ bGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 Q29uc29sYXM7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFp biBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkJhbGxv b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250 LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KLi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXBwb3J0PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Zb3VycyBJcnJlc3BlY3RpdmVseSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Sm9objxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IHNm YyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5zZmMtYm91bmNlc0Bp ZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzpzdGVw aGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208 L2E+PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMjIsIDIwMTkgMTE6NDEgQU08 YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NmY10gRlc6IFdHTEMsIElQUiBhbmQgaW1wbGVt ZW50YXRpb24gcG9sbCBmb3IgZHJhZnQtaWV0Zi1iZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFuZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkhpIFdHLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RllJ LCBpbiBCRVNTIHdlIGhhdmUgc3RhcnRlZCB0aGUgV0dMQyBmb3IgZHJhZnQtaWV0Zi1iZXNzLW5z aC1iZ3AtY29udHJvbC1wbGFuZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RmVlbCBmcmVlIHRvIGNvbW1lbnQg b24gb3VyIEJFU1MgbWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+QnJnZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdGVwaGFu ZSwgY28tY2hhaXIgb2YgQkVTUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYi Pg0KPGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLi5saXRrb3dza2lAb3JhbmdlLmNvbSI+c3RlcGhh bmUuLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tIj5tYWlsdG86c3RlcGhhbmUuLmxpdGtvd3NraUBvcmFuZ2UuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMjEsIDIwMTkgMTQ6MDY8 YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpiZXNzQGlldGYub3JnIj5iZXNzQGlldGYu b3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmJlc3MtY2hhaXJzQGlldGYu b3JnIj5iZXNzLWNoYWlyc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gV0dMQywg SVBSIGFuZCBpbXBsZW1lbnRhdGlvbiBwb2xsIGZvciBkcmFmdC1pZXRmLWJlc3MtbnNoLWJncC1j b250cm9sLXBsYW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SGVsbG8gV29ya2luZyBHcm91cCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoaXMgZW1haWwgc3RhcnRzIGEgdGhyZWUgd2Vla3MgV29ya2luZyBHcm91 cCBMYXN0IENhbGwgb24gJm5ic3A7ZHJhZnQtaWV0Zi1iZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFu ZSBbMV0uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBwb2xsIHJ1bnMgdW50 aWwgKnRoZSA0dGggb2YgRmVicnVhcnkqLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5X ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IHVuZGlzY2xvc2VkIElQUiB0 aGF0IGFwcGxpZXMgdG8gdGhpcyBEb2N1bWVudCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVu IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5 NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhbiBBdXRob3Ig b3IgYSBDb250cmlidXRvciBvZiB0aGlzIERvY3VtZW50IHBsZWFzZSByZXNwb25kIHRvIHRoaXMg ZW1haWwgYW5kIGluZGljYXRlIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJl bGV2YW50IHVuZGlzY2xvc2VkIElQUi4gVGhlIERvY3VtZW50IHdvbid0IHByb2dyZXNzIHdpdGhv dXQgYW5zd2VycyBmcm9tIGFsbCB0aGUgQXV0aG9ycw0KIGFuZCBDb250cmlidXRvcnMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldlIGhhdmUgc2V2ZXJhbCBJUFJzIGFscmVhZHkgZGlz Y2xvc2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JZiB5b3UgYXJlIG5vdCBsaXN0 ZWQgYXMgYW4gQXV0aG9yIG9yIGEgQ29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkg cmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0 IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+V2UgYXJlIGFsc28gcG9sbGluZyBmb3IgYW55IGV4aXN0aW5n IGltcGxlbWVudGF0aW9uIGFzIHBlciBbMl0uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoYW5rIHlvdSw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBTdGVw aGFuZSAmYW1wOyBNYXR0aGV3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1sxXSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0y RGlldGYtMkRiZXNzLTJEbnNoLTJEYmdwLTJEY29udHJvbC0yRHBsYW5lXyZhbXA7ZD1Ed01GQWcm YW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj1D UkIydEppUWVQazBjVC1oNUxHaEVXSC1zX3hYWHVwM0h6dkJTTVJqNVZFJmFtcDttPW9pZnh5MUNS X1gyaGF5dUgxRWtjRFdTU3A4VjRGZEwxT2VybDhqT0IyRE0mYW1wO3M9MzQzMThpYkFOci1McVpE VHptLUJkOVlxY3N4VVpjdmRILTBUZHZBV2ZDSSZhbXA7ZT0iPg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZXNzLW5zaC1iZ3AtY29udHJvbC1wbGFuZS88L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBbMl0gPGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X19tYWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19iZXNzX2NHM1gxdFRxYi01RnZQQzRyZzU2 U0Vka2pxRHB3JmFtcDtkPUR3TUZBZyZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUst bmRiM3ZvRFRYY1d6b0NJJmFtcDtyPUNSQjJ0SmlRZVBrMGNULWg1TEdoRVdILXNfeFhYdXAzSHp2 QlNNUmo1VkUmYW1wO209b2lmeHkxQ1JfWDJoYXl1SDFFa2NEV1NTcDhWNEZkTDFPZXJsOGpPQjJE TSZhbXA7cz1tckt0dHQ0SF95ZG1Idk5Yd1VQNklqQl9Eb2IyUmFERTUwS0JKdHVPME1BJmFtcDtl PSI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Jlc3MvY0czWDF0VHFi X3ZQQzRyZzU2U0Vka2pxRHB3PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86 cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PcmFuZ2Ug ZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3ByZT4N CjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286 cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48 L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48 L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcHJlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5zZmMgbWFpbGluZyBsaXN0PC9z cGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9y ZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjPC9hPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_5E2744C708044A24BDF615046AE489D9arrcuscom_-- From nobody Wed Jan 23 08:10:28 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FF5130E83; Wed, 23 Jan 2019 08:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 aSKwQtVi_IPQ; Wed, 23 Jan 2019 08:10:24 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 3AE20130E82; Wed, 23 Jan 2019 08:10:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43l9HN0wf0z11RL8; Wed, 23 Jan 2019 08:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1548259824; bh=COhhMjyTtU+L5OrPInQTKFrpw1wDjtJwTgikw4loT3k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EraKEkwETfC0aGov2Oz0FtpMEzXHsJI3Lx/r16NhrG09de+ozneg7JBOx354nDEqq qToJhPGTPB6oY5+AoM3FD6xZFrhdgWNoQivfHfX/RY4nRSu7j6aNO9GMY4vkLlvA6a uP3EBLow/lls0SLkaDeieM4R3nWMUB5lJ+sZafD4= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43l9HM0Kn1z11RLr; Wed, 23 Jan 2019 08:10:22 -0800 (PST) To: mohamed.boucadair@orange.com Cc: "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <7899163b-e90e-4fec-a523-a7c4f2e881df@joelhalpern.com> Date: Wed, 23 Jan 2019 11:10:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 16:10:27 -0000 Maybe I am missing something important, but I would not expect SFF to exhibit the behavior you describe relative to DSCPs. I do not know of any place where this is required for intra-domain tunnels. It is an interesting issue for inter-domain usage of SFC. But our scope is explicitly intra-domain. As far as I know, DSCPs are not re-marked within a domain. They are modified at entry / exit from a domain, but that is not an issue for an SFF. Is there someplace where the behavior you are asking about is required by existing documents? Yours, Joel On 1/23/19 8:37 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > The point Joel is SFFs has to preserve whatever DSCP marking when encapsulating/encapsulation (including cases where transport encap changes). > > If you will, we can describe the scenario using your words: > > ======= > Consider an SFF that receives a packet with a transport DSCP marking > and an NSH header. That SFF removes the transport header. It then > (usually) sends the packet via some other means to an SF, and gets the > packet back. After which it sends it on to the next SFF with a new > transport header carrying the NSH. > Let us take as given that we want to support DSCP marking preservation. > Then we need to somehow preserve the DSCP information that the SFF > receives. > ========== > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : mardi 22 janvier 2019 13:31 >> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis >> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in >> state "Candidate for WG Adoption" >> >> (again: speaking personally) >> DSCP behavior is VERY different from ECN behavior in terms of >> intermediate router modification. DSCPs may get rewritten at certain >> specific places, but not generally at interior routers. So mapping from >> the interior packet DSCP to the exterior packet DSCP and IEEE marking is >> normal and safe. there is no need to reverse the process. ECN marking >> needs to reverse the process due to the fact that individual routers are >> expected to change the marking based on local conditions. >> >> At least thaat is how I understand it, >> Joel >> >> On 1/22/19 1:25 AM, mohamed.boucadair@orange.com wrote: >>> Hi Joel, >>> >>> What makes ECN specific in this regards compared to DSCP marking >> preservation? >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Envoyé : vendredi 18 janvier 2019 15:55 >>>> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis >>>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support >> in >>>> state "Candidate for WG Adoption" >>>> >>>> >>>> Let me try as an individual to paraphrase what I understand the document >>>> to be offering. That authors should feel free to comment further >>>> including if necessary telling me that I am confused. >>>> >>>> Consider an SFF that receives a packet with a transport ECN indication >>>> and an NSH header. That SFF removes the transport header. It then >>>> (usually) sends the packet via some other means to an SF, and gets the >>>> packet back. After which it sends it on to the next SFF with a new >>>> transport header carrying the NSH. >>>> Let us take as given that we want to support effective ECN. >>>> Then we need to somehow preserve the ECN information that the SFF >> receives. >>>> >>>> One way would be to insist that the SFF, when it receives the ECN >>>> information, has to rummage through to find the internal IP packet, and >>>> must update the internal ECN information therein. Ugg. IThat would be >>>> a pretty onerous requirement. >>>> >>>> Instead, the document suggests that the SFF transfer the marking to the >>>> NSH header, and then use that NSH marking when it generates the new >>>> transport header. This can then be used when the packet exits the NSH >>>> domain to propagate the information to the header (which is by >>>> definition exposed when the NSH header is removed.) >>>> >>>> Med, if I understand you properly you are suggesting that the SFF should >>>> somehow keep the information from the transport header associated with >>>> the packet, but not in the NSH header. In some SFF implementations, and >>>> with some ways of working with SFs, that is doable. Requiring that >>>> would limit the implementation and deployment choices. >>>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 1/18/19 4:15 AM, mohamed.boucadair@orange.com wrote: >>>>> Hi Andy, >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, >>>>> >>>>> Med >>>>> >>>>> *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* Andrew G. Malis >>>>> *Envoyé :* jeudi 17 janvier 2019 16:33 >>>>> *À :* BOUCADAIR Mohamed TGI/OLN >>>>> *Cc :* sfc-chairs@ietf.org; IETF Secretariat; >>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>>> *Objet :* Re: [sfc] The SFC WG has placed >>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" >>>>> >>>>> Med, >>>>> >>>>> Your point about RFC 5129 is correct, but I'm not personally aware of >>>>> any implementations. And I was just using MPLS as an example, there may >>>>> be others in the future as well. >>>>> >>>>> [Med] I understood this was an example, but still this is IMHO supposed >>>>> to be handled among the spirit of the effort led by Bob in 6040 and its >>>>> current & futures updates. >>>>> >>>>> Your point about the SFF preserving ECN is implementation dependent, for >>>>> example the SFF could have separate input and output interfaces without >>>>> shared memory, or the transport encapsulation could change in different >>>>> regions of the SFC domain. >>>>> >>>>> [Med] I don’t understand your point about separate inputs/output >>>>> interfaces and the change of encap schemes. Let’s put aside SFC for a >>>>> moment and consider the example of a LISP XTR which is supporting ECN >>>>> dissemination/handling. That xTR may not use the same in/out interfaces, >>>>> but still need to achieve some processing when doing its encap/decap. >>>>> >>>>> It's difficult to depend on SFFs being able to preserve >>>>> transport-header-dependent information without that becoming a >>>>> requirement in the SFC architecture. >>>>> >>>>> [Med] I don’t think that we can tag congestion notification as >>>>> “transport-header-dependent”. There are ways to pass that info even when >>>>> the transport encap changes. >>>>> >>>>> This is IMHO among things that the WG is supposed to cover under this >>>>> item in the charter (please note that those are clearing taged as >>>>> transport issues): >>>>> >>>>> == >>>>> >>>>> 4) Transport Considerations - This will capture the expectations SFC >>>>> places on transport behavior, including dealing with issues such as >>>>> congestion indications and responses. >>>>> >>>>> == >>>>> >>>>> Cheers, >>>>> >>>>> Andy >>>>> >>>>> On Thu, Jan 17, 2019 at 10:02 AM >>>> > wrote: >>>>> >>>>> Hi Andy, >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, >>>>> >>>>> Med >>>>> >>>>> *De :*Andrew G. Malis [mailto:agmalis@gmail.com >>>>> ] >>>>> *Envoyé :* jeudi 17 janvier 2019 15:50 >>>>> *À :* BOUCADAIR Mohamed TGI/OLN >>>>> *Cc :* IETF Secretariat; sfc-chairs@ietf.org >>>>> ; >>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org >>>>> ; sfc@ietf.org >>>>> >>>>> *Objet :* Re: [sfc] The SFC WG has placed >>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG >> Adoption" >>>>> >>>>> Med, >>>>> >>>>> Not all transports support ECN marking, for example NSH over MPLS. >>>>> >>>>> [Med] Isn’t this covered by RFC5129? >>>>> >>>>> And even where the transport supports ECN marking, note the example >>>>> in Figure 1 in the draft where the outer encapsulation can be >>>>> stripped during SFF processing. In that case, the scope of the ECN >>>>> marking is limited to individual SFF-SFF links. rather than end-to- >> end. >>>>> >>>>> [Med] Why couldn’t SFF preserve ECN when doing its transport >>>>> decap/encap? >>>>> >>>>> Cheers, >>>>> >>>>> Andy >>>>> >>>>> On Thu, Jan 17, 2019 at 9:12 AM >>>> > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I do think that ECN is naturally better handled at the transport >>>>> encapsulation instead of the NSH itself. >>>>> >>>>> Requiring the functionality to be handled at the transport encap >>>>> (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redundant, IMO. >>>>> >>>>> I like the approach we set in the SFC architecture in which we >>>>> separated service matters from transport ones. I'd vote for >>>>> maintaining that separation cleaner as it was set in the arch >> RFC. >>>>> >>>>> Thank you. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>> > -----Message d'origine----- >>>>> > De : sfc [mailto:sfc-bounces@ietf.org >>>>> ] De la part de IETF Secretariat >>>>> > Envoyé : jeudi 3 janvier 2019 06:11 >>>>> > À : sfc-chairs@ietf.org ; >>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org >>>>> ; >>>>> > sfc@ietf.org >>>>> > Objet : [sfc] The SFC WG has placed >>>>> draft-eastlake-sfc-nsh-ecn-support in >>>>> > state "Candidate for WG Adoption" >>>>> > >>>>> > >>>>> > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in >>>> state >>>>> > Candidate for WG Adoption (entered by Joel Halpern) >>>>> > >>>>> > The document is available at >>>>> > >>>>> https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn- >>>> support/ >>>>> > >>>>> > Comment: >>>>> > This starts the WG call for adoption of this draft. >>>>> > Please respond to the list, indicating support for this as a >>>>> work item of the >>>>> > working group with this document as the basis for the work, >>>>> or objection to >>>>> > the working group adopting this item as a working group >> draft. >>>>> > >>>>> > The authors should confirm to the chairs and WG secretary >>>>> that all IPR known >>>>> > to them relevant to this draft has been disclosed. >>>>> > >>>>> > The working group adoption call will last 2 weeks, ending at >>>>> the end of the >>>>> > day on Thursday, January 17 2019 COB somewhere. >>>>> > >>>>> > Thank you, >>>>> > Joel >>>>> > >>>>> > _______________________________________________ >>>>> > sfc mailing list >>>>> > sfc@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/sfc >>>>> From nobody Wed Jan 23 15:14:16 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FF2130F63 for ; Wed, 23 Jan 2019 15:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 NRjOvk7wT1DN for ; Wed, 23 Jan 2019 15:14:11 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 C7817130F62 for ; Wed, 23 Jan 2019 15:14:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43lLhM3k5kzFqNt for ; Wed, 23 Jan 2019 15:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1548285251; bh=9TWQTQ1dvi6Y/JNga8hzA9DvzIeggC7MO/cQkFKXivw=; h=To:From:Subject:Date:From; b=Gk1tHdTrTpJPbC1bnPWXmUIFv792TX23GChllZPkN7Xo2HNtiPLeJtbwHURCz8Xmj HEDza5ZgqmOJxY5530SjbYDcHQowsdsHcvw4q7jjZAJjq7Igln+owYx7GdewYzjvoQ TCZNI0UTLuPycaVIwZmTqxn++pZZAw+MXHw9L8GA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43lLhM0c24zFpr9 for ; Wed, 23 Jan 2019 15:14:10 -0800 (PST) To: "sfc@ietf.org" From: "Joel M. Halpern" Message-ID: Date: Wed, 23 Jan 2019 18:14:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Regarding draft-eastlake-sfc-nsh-ecn-support adoption call X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 23:14:14 -0000 While the time for the call has completed, I would like to see the current discussion resolve before judging the adoption as chair (with Jim). As a corollary, if anyone who has not spoken up has an opinion about the adoption, it is still VERY helpful if you speak up. Please provide motivation for your response. If things do not resolve clearly on their own, the chairs will (as is required) reach a determination anyway, but WG clarity is preferred. Thank you, Joel From nobody Wed Jan 23 22:39:18 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE98A1310AC; Wed, 23 Jan 2019 22:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 4xyHgXC0aqhy; Wed, 23 Jan 2019 22:39:15 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC5B130E11; Wed, 23 Jan 2019 22:39:15 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 43lXYs3bb9z5wHn; Thu, 24 Jan 2019 07:39:13 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 43lXYs2RJ1z1xpB; Thu, 24 Jan 2019 07:39:13 +0100 (CET) Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup (10.114.13.67) by OPEXCLILM23.corporate.adroot.infra.ftgroup (10.114.31.57) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 24 Jan 2019 07:39:12 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM43.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0415.000; Thu, 24 Jan 2019 07:39:12 +0100 From: To: "Joel M. Halpern" CC: "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" Thread-Index: AQHUszYoSQ0VNBgi70mJk8BE5DP5AaW9854Q Date: Thu, 24 Jan 2019 06:39:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7899163b-e90e-4fec-a523-a7c4f2e881df@joelhalpern.com> In-Reply-To: <7899163b-e90e-4fec-a523-a7c4f2e881df@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 06:39:18 -0000 Sm9lbCwgDQoNCkRTQ1AgcHJlc2VydmF0aW9uIGlzIGEgdHJpdmlhbCByZXF1aXJlbWVudCBmb3Ig aW50cmEtZG9tYWluIFNGQy4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmMyOTgzOiANCg0KICAgV2hlbiBhIHR1bm5lbCBpcyBub3QgZW5kLXRvLWVuZCwgdGhl cmUgYXJlDQogICBjaXJjdW1zdGFuY2VzIGluIHdoaWNoIGl0IG1heSBiZSBkZXNpcmFibGUgdG8g cHJvcGFnYXRlIHRoZSBEU0NQDQogICBhbmQvb3Igc29tZSBvZiB0aGUgaW5mb3JtYXRpb24gdGhh dCBpdCBjb250YWlucyB0byB0aGUgb3V0ZXIgSVANCiAgIGhlYWRlciBvbiBpbmdyZXNzIGFuZC9v ciBiYWNrIHRvIGlubmVyIElQIGhlYWRlciBvbiBlZ3Jlc3MuDQoNCk9uZSBvZiB0aGUgbW9kZWxz IGRpc2N1c3NlZCBpbiAyOTgzIGFzc3VtZXMgdGhlIGZvbGxvd2luZy4gDQoNCiAgIEluIHRoaXMg bW9kZWwsIGFueSBwYWNrZXQgaGFzIGV4YWN0bHkgb25lIERTIEZpZWxkDQogICB0aGF0IGlzIHVz ZWQgZm9yIHRyYWZmaWMgY29uZGl0aW9uaW5nIGF0IGFueSBwb2ludCwgbmFtZWx5IHRoZSBEUw0K ICAgRmllbGQgaW4gdGhlIG91dGVybW9zdCBJUCBoZWFkZXI7IGFueSBvdGhlcnMgYXJlIGlnbm9y ZWQuDQogICBJbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBtb2RlbCBjb3B5IHRoZSBEU0NQIHZhbHVl IHRvIHRoZSBvdXRlciBJUA0KICAgaGVhZGVyIGF0IGVuY2Fwc3VsYXRpb24gYW5kIGNvcHkgdGhl IG91dGVyIGhlYWRlcidzIERTQ1AgdmFsdWUgdG8gdGhlDQogICBpbm5lciBJUCBoZWFkZXIgYXQg ZGVjYXBzdWxhdGlvbi4NCg0KQmVjYXVzZSBTRkYgaXMgYW4gZW5jYXAvZGVjcGEgZnVuY3Rpb24s IGl0IGZhbGxzIHVuZGVyIHRoZSBhYm92ZSBpbXBsZW1lbnRhdGlvbnMuIA0KDQpDaGVlcnMsDQpN ZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogSm9lbCBNLiBIYWxw ZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4gRW52b3nDqcKgOiBtZXJjcmVkaSAy MyBqYW52aWVyIDIwMTkgMTc6MTANCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0K PiBDY8KgOiBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnOyBzZmNA aWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNlZCBkcmFm dC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0IGluDQo+IHN0YXRlICJDYW5kaWRhdGUgZm9y IFdHIEFkb3B0aW9uIg0KPiANCj4gPG5vIGhhdD4NCj4gTWF5YmUgSSBhbSBtaXNzaW5nIHNvbWV0 aGluZyBpbXBvcnRhbnQsIGJ1dCBJIHdvdWxkIG5vdCBleHBlY3QgU0ZGIHRvDQo+IGV4aGliaXQg dGhlIGJlaGF2aW9yIHlvdSBkZXNjcmliZSByZWxhdGl2ZSB0byBEU0NQcy4NCj4gDQo+IEkgZG8g bm90IGtub3cgb2YgYW55IHBsYWNlIHdoZXJlIHRoaXMgaXMgcmVxdWlyZWQgZm9yIGludHJhLWRv bWFpbg0KPiB0dW5uZWxzLiAgSXQgaXMgYW4gaW50ZXJlc3RpbmcgaXNzdWUgZm9yIGludGVyLWRv bWFpbiB1c2FnZSBvZiBTRkMuICBCdXQNCj4gb3VyIHNjb3BlIGlzIGV4cGxpY2l0bHkgaW50cmEt ZG9tYWluLg0KPiANCj4gQXMgZmFyIGFzIEkga25vdywgRFNDUHMgYXJlIG5vdCByZS1tYXJrZWQg d2l0aGluIGEgZG9tYWluLiAgVGhleSBhcmUNCj4gbW9kaWZpZWQgYXQgZW50cnkgLyBleGl0IGZy b20gYSBkb21haW4sIGJ1dCB0aGF0IGlzIG5vdCBhbiBpc3N1ZSBmb3IgYW4gU0ZGLg0KPiANCj4g SXMgdGhlcmUgc29tZXBsYWNlIHdoZXJlIHRoZSBiZWhhdmlvciB5b3UgYXJlIGFza2luZyBhYm91 dCBpcyByZXF1aXJlZA0KPiBieSBleGlzdGluZyBkb2N1bWVudHM/DQo+IA0KPiBZb3VycywNCj4g Sm9lbA0KPiANCj4gT24gMS8yMy8xOSA4OjM3IEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tIHdyb3RlOg0KPiA+IEhpIEpvZWwsDQo+ID4NCj4gPiBUaGUgcG9pbnQgSm9lbCBpcyBTRkZz IGhhcyB0byBwcmVzZXJ2ZSB3aGF0ZXZlciBEU0NQIG1hcmtpbmcgd2hlbg0KPiBlbmNhcHN1bGF0 aW5nL2VuY2Fwc3VsYXRpb24gKGluY2x1ZGluZyBjYXNlcyB3aGVyZSB0cmFuc3BvcnQgZW5jYXAg Y2hhbmdlcykuDQo+ID4NCj4gPiBJZiB5b3Ugd2lsbCwgd2UgY2FuIGRlc2NyaWJlIHRoZSBzY2Vu YXJpbyB1c2luZyB5b3VyIHdvcmRzOg0KPiA+DQo+ID4gPT09PT09PQ0KPiA+IENvbnNpZGVyIGFu IFNGRiB0aGF0IHJlY2VpdmVzIGEgcGFja2V0IHdpdGggYSB0cmFuc3BvcnQgRFNDUCBtYXJraW5n DQo+ID4gYW5kIGFuIE5TSCBoZWFkZXIuICBUaGF0IFNGRiByZW1vdmVzIHRoZSB0cmFuc3BvcnQg aGVhZGVyLiAgSXQgdGhlbg0KPiA+ICh1c3VhbGx5KSBzZW5kcyB0aGUgcGFja2V0IHZpYSBzb21l IG90aGVyIG1lYW5zIHRvIGFuIFNGLCBhbmQgZ2V0cyB0aGUNCj4gPiBwYWNrZXQgYmFjay4gIEFm dGVyIHdoaWNoIGl0IHNlbmRzIGl0IG9uIHRvIHRoZSBuZXh0IFNGRiB3aXRoIGEgbmV3DQo+ID4g dHJhbnNwb3J0IGhlYWRlciBjYXJyeWluZyB0aGUgTlNILg0KPiA+IExldCB1cyB0YWtlIGFzIGdp dmVuIHRoYXQgd2Ugd2FudCB0byBzdXBwb3J0IERTQ1AgbWFya2luZyBwcmVzZXJ2YXRpb24uDQo+ ID4gVGhlbiB3ZSBuZWVkIHRvIHNvbWVob3cgcHJlc2VydmUgdGhlIERTQ1AgaW5mb3JtYXRpb24g dGhhdCB0aGUgU0ZGDQo+ID4gcmVjZWl2ZXMuDQo+ID4gPT09PT09PT09PQ0KPiA+DQo+ID4gQ2hl ZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ PiBEZcKgOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiA+ PiBFbnZvecOpwqA6IG1hcmRpIDIyIGphbnZpZXIgMjAxOSAxMzozMQ0KPiA+PiDDgMKgOiBCT1VD QURBSVIgTW9oYW1lZCBUR0kvT0xOOyBBbmRyZXcgRy4gTWFsaXMNCj4gPj4gQ2PCoDogZHJhZnQt ZWFzdGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydEBpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+ID4+ IE9iamV0wqA6IFJlOiBbc2ZjXSBUaGUgU0ZDIFdHIGhhcyBwbGFjZWQgZHJhZnQtZWFzdGxha2Ut c2ZjLW5zaC1lY24tc3VwcG9ydA0KPiBpbg0KPiA+PiBzdGF0ZSAiQ2FuZGlkYXRlIGZvciBXRyBB ZG9wdGlvbiINCj4gPj4NCj4gPj4gKGFnYWluOiBzcGVha2luZyBwZXJzb25hbGx5KQ0KPiA+PiBE U0NQIGJlaGF2aW9yIGlzIFZFUlkgZGlmZmVyZW50IGZyb20gRUNOIGJlaGF2aW9yIGluIHRlcm1z IG9mDQo+ID4+IGludGVybWVkaWF0ZSByb3V0ZXIgbW9kaWZpY2F0aW9uLiAgRFNDUHMgbWF5IGdl dCByZXdyaXR0ZW4gYXQgY2VydGFpbg0KPiA+PiBzcGVjaWZpYyBwbGFjZXMsIGJ1dCBub3QgZ2Vu ZXJhbGx5IGF0IGludGVyaW9yIHJvdXRlcnMuICBTbyBtYXBwaW5nIGZyb20NCj4gPj4gdGhlIGlu dGVyaW9yIHBhY2tldCBEU0NQIHRvIHRoZSBleHRlcmlvciBwYWNrZXQgRFNDUCBhbmQgSUVFRSBt YXJraW5nIGlzDQo+ID4+IG5vcm1hbCBhbmQgc2FmZS4gIHRoZXJlIGlzIG5vIG5lZWQgdG8gcmV2 ZXJzZSB0aGUgcHJvY2Vzcy4gIEVDTiBtYXJraW5nDQo+ID4+IG5lZWRzIHRvIHJldmVyc2UgdGhl IHByb2Nlc3MgZHVlIHRvIHRoZSBmYWN0IHRoYXQgaW5kaXZpZHVhbCByb3V0ZXJzIGFyZQ0KPiA+ PiBleHBlY3RlZCB0byBjaGFuZ2UgdGhlIG1hcmtpbmcgYmFzZWQgb24gbG9jYWwgY29uZGl0aW9u cy4NCj4gPj4NCj4gPj4gQXQgbGVhc3QgdGhhYXQgaXMgaG93IEkgdW5kZXJzdGFuZCBpdCwNCj4g Pj4gSm9lbA0KPiA+Pg0KPiA+PiBPbiAxLzIyLzE5IDE6MjUgQU0sIG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20gd3JvdGU6DQo+ID4+PiBIaSBKb2VsLA0KPiA+Pj4NCj4gPj4+IFdoYXQgbWFr ZXMgRUNOIHNwZWNpZmljIGluIHRoaXMgcmVnYXJkcyBjb21wYXJlZCB0byBEU0NQIG1hcmtpbmcN Cj4gPj4gcHJlc2VydmF0aW9uPw0KPiA+Pj4NCj4gPj4+IENoZWVycywNCj4gPj4+IE1lZA0KPiA+ Pj4NCj4gPj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4+PiBEZcKgOiBKb2Vs IE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiA+Pj4+IEVudm95w6nC oDogdmVuZHJlZGkgMTggamFudmllciAyMDE5IDE1OjU1DQo+ID4+Pj4gw4DCoDogQk9VQ0FEQUlS IE1vaGFtZWQgVEdJL09MTjsgQW5kcmV3IEcuIE1hbGlzDQo+ID4+Pj4gQ2PCoDogZHJhZnQtZWFz dGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydEBpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+ID4+Pj4g T2JqZXTCoDogUmU6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNlZCBkcmFmdC1lYXN0bGFrZS1z ZmMtbnNoLWVjbi0NCj4gc3VwcG9ydA0KPiA+PiBpbg0KPiA+Pj4+IHN0YXRlICJDYW5kaWRhdGUg Zm9yIFdHIEFkb3B0aW9uIg0KPiA+Pj4+DQo+ID4+Pj4gPGNoYWlyIGhhdCBvZmY+DQo+ID4+Pj4g TGV0IG1lIHRyeSBhcyBhbiBpbmRpdmlkdWFsIHRvIHBhcmFwaHJhc2Ugd2hhdCBJIHVuZGVyc3Rh bmQgdGhlIGRvY3VtZW50DQo+ID4+Pj4gdG8gYmUgb2ZmZXJpbmcuICBUaGF0IGF1dGhvcnMgc2hv dWxkIGZlZWwgZnJlZSB0byBjb21tZW50IGZ1cnRoZXINCj4gPj4+PiBpbmNsdWRpbmcgaWYgbmVj ZXNzYXJ5IHRlbGxpbmcgbWUgdGhhdCBJIGFtIGNvbmZ1c2VkLg0KPiA+Pj4+DQo+ID4+Pj4gQ29u c2lkZXIgYW4gU0ZGIHRoYXQgcmVjZWl2ZXMgYSBwYWNrZXQgd2l0aCBhIHRyYW5zcG9ydCBFQ04g aW5kaWNhdGlvbg0KPiA+Pj4+IGFuZCBhbiBOU0ggaGVhZGVyLiAgVGhhdCBTRkYgcmVtb3ZlcyB0 aGUgdHJhbnNwb3J0IGhlYWRlci4gIEl0IHRoZW4NCj4gPj4+PiAodXN1YWxseSkgc2VuZHMgdGhl IHBhY2tldCB2aWEgc29tZSBvdGhlciBtZWFucyB0byBhbiBTRiwgYW5kIGdldHMgdGhlDQo+ID4+ Pj4gcGFja2V0IGJhY2suICBBZnRlciB3aGljaCBpdCBzZW5kcyBpdCBvbiB0byB0aGUgbmV4dCBT RkYgd2l0aCBhIG5ldw0KPiA+Pj4+IHRyYW5zcG9ydCBoZWFkZXIgY2FycnlpbmcgdGhlIE5TSC4N Cj4gPj4+PiBMZXQgdXMgdGFrZSBhcyBnaXZlbiB0aGF0IHdlIHdhbnQgdG8gc3VwcG9ydCBlZmZl Y3RpdmUgRUNOLg0KPiA+Pj4+IFRoZW4gd2UgbmVlZCB0byBzb21laG93IHByZXNlcnZlIHRoZSBF Q04gaW5mb3JtYXRpb24gdGhhdCB0aGUgU0ZGDQo+ID4+IHJlY2VpdmVzLg0KPiA+Pj4+DQo+ID4+ Pj4gT25lIHdheSB3b3VsZCBiZSB0byBpbnNpc3QgdGhhdCB0aGUgU0ZGLCB3aGVuIGl0IHJlY2Vp dmVzIHRoZSBFQ04NCj4gPj4+PiBpbmZvcm1hdGlvbiwgaGFzIHRvIHJ1bW1hZ2UgdGhyb3VnaCB0 byBmaW5kIHRoZSBpbnRlcm5hbCBJUCBwYWNrZXQsIGFuZA0KPiA+Pj4+IG11c3QgdXBkYXRlIHRo ZSBpbnRlcm5hbCBFQ04gaW5mb3JtYXRpb24gdGhlcmVpbi4gIFVnZy4gIElUaGF0IHdvdWxkIGJl DQo+ID4+Pj4gYSBwcmV0dHkgb25lcm91cyByZXF1aXJlbWVudC4NCj4gPj4+Pg0KPiA+Pj4+IElu c3RlYWQsIHRoZSBkb2N1bWVudCBzdWdnZXN0cyB0aGF0IHRoZSBTRkYgdHJhbnNmZXIgdGhlIG1h cmtpbmcgdG8gdGhlDQo+ID4+Pj4gTlNIIGhlYWRlciwgYW5kIHRoZW4gdXNlIHRoYXQgTlNIIG1h cmtpbmcgd2hlbiBpdCBnZW5lcmF0ZXMgdGhlIG5ldw0KPiA+Pj4+IHRyYW5zcG9ydCBoZWFkZXIu ICBUaGlzIGNhbiB0aGVuIGJlIHVzZWQgd2hlbiB0aGUgcGFja2V0IGV4aXRzIHRoZSBOU0gNCj4g Pj4+PiBkb21haW4gdG8gcHJvcGFnYXRlIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgaGVhZGVyICh3 aGljaCBpcyBieQ0KPiA+Pj4+IGRlZmluaXRpb24gZXhwb3NlZCB3aGVuIHRoZSBOU0ggaGVhZGVy IGlzIHJlbW92ZWQuKQ0KPiA+Pj4+DQo+ID4+Pj4gTWVkLCBpZiBJIHVuZGVyc3RhbmQgeW91IHBy b3Blcmx5IHlvdSBhcmUgc3VnZ2VzdGluZyB0aGF0IHRoZSBTRkYgc2hvdWxkDQo+ID4+Pj4gc29t ZWhvdyBrZWVwIHRoZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSB0cmFuc3BvcnQgaGVhZGVyIGFzc29j aWF0ZWQgd2l0aA0KPiA+Pj4+IHRoZSBwYWNrZXQsIGJ1dCBub3QgaW4gdGhlIE5TSCBoZWFkZXIu ICBJbiBzb21lIFNGRiBpbXBsZW1lbnRhdGlvbnMsIGFuZA0KPiA+Pj4+IHdpdGggc29tZSB3YXlz IG9mIHdvcmtpbmcgd2l0aCBTRnMsIHRoYXQgaXMgZG9hYmxlLiAgUmVxdWlyaW5nIHRoYXQNCj4g Pj4+PiB3b3VsZCBsaW1pdCB0aGUgaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQgY2hvaWNl cy4NCj4gPj4+Pg0KPiA+Pj4+IDxjaGFpciBoYXQgc29tZXdoZXJlPg0KPiA+Pj4+IFlvdXJzLA0K PiA+Pj4+IEpvZWwNCj4gPj4+Pg0KPiA+Pj4+IE9uIDEvMTgvMTkgNDoxNSBBTSwgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPj4+Pj4gSGkgQW5keSwNCj4gPj4+Pj4NCj4g Pj4+Pj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4+Pj4+DQo+ID4+Pj4+IENoZWVycywNCj4gPj4+ Pj4NCj4gPj4+Pj4gTWVkDQo+ID4+Pj4+DQo+ID4+Pj4+ICpEZcKgOipzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gKkRlIGxhIHBhcnQgZGUqIEFuZHJldyBHLiBNYWxpcw0KPiA+Pj4+ PiAqRW52b3nDqcKgOiogamV1ZGkgMTcgamFudmllciAyMDE5IDE2OjMzDQo+ID4+Pj4+ICrDgMKg OiogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0KPiA+Pj4+PiAqQ2PCoDoqIHNmYy1jaGFpcnNA aWV0Zi5vcmc7IElFVEYgU2VjcmV0YXJpYXQ7DQo+ID4+Pj4+IGRyYWZ0LWVhc3RsYWtlLXNmYy1u c2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiA+Pj4+PiAqT2JqZXTCoDoq IFJlOiBbc2ZjXSBUaGUgU0ZDIFdHIGhhcyBwbGFjZWQNCj4gPj4+Pj4gZHJhZnQtZWFzdGxha2Ut c2ZjLW5zaC1lY24tc3VwcG9ydCBpbiBzdGF0ZSAiQ2FuZGlkYXRlIGZvciBXRyBBZG9wdGlvbiIN Cj4gPj4+Pj4NCj4gPj4+Pj4gTWVkLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBZb3VyIHBvaW50IGFib3V0 IFJGQyA1MTI5IGlzIGNvcnJlY3QsIGJ1dCBJJ20gbm90IHBlcnNvbmFsbHkgYXdhcmUgb2YNCj4g Pj4+Pj4gYW55IGltcGxlbWVudGF0aW9ucy4gQW5kIEkgd2FzIGp1c3QgdXNpbmcgTVBMUyBhcyBh biBleGFtcGxlLCB0aGVyZSBtYXkNCj4gPj4+Pj4gYmUgb3RoZXJzIGluIHRoZSBmdXR1cmUgYXMg d2VsbC4NCj4gPj4+Pj4NCj4gPj4+Pj4gW01lZF0gSSB1bmRlcnN0b29kIHRoaXMgd2FzIGFuIGV4 YW1wbGUsIGJ1dCBzdGlsbCB0aGlzIGlzIElNSE8gc3VwcG9zZWQNCj4gPj4+Pj4gdG8gYmUgaGFu ZGxlZCBhbW9uZyB0aGUgc3Bpcml0IG9mIHRoZSBlZmZvcnQgbGVkIGJ5IEJvYiBpbiA2MDQwIGFu ZCBpdHMNCj4gPj4+Pj4gY3VycmVudCAmIGZ1dHVyZXMgdXBkYXRlcy4NCj4gPj4+Pj4NCj4gPj4+ Pj4gWW91ciBwb2ludCBhYm91dCB0aGUgU0ZGIHByZXNlcnZpbmcgRUNOIGlzIGltcGxlbWVudGF0 aW9uIGRlcGVuZGVudCwNCj4gZm9yDQo+ID4+Pj4+IGV4YW1wbGUgdGhlIFNGRiBjb3VsZCBoYXZl IHNlcGFyYXRlIGlucHV0IGFuZCBvdXRwdXQgaW50ZXJmYWNlcyB3aXRob3V0DQo+ID4+Pj4+IHNo YXJlZCBtZW1vcnksIG9yIHRoZSB0cmFuc3BvcnQgZW5jYXBzdWxhdGlvbiBjb3VsZCBjaGFuZ2Ug aW4gZGlmZmVyZW50DQo+ID4+Pj4+IHJlZ2lvbnMgb2YgdGhlIFNGQyBkb21haW4uDQo+ID4+Pj4+ DQo+ID4+Pj4+IFtNZWRdIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHlvdXIgcG9pbnQgYWJvdXQgc2Vw YXJhdGUgaW5wdXRzL291dHB1dA0KPiA+Pj4+PiBpbnRlcmZhY2VzIGFuZCB0aGUgY2hhbmdlIG9m IGVuY2FwIHNjaGVtZXMuIExldOKAmXMgcHV0IGFzaWRlIFNGQyBmb3IgYQ0KPiA+Pj4+PiBtb21l bnQgYW5kIGNvbnNpZGVyIHRoZSBleGFtcGxlIG9mIGEgTElTUCBYVFIgd2hpY2ggaXMgc3VwcG9y dGluZyBFQ04NCj4gPj4+Pj4gZGlzc2VtaW5hdGlvbi9oYW5kbGluZy4gVGhhdCB4VFIgbWF5IG5v dCB1c2UgdGhlIHNhbWUgaW4vb3V0DQo+IGludGVyZmFjZXMsDQo+ID4+Pj4+IGJ1dCBzdGlsbCBu ZWVkIHRvIGFjaGlldmUgc29tZSBwcm9jZXNzaW5nIHdoZW4gZG9pbmcgaXRzIGVuY2FwL2RlY2Fw Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJdCdzIGRpZmZpY3VsdCB0byBkZXBlbmQgb24gU0ZGcyBiZWlu ZyBhYmxlIHRvIHByZXNlcnZlDQo+ID4+Pj4+IHRyYW5zcG9ydC1oZWFkZXItZGVwZW5kZW50IGlu Zm9ybWF0aW9uIHdpdGhvdXQgdGhhdCBiZWNvbWluZyBhDQo+ID4+Pj4+IHJlcXVpcmVtZW50IGlu IHRoZSBTRkMgYXJjaGl0ZWN0dXJlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBbTWVkXSBJIGRvbuKAmXQg dGhpbmsgdGhhdCB3ZSBjYW4gdGFnIGNvbmdlc3Rpb24gbm90aWZpY2F0aW9uIGFzDQo+ID4+Pj4+ IOKAnHRyYW5zcG9ydC1oZWFkZXItZGVwZW5kZW504oCdLiBUaGVyZSBhcmUgd2F5cyB0byBwYXNz IHRoYXQgaW5mbyBldmVuDQo+IHdoZW4NCj4gPj4+Pj4gdGhlIHRyYW5zcG9ydCBlbmNhcCBjaGFu Z2VzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGlzIGlzIElNSE8gYW1vbmcgdGhpbmdzIHRoYXQgdGhl IFdHIGlzIHN1cHBvc2VkIHRvIGNvdmVyIHVuZGVyIHRoaXMNCj4gPj4+Pj4gaXRlbSBpbiB0aGUg Y2hhcnRlciAocGxlYXNlIG5vdGUgdGhhdCB0aG9zZSBhcmUgY2xlYXJpbmcgdGFnZWQgYXMNCj4g Pj4+Pj4gdHJhbnNwb3J0IGlzc3Vlcyk6DQo+ID4+Pj4+DQo+ID4+Pj4+ID09DQo+ID4+Pj4+DQo+ ID4+Pj4+IDQpIFRyYW5zcG9ydCBDb25zaWRlcmF0aW9ucyAtIFRoaXMgd2lsbCBjYXB0dXJlIHRo ZSBleHBlY3RhdGlvbnMgU0ZDDQo+ID4+Pj4+IHBsYWNlcyBvbiB0cmFuc3BvcnQgYmVoYXZpb3Is IGluY2x1ZGluZyBkZWFsaW5nIHdpdGggaXNzdWVzIHN1Y2ggYXMNCj4gPj4+Pj4gY29uZ2VzdGlv biBpbmRpY2F0aW9ucyBhbmQgcmVzcG9uc2VzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiA9PQ0KPiA+Pj4+ Pg0KPiA+Pj4+PiBDaGVlcnMsDQo+ID4+Pj4+DQo+ID4+Pj4+IEFuZHkNCj4gPj4+Pj4NCj4gPj4+ Pj4gT24gVGh1LCBKYW4gMTcsIDIwMTkgYXQgMTA6MDIgQU0gPG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4gPj4+Pj4gPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPj4g d3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIEhpIEFuZHksDQo+ID4+Pj4+DQo+ID4+Pj4+ ICAgICAgIFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICBDaGVlcnMs DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIE1lZA0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAqRGXC oDoqQW5kcmV3IEcuIE1hbGlzIFttYWlsdG86YWdtYWxpc0BnbWFpbC5jb20NCj4gPj4+Pj4gICAg ICAgPG1haWx0bzphZ21hbGlzQGdtYWlsLmNvbT5dDQo+ID4+Pj4+ICAgICAgICpFbnZvecOpwqA6 KiBqZXVkaSAxNyBqYW52aWVyIDIwMTkgMTU6NTANCj4gPj4+Pj4gICAgICAgKsOAwqA6KiBCT1VD QURBSVIgTW9oYW1lZCBUR0kvT0xODQo+ID4+Pj4+ICAgICAgICpDY8KgOiogSUVURiBTZWNyZXRh cmlhdDsgc2ZjLWNoYWlyc0BpZXRmLm9yZw0KPiA+Pj4+PiAgICAgICA8bWFpbHRvOnNmYy1jaGFp cnNAaWV0Zi5vcmc+Ow0KPiA+Pj4+PiAgICAgICBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1z dXBwb3J0QGlldGYub3JnDQo+ID4+Pj4+ICAgICAgIDxtYWlsdG86ZHJhZnQtZWFzdGxha2Utc2Zj LW5zaC1lY24tc3VwcG9ydEBpZXRmLm9yZz47DQo+IHNmY0BpZXRmLm9yZw0KPiA+Pj4+PiAgICAg ICA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4gPj4+Pj4gICAgICAgKk9iamV0wqA6KiBSZTogW3Nm Y10gVGhlIFNGQyBXRyBoYXMgcGxhY2VkDQo+ID4+Pj4+ICAgICAgIGRyYWZ0LWVhc3RsYWtlLXNm Yy1uc2gtZWNuLXN1cHBvcnQgaW4gc3RhdGUgIkNhbmRpZGF0ZSBmb3IgV0cNCj4gPj4gQWRvcHRp b24iDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIE1lZCwNCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAg Tm90IGFsbCB0cmFuc3BvcnRzIHN1cHBvcnQgRUNOIG1hcmtpbmcsIGZvciBleGFtcGxlIE5TSCBv dmVyDQo+IE1QTFMuDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIFtNZWRdIElzbuKAmXQgdGhpcyBj b3ZlcmVkIGJ5IFJGQzUxMjk/DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgIEFuZCBldmVuIHdoZXJl IHRoZSB0cmFuc3BvcnQgc3VwcG9ydHMgRUNOIG1hcmtpbmcsIG5vdGUgdGhlDQo+IGV4YW1wbGUN Cj4gPj4+Pj4gICAgICAgaW4gRmlndXJlIDEgaW4gdGhlIGRyYWZ0IHdoZXJlIHRoZSBvdXRlciBl bmNhcHN1bGF0aW9uIGNhbiBiZQ0KPiA+Pj4+PiAgICAgICBzdHJpcHBlZCBkdXJpbmcgU0ZGIHBy b2Nlc3NpbmcuIEluIHRoYXQgY2FzZSwgdGhlIHNjb3BlIG9mIHRoZQ0KPiBFQ04NCj4gPj4+Pj4g ICAgICAgbWFya2luZyBpcyBsaW1pdGVkIHRvIGluZGl2aWR1YWwgU0ZGLVNGRiBsaW5rcy4gcmF0 aGVyIHRoYW4gZW5kLQ0KPiB0by0NCj4gPj4gZW5kLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICBb TWVkXSBXaHkgY291bGRu4oCZdCBTRkYgcHJlc2VydmUgRUNOIHdoZW4gZG9pbmcgaXRzIHRyYW5z cG9ydA0KPiA+Pj4+PiAgICAgICBkZWNhcC9lbmNhcD8NCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAg Q2hlZXJzLA0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICBBbmR5DQo+ID4+Pj4+DQo+ID4+Pj4+ICAg ICAgIE9uIFRodSwgSmFuIDE3LCAyMDE5IGF0IDk6MTIgQU0gPG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20NCj4gPj4+Pj4gICAgICAgPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tPj4gd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgICAgICBIaSBhbGwsDQo+ID4+Pj4+ DQo+ID4+Pj4+ICAgICAgICAgICBJIGRvIHRoaW5rIHRoYXQgRUNOIGlzIG5hdHVyYWxseSBiZXR0 ZXIgaGFuZGxlZCBhdCB0aGUNCj4gdHJhbnNwb3J0DQo+ID4+Pj4+ICAgICAgICAgICBlbmNhcHN1 bGF0aW9uIGluc3RlYWQgb2YgdGhlIE5TSCBpdHNlbGYuDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAg ICAgICBSZXF1aXJpbmcgdGhlIGZ1bmN0aW9uYWxpdHkgdG8gYmUgaGFuZGxlZCBhdCB0aGUgdHJh bnNwb3J0DQo+IGVuY2FwDQo+ID4+Pj4+ICAgICAgICAgICAoZHJhZnQtaWV0Zi10c3Z3Zy1yZmM2 MDQwdXBkYXRlLXNoaW0pIGFuZCBOU0ggaXMgcmVkdW5kYW50LA0KPiBJTU8uDQo+ID4+Pj4+DQo+ ID4+Pj4+ICAgICAgICAgICBJIGxpa2UgdGhlIGFwcHJvYWNoIHdlIHNldCBpbiB0aGUgU0ZDIGFy Y2hpdGVjdHVyZSBpbiB3aGljaA0KPiB3ZQ0KPiA+Pj4+PiAgICAgICAgICAgc2VwYXJhdGVkIHNl cnZpY2UgbWF0dGVycyBmcm9tIHRyYW5zcG9ydCBvbmVzLiBJJ2Qgdm90ZSBmb3INCj4gPj4+Pj4g ICAgICAgICAgIG1haW50YWluaW5nIHRoYXQgc2VwYXJhdGlvbiBjbGVhbmVyIGFzIGl0IHdhcyBz ZXQgaW4gdGhlIGFyY2gNCj4gPj4gUkZDLg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAgICAgVGhh bmsgeW91Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgICAgICAgQ2hlZXJzLA0KPiA+Pj4+PiAgICAg ICAgICAgTWVkDQo+ID4+Pj4+DQo+ID4+Pj4+ICAgICAgICAgICAgPiAtLS0tLU1lc3NhZ2UgZCdv cmlnaW5lLS0tLS0NCj4gPj4+Pj4gICAgICAgICAgICA+IERlwqA6IHNmYyBbbWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnDQo+ID4+Pj4+ICAgICAgICAgICA8bWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnPl0gRGUgbGEgcGFydCBkZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4+Pj4+ICAgICAgICAg ICAgPiBFbnZvecOpwqA6IGpldWRpIDMgamFudmllciAyMDE5IDA2OjExDQo+ID4+Pj4+ICAgICAg ICAgICAgPiDDgMKgOiBzZmMtY2hhaXJzQGlldGYub3JnIDxtYWlsdG86c2ZjLWNoYWlyc0BpZXRm Lm9yZz47DQo+ID4+Pj4+ICAgICAgICAgICBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBw b3J0QGlldGYub3JnDQo+ID4+Pj4+ICAgICAgICAgICA8bWFpbHRvOmRyYWZ0LWVhc3RsYWtlLXNm Yy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmc+Ow0KPiA+Pj4+PiAgICAgICAgICAgID4gc2ZjQGll dGYub3JnIDxtYWlsdG86c2ZjQGlldGYub3JnPg0KPiA+Pj4+PiAgICAgICAgICAgID4gT2JqZXTC oDogW3NmY10gVGhlIFNGQyBXRyBoYXMgcGxhY2VkDQo+ID4+Pj4+ICAgICAgICAgICBkcmFmdC1l YXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0IGluDQo+ID4+Pj4+ICAgICAgICAgICAgPiBzdGF0 ZSAiQ2FuZGlkYXRlIGZvciBXRyBBZG9wdGlvbiINCj4gPj4+Pj4gICAgICAgICAgICA+DQo+ID4+ Pj4+ICAgICAgICAgICAgPg0KPiA+Pj4+PiAgICAgICAgICAgID4gVGhlIFNGQyBXRyBoYXMgcGxh Y2VkIGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnQNCj4gaW4NCj4gPj4+PiBzdGF0 ZQ0KPiA+Pj4+PiAgICAgICAgICAgID4gQ2FuZGlkYXRlIGZvciBXRyBBZG9wdGlvbiAoZW50ZXJl ZCBieSBKb2VsIEhhbHBlcm4pDQo+ID4+Pj4+ICAgICAgICAgICAgPg0KPiA+Pj4+PiAgICAgICAg ICAgID4gVGhlIGRvY3VtZW50IGlzIGF2YWlsYWJsZSBhdA0KPiA+Pj4+PiAgICAgICAgICAgID4N Cj4gPj4+Pj4gICAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWVhc3RsYWtlLXNmYy1uc2gtZWNuLQ0KPiA+Pj4+IHN1cHBvcnQvDQo+ID4+Pj4+ICAgICAgICAg ICAgPg0KPiA+Pj4+PiAgICAgICAgICAgID4gQ29tbWVudDoNCj4gPj4+Pj4gICAgICAgICAgICA+ IFRoaXMgc3RhcnRzIHRoZSBXRyBjYWxsIGZvciBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KPiA+ Pj4+PiAgICAgICAgICAgID4gUGxlYXNlIHJlc3BvbmQgdG8gdGhlIGxpc3QsIGluZGljYXRpbmcg c3VwcG9ydCBmb3IgdGhpcyBhcw0KPiBhDQo+ID4+Pj4+ICAgICAgICAgICB3b3JrIGl0ZW0gb2Yg dGhlDQo+ID4+Pj4+ICAgICAgICAgICAgPiB3b3JraW5nIGdyb3VwIHdpdGggdGhpcyBkb2N1bWVu dCBhcyB0aGUgYmFzaXMgZm9yIHRoZQ0KPiB3b3JrLA0KPiA+Pj4+PiAgICAgICAgICAgb3Igb2Jq ZWN0aW9uIHRvDQo+ID4+Pj4+ICAgICAgICAgICAgPiB0aGUgd29ya2luZyBncm91cCBhZG9wdGlu ZyB0aGlzIGl0ZW0gYXMgYSB3b3JraW5nIGdyb3VwDQo+ID4+IGRyYWZ0Lg0KPiA+Pj4+PiAgICAg ICAgICAgID4NCj4gPj4+Pj4gICAgICAgICAgICA+IFRoZSBhdXRob3JzIHNob3VsZCBjb25maXJt IHRvIHRoZSBjaGFpcnMgYW5kIFdHIHNlY3JldGFyeQ0KPiA+Pj4+PiAgICAgICAgICAgdGhhdCBh bGwgSVBSIGtub3duDQo+ID4+Pj4+ICAgICAgICAgICAgPiB0byB0aGVtIHJlbGV2YW50IHRvIHRo aXMgZHJhZnQgaGFzIGJlZW4gZGlzY2xvc2VkLg0KPiA+Pj4+PiAgICAgICAgICAgID4NCj4gPj4+ Pj4gICAgICAgICAgICA+IFRoZSB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGNhbGwgd2lsbCBsYXN0 IDIgd2Vla3MsIGVuZGluZw0KPiBhdA0KPiA+Pj4+PiAgICAgICAgICAgdGhlIGVuZCBvZiB0aGUN Cj4gPj4+Pj4gICAgICAgICAgICA+IGRheSBvbiBUaHVyc2RheSwgSmFudWFyeSAxNyAyMDE5IENP QiBzb21ld2hlcmUuDQo+ID4+Pj4+ICAgICAgICAgICAgPg0KPiA+Pj4+PiAgICAgICAgICAgID4g VGhhbmsgeW91LA0KPiA+Pj4+PiAgICAgICAgICAgID4gSm9lbA0KPiA+Pj4+PiAgICAgICAgICAg ID4NCj4gPj4+Pj4gICAgICAgICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+Pj4+ICAgICAgICAgICAgPiBzZmMgbWFpbGluZyBsaXN0DQo+ ID4+Pj4+ICAgICAgICAgICAgPiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ ID4+Pj4+ICAgICAgICAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPiA+Pj4+Pg0K From nobody Thu Jan 24 05:39:58 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E0E130E9D; Thu, 24 Jan 2019 05:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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=joelhalpern.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 O1Eyqr0pZVNh; Thu, 24 Jan 2019 05:39:54 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 8041F130E99; Thu, 24 Jan 2019 05:39:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43ljvG2MJkzkZrQ; Thu, 24 Jan 2019 05:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1548337194; bh=npijM/MGmkqpiyur9k8Iy2bmV6doBU3k8xmL9M9aJ5A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eROUfJVMZjYbslIdOTBmPVi49qGkSBHTcqWehtLvJk2cL65uAPOZ2sXs7zH+weAwV 8boizcgaq6abw0AoeyxkwP7AQBU+PqS/8q5jonsbxiv8+swN+WLMmcIPMs3TrSiehv 9IaLU+/KxUybc5MFlAobOXgDScVoPFvK3+W6XToI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43ljvF1CxpzkZrN; Thu, 24 Jan 2019 05:39:52 -0800 (PST) To: mohamed.boucadair@orange.com Cc: "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7899163b-e90e-4fec-a523-a7c4f2e881df@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: Date: Thu, 24 Jan 2019 08:39:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 13:39:57 -0000 Thank you for the citation Med. I would like to hear from others in the working group as to whether they it. Yours, Joel On 1/24/19 1:39 AM, mohamed.boucadair@orange.com wrote: > Joel, > > DSCP preservation is a trivial requirement for intra-domain SFC. Please refer to https://tools.ietf.org/html/rfc2983: > > When a tunnel is not end-to-end, there are > circumstances in which it may be desirable to propagate the DSCP > and/or some of the information that it contains to the outer IP > header on ingress and/or back to inner IP header on egress. > > One of the models discussed in 2983 assumes the following. > > In this model, any packet has exactly one DS Field > that is used for traffic conditioning at any point, namely the DS > Field in the outermost IP header; any others are ignored. > Implementations of this model copy the DSCP value to the outer IP > header at encapsulation and copy the outer header's DSCP value to the > inner IP header at decapsulation. > > Because SFF is an encap/decpa function, it falls under the above implementations. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : mercredi 23 janvier 2019 17:10 >> À : BOUCADAIR Mohamed TGI/OLN >> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in >> state "Candidate for WG Adoption" >> >> >> Maybe I am missing something important, but I would not expect SFF to >> exhibit the behavior you describe relative to DSCPs. >> >> I do not know of any place where this is required for intra-domain >> tunnels. It is an interesting issue for inter-domain usage of SFC. But >> our scope is explicitly intra-domain. >> >> As far as I know, DSCPs are not re-marked within a domain. They are >> modified at entry / exit from a domain, but that is not an issue for an SFF. >> >> Is there someplace where the behavior you are asking about is required >> by existing documents? >> >> Yours, >> Joel >> >> On 1/23/19 8:37 AM, mohamed.boucadair@orange.com wrote: >>> Hi Joel, >>> >>> The point Joel is SFFs has to preserve whatever DSCP marking when >> encapsulating/encapsulation (including cases where transport encap changes). >>> >>> If you will, we can describe the scenario using your words: >>> >>> ======= >>> Consider an SFF that receives a packet with a transport DSCP marking >>> and an NSH header. That SFF removes the transport header. It then >>> (usually) sends the packet via some other means to an SF, and gets the >>> packet back. After which it sends it on to the next SFF with a new >>> transport header carrying the NSH. >>> Let us take as given that we want to support DSCP marking preservation. >>> Then we need to somehow preserve the DSCP information that the SFF >>> receives. >>> ========== >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Envoyé : mardi 22 janvier 2019 13:31 >>>> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis >>>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support >> in >>>> state "Candidate for WG Adoption" >>>> >>>> (again: speaking personally) >>>> DSCP behavior is VERY different from ECN behavior in terms of >>>> intermediate router modification. DSCPs may get rewritten at certain >>>> specific places, but not generally at interior routers. So mapping from >>>> the interior packet DSCP to the exterior packet DSCP and IEEE marking is >>>> normal and safe. there is no need to reverse the process. ECN marking >>>> needs to reverse the process due to the fact that individual routers are >>>> expected to change the marking based on local conditions. >>>> >>>> At least thaat is how I understand it, >>>> Joel >>>> >>>> On 1/22/19 1:25 AM, mohamed.boucadair@orange.com wrote: >>>>> Hi Joel, >>>>> >>>>> What makes ECN specific in this regards compared to DSCP marking >>>> preservation? >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>> Envoyé : vendredi 18 janvier 2019 15:55 >>>>>> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis >>>>>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>>>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn- >> support >>>> in >>>>>> state "Candidate for WG Adoption" >>>>>> >>>>>> >>>>>> Let me try as an individual to paraphrase what I understand the document >>>>>> to be offering. That authors should feel free to comment further >>>>>> including if necessary telling me that I am confused. >>>>>> >>>>>> Consider an SFF that receives a packet with a transport ECN indication >>>>>> and an NSH header. That SFF removes the transport header. It then >>>>>> (usually) sends the packet via some other means to an SF, and gets the >>>>>> packet back. After which it sends it on to the next SFF with a new >>>>>> transport header carrying the NSH. >>>>>> Let us take as given that we want to support effective ECN. >>>>>> Then we need to somehow preserve the ECN information that the SFF >>>> receives. >>>>>> >>>>>> One way would be to insist that the SFF, when it receives the ECN >>>>>> information, has to rummage through to find the internal IP packet, and >>>>>> must update the internal ECN information therein. Ugg. IThat would be >>>>>> a pretty onerous requirement. >>>>>> >>>>>> Instead, the document suggests that the SFF transfer the marking to the >>>>>> NSH header, and then use that NSH marking when it generates the new >>>>>> transport header. This can then be used when the packet exits the NSH >>>>>> domain to propagate the information to the header (which is by >>>>>> definition exposed when the NSH header is removed.) >>>>>> >>>>>> Med, if I understand you properly you are suggesting that the SFF should >>>>>> somehow keep the information from the transport header associated with >>>>>> the packet, but not in the NSH header. In some SFF implementations, and >>>>>> with some ways of working with SFs, that is doable. Requiring that >>>>>> would limit the implementation and deployment choices. >>>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 1/18/19 4:15 AM, mohamed.boucadair@orange.com wrote: >>>>>>> Hi Andy, >>>>>>> >>>>>>> Please see inline. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Med >>>>>>> >>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* Andrew G. Malis >>>>>>> *Envoyé :* jeudi 17 janvier 2019 16:33 >>>>>>> *À :* BOUCADAIR Mohamed TGI/OLN >>>>>>> *Cc :* sfc-chairs@ietf.org; IETF Secretariat; >>>>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>>>>> *Objet :* Re: [sfc] The SFC WG has placed >>>>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" >>>>>>> >>>>>>> Med, >>>>>>> >>>>>>> Your point about RFC 5129 is correct, but I'm not personally aware of >>>>>>> any implementations. And I was just using MPLS as an example, there may >>>>>>> be others in the future as well. >>>>>>> >>>>>>> [Med] I understood this was an example, but still this is IMHO supposed >>>>>>> to be handled among the spirit of the effort led by Bob in 6040 and its >>>>>>> current & futures updates. >>>>>>> >>>>>>> Your point about the SFF preserving ECN is implementation dependent, >> for >>>>>>> example the SFF could have separate input and output interfaces without >>>>>>> shared memory, or the transport encapsulation could change in different >>>>>>> regions of the SFC domain. >>>>>>> >>>>>>> [Med] I don’t understand your point about separate inputs/output >>>>>>> interfaces and the change of encap schemes. Let’s put aside SFC for a >>>>>>> moment and consider the example of a LISP XTR which is supporting ECN >>>>>>> dissemination/handling. That xTR may not use the same in/out >> interfaces, >>>>>>> but still need to achieve some processing when doing its encap/decap. >>>>>>> >>>>>>> It's difficult to depend on SFFs being able to preserve >>>>>>> transport-header-dependent information without that becoming a >>>>>>> requirement in the SFC architecture. >>>>>>> >>>>>>> [Med] I don’t think that we can tag congestion notification as >>>>>>> “transport-header-dependent”. There are ways to pass that info even >> when >>>>>>> the transport encap changes. >>>>>>> >>>>>>> This is IMHO among things that the WG is supposed to cover under this >>>>>>> item in the charter (please note that those are clearing taged as >>>>>>> transport issues): >>>>>>> >>>>>>> == >>>>>>> >>>>>>> 4) Transport Considerations - This will capture the expectations SFC >>>>>>> places on transport behavior, including dealing with issues such as >>>>>>> congestion indications and responses. >>>>>>> >>>>>>> == >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> On Thu, Jan 17, 2019 at 10:02 AM >>>>>> > wrote: >>>>>>> >>>>>>> Hi Andy, >>>>>>> >>>>>>> Please see inline. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Med >>>>>>> >>>>>>> *De :*Andrew G. Malis [mailto:agmalis@gmail.com >>>>>>> ] >>>>>>> *Envoyé :* jeudi 17 janvier 2019 15:50 >>>>>>> *À :* BOUCADAIR Mohamed TGI/OLN >>>>>>> *Cc :* IETF Secretariat; sfc-chairs@ietf.org >>>>>>> ; >>>>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org >>>>>>> ; >> sfc@ietf.org >>>>>>> >>>>>>> *Objet :* Re: [sfc] The SFC WG has placed >>>>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG >>>> Adoption" >>>>>>> >>>>>>> Med, >>>>>>> >>>>>>> Not all transports support ECN marking, for example NSH over >> MPLS. >>>>>>> >>>>>>> [Med] Isn’t this covered by RFC5129? >>>>>>> >>>>>>> And even where the transport supports ECN marking, note the >> example >>>>>>> in Figure 1 in the draft where the outer encapsulation can be >>>>>>> stripped during SFF processing. In that case, the scope of the >> ECN >>>>>>> marking is limited to individual SFF-SFF links. rather than end- >> to- >>>> end. >>>>>>> >>>>>>> [Med] Why couldn’t SFF preserve ECN when doing its transport >>>>>>> decap/encap? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> On Thu, Jan 17, 2019 at 9:12 AM >>>>>> > wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I do think that ECN is naturally better handled at the >> transport >>>>>>> encapsulation instead of the NSH itself. >>>>>>> >>>>>>> Requiring the functionality to be handled at the transport >> encap >>>>>>> (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redundant, >> IMO. >>>>>>> >>>>>>> I like the approach we set in the SFC architecture in which >> we >>>>>>> separated service matters from transport ones. I'd vote for >>>>>>> maintaining that separation cleaner as it was set in the arch >>>> RFC. >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>> > -----Message d'origine----- >>>>>>> > De : sfc [mailto:sfc-bounces@ietf.org >>>>>>> ] De la part de IETF Secretariat >>>>>>> > Envoyé : jeudi 3 janvier 2019 06:11 >>>>>>> > À : sfc-chairs@ietf.org ; >>>>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org >>>>>>> ; >>>>>>> > sfc@ietf.org >>>>>>> > Objet : [sfc] The SFC WG has placed >>>>>>> draft-eastlake-sfc-nsh-ecn-support in >>>>>>> > state "Candidate for WG Adoption" >>>>>>> > >>>>>>> > >>>>>>> > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support >> in >>>>>> state >>>>>>> > Candidate for WG Adoption (entered by Joel Halpern) >>>>>>> > >>>>>>> > The document is available at >>>>>>> > >>>>>>> https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn- >>>>>> support/ >>>>>>> > >>>>>>> > Comment: >>>>>>> > This starts the WG call for adoption of this draft. >>>>>>> > Please respond to the list, indicating support for this as >> a >>>>>>> work item of the >>>>>>> > working group with this document as the basis for the >> work, >>>>>>> or objection to >>>>>>> > the working group adopting this item as a working group >>>> draft. >>>>>>> > >>>>>>> > The authors should confirm to the chairs and WG secretary >>>>>>> that all IPR known >>>>>>> > to them relevant to this draft has been disclosed. >>>>>>> > >>>>>>> > The working group adoption call will last 2 weeks, ending >> at >>>>>>> the end of the >>>>>>> > day on Thursday, January 17 2019 COB somewhere. >>>>>>> > >>>>>>> > Thank you, >>>>>>> > Joel >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > sfc mailing list >>>>>>> > sfc@ietf.org >>>>>>> > https://www.ietf.org/mailman/listinfo/sfc >>>>>>> From nobody Thu Jan 24 06:02:45 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA3C12426A; Thu, 24 Jan 2019 06:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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=joelhalpern.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 VgiGsSNo0j3r; Thu, 24 Jan 2019 06:02:36 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 462D61228B7; Thu, 24 Jan 2019 06:02:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43lkPS0HpczkZrY; Thu, 24 Jan 2019 06:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1548338556; bh=eX1ihVVEVuY9Q0SOFtSL0L4qh5joH1Li6mawfmomG0Y=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=aJpgZncs6RA9LYinQ93htrg4ZlywDzLKmEdDYBcDnkn01COopAisG9+0uwY4JjPpf qbCMJr+sjY7RM2y/9jVauPwTiHs5aeIDrTNeo2NkDFc9Z2gpwD/4merfCA2bInIBU4 IiYd1LipUJKA3ONS65kuKA0WQgkYkJ1Y5M90JzpE= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43lkPR1v4QzKmY3; Thu, 24 Jan 2019 06:02:35 -0800 (PST) From: "Joel M. Halpern" To: mohamed.boucadair@orange.com Cc: "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7899163b-e90e-4fec-a523-a7c4f2e881df@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Message-ID: Date: Thu, 24 Jan 2019 09:02:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 14:02:44 -0000 Apparently I am having trouble typing this morning. Do others understand the DiffServ RFCs to place this requirement on SFC? I am also checking with some other folks who work regularly with DSCPs and the relevant RFCs. Thank you, Joel On 1/24/19 8:39 AM, Joel M. Halpern wrote: > > Thank you for the citation Med. > > I would like to hear from others in the working group as to whether they > it. > > Yours, > Joel > > > On 1/24/19 1:39 AM, mohamed.boucadair@orange.com wrote: >> Joel, >> >> DSCP preservation is a trivial requirement for intra-domain SFC. >> Please refer to https://tools.ietf.org/html/rfc2983: >> >>     When a tunnel is not end-to-end, there are >>     circumstances in which it may be desirable to propagate the DSCP >>     and/or some of the information that it contains to the outer IP >>     header on ingress and/or back to inner IP header on egress. >> >> One of the models discussed in 2983 assumes the following. >> >>     In this model, any packet has exactly one DS Field >>     that is used for traffic conditioning at any point, namely the DS >>     Field in the outermost IP header; any others are ignored. >>     Implementations of this model copy the DSCP value to the outer IP >>     header at encapsulation and copy the outer header's DSCP value to the >>     inner IP header at decapsulation. >> >> Because SFF is an encap/decpa function, it falls under the above >> implementations. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Envoyé : mercredi 23 janvier 2019 17:10 >>> À : BOUCADAIR Mohamed TGI/OLN >>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>> Objet : Re: [sfc] The SFC WG has placed >>> draft-eastlake-sfc-nsh-ecn-support in >>> state "Candidate for WG Adoption" >>> >>> >>> Maybe I am missing something important, but I would not expect SFF to >>> exhibit the behavior you describe relative to DSCPs. >>> >>> I do not know of any place where this is required for intra-domain >>> tunnels.  It is an interesting issue for inter-domain usage of SFC.  But >>> our scope is explicitly intra-domain. >>> >>> As far as I know, DSCPs are not re-marked within a domain.  They are >>> modified at entry / exit from a domain, but that is not an issue for >>> an SFF. >>> >>> Is there someplace where the behavior you are asking about is required >>> by existing documents? >>> >>> Yours, >>> Joel >>> >>> On 1/23/19 8:37 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Joel, >>>> >>>> The point Joel is SFFs has to preserve whatever DSCP marking when >>> encapsulating/encapsulation (including cases where transport encap >>> changes). >>>> >>>> If you will, we can describe the scenario using your words: >>>> >>>> ======= >>>> Consider an SFF that receives a packet with a transport DSCP marking >>>> and an NSH header.  That SFF removes the transport header.  It then >>>> (usually) sends the packet via some other means to an SF, and gets the >>>> packet back.  After which it sends it on to the next SFF with a new >>>> transport header carrying the NSH. >>>> Let us take as given that we want to support DSCP marking preservation. >>>> Then we need to somehow preserve the DSCP information that the SFF >>>> receives. >>>> ========== >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Envoyé : mardi 22 janvier 2019 13:31 >>>>> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis >>>>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>>> Objet : Re: [sfc] The SFC WG has placed >>>>> draft-eastlake-sfc-nsh-ecn-support >>> in >>>>> state "Candidate for WG Adoption" >>>>> >>>>> (again: speaking personally) >>>>> DSCP behavior is VERY different from ECN behavior in terms of >>>>> intermediate router modification.  DSCPs may get rewritten at certain >>>>> specific places, but not generally at interior routers.  So mapping >>>>> from >>>>> the interior packet DSCP to the exterior packet DSCP and IEEE >>>>> marking is >>>>> normal and safe.  there is no need to reverse the process.  ECN >>>>> marking >>>>> needs to reverse the process due to the fact that individual >>>>> routers are >>>>> expected to change the marking based on local conditions. >>>>> >>>>> At least thaat is how I understand it, >>>>> Joel >>>>> >>>>> On 1/22/19 1:25 AM, mohamed.boucadair@orange.com wrote: >>>>>> Hi Joel, >>>>>> >>>>>> What makes ECN specific in this regards compared to DSCP marking >>>>> preservation? >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>>> Envoyé : vendredi 18 janvier 2019 15:55 >>>>>>> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis >>>>>>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>>>>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn- >>> support >>>>> in >>>>>>> state "Candidate for WG Adoption" >>>>>>> >>>>>>> >>>>>>> Let me try as an individual to paraphrase what I understand the >>>>>>> document >>>>>>> to be offering.  That authors should feel free to comment further >>>>>>> including if necessary telling me that I am confused. >>>>>>> >>>>>>> Consider an SFF that receives a packet with a transport ECN >>>>>>> indication >>>>>>> and an NSH header.  That SFF removes the transport header.  It then >>>>>>> (usually) sends the packet via some other means to an SF, and >>>>>>> gets the >>>>>>> packet back.  After which it sends it on to the next SFF with a new >>>>>>> transport header carrying the NSH. >>>>>>> Let us take as given that we want to support effective ECN. >>>>>>> Then we need to somehow preserve the ECN information that the SFF >>>>> receives. >>>>>>> >>>>>>> One way would be to insist that the SFF, when it receives the ECN >>>>>>> information, has to rummage through to find the internal IP >>>>>>> packet, and >>>>>>> must update the internal ECN information therein.  Ugg.  IThat >>>>>>> would be >>>>>>> a pretty onerous requirement. >>>>>>> >>>>>>> Instead, the document suggests that the SFF transfer the marking >>>>>>> to the >>>>>>> NSH header, and then use that NSH marking when it generates the new >>>>>>> transport header.  This can then be used when the packet exits >>>>>>> the NSH >>>>>>> domain to propagate the information to the header (which is by >>>>>>> definition exposed when the NSH header is removed.) >>>>>>> >>>>>>> Med, if I understand you properly you are suggesting that the SFF >>>>>>> should >>>>>>> somehow keep the information from the transport header associated >>>>>>> with >>>>>>> the packet, but not in the NSH header.  In some SFF >>>>>>> implementations, and >>>>>>> with some ways of working with SFs, that is doable.  Requiring that >>>>>>> would limit the implementation and deployment choices. >>>>>>> >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 1/18/19 4:15 AM, mohamed.boucadair@orange.com wrote: >>>>>>>> Hi Andy, >>>>>>>> >>>>>>>> Please see inline. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Med >>>>>>>> >>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* Andrew >>>>>>>> G. Malis >>>>>>>> *Envoyé :* jeudi 17 janvier 2019 16:33 >>>>>>>> *À :* BOUCADAIR Mohamed TGI/OLN >>>>>>>> *Cc :* sfc-chairs@ietf.org; IETF Secretariat; >>>>>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>>>>>> *Objet :* Re: [sfc] The SFC WG has placed >>>>>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG >>>>>>>> Adoption" >>>>>>>> >>>>>>>> Med, >>>>>>>> >>>>>>>> Your point about RFC 5129 is correct, but I'm not personally >>>>>>>> aware of >>>>>>>> any implementations. And I was just using MPLS as an example, >>>>>>>> there may >>>>>>>> be others in the future as well. >>>>>>>> >>>>>>>> [Med] I understood this was an example, but still this is IMHO >>>>>>>> supposed >>>>>>>> to be handled among the spirit of the effort led by Bob in 6040 >>>>>>>> and its >>>>>>>> current & futures updates. >>>>>>>> >>>>>>>> Your point about the SFF preserving ECN is implementation >>>>>>>> dependent, >>> for >>>>>>>> example the SFF could have separate input and output interfaces >>>>>>>> without >>>>>>>> shared memory, or the transport encapsulation could change in >>>>>>>> different >>>>>>>> regions of the SFC domain. >>>>>>>> >>>>>>>> [Med] I don’t understand your point about separate inputs/output >>>>>>>> interfaces and the change of encap schemes. Let’s put aside SFC >>>>>>>> for a >>>>>>>> moment and consider the example of a LISP XTR which is >>>>>>>> supporting ECN >>>>>>>> dissemination/handling. That xTR may not use the same in/out >>> interfaces, >>>>>>>> but still need to achieve some processing when doing its >>>>>>>> encap/decap. >>>>>>>> >>>>>>>> It's difficult to depend on SFFs being able to preserve >>>>>>>> transport-header-dependent information without that becoming a >>>>>>>> requirement in the SFC architecture. >>>>>>>> >>>>>>>> [Med] I don’t think that we can tag congestion notification as >>>>>>>> “transport-header-dependent”. There are ways to pass that info even >>> when >>>>>>>> the transport encap changes. >>>>>>>> >>>>>>>> This is IMHO among things that the WG is supposed to cover under >>>>>>>> this >>>>>>>> item in the charter (please note that those are clearing taged as >>>>>>>> transport issues): >>>>>>>> >>>>>>>> == >>>>>>>> >>>>>>>> 4) Transport Considerations - This will capture the expectations >>>>>>>> SFC >>>>>>>> places on transport behavior, including dealing with issues such as >>>>>>>> congestion indications and responses. >>>>>>>> >>>>>>>> == >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> On Thu, Jan 17, 2019 at 10:02 AM >>>>>>> > wrote: >>>>>>>> >>>>>>>>        Hi Andy, >>>>>>>> >>>>>>>>        Please see inline. >>>>>>>> >>>>>>>>        Cheers, >>>>>>>> >>>>>>>>        Med >>>>>>>> >>>>>>>>        *De :*Andrew G. Malis [mailto:agmalis@gmail.com >>>>>>>>        ] >>>>>>>>        *Envoyé :* jeudi 17 janvier 2019 15:50 >>>>>>>>        *À :* BOUCADAIR Mohamed TGI/OLN >>>>>>>>        *Cc :* IETF Secretariat; sfc-chairs@ietf.org >>>>>>>>        ; >>>>>>>>        draft-eastlake-sfc-nsh-ecn-support@ietf.org >>>>>>>>        ; >>> sfc@ietf.org >>>>>>>>        >>>>>>>>        *Objet :* Re: [sfc] The SFC WG has placed >>>>>>>>        draft-eastlake-sfc-nsh-ecn-support in state "Candidate >>>>>>>> for WG >>>>> Adoption" >>>>>>>> >>>>>>>>        Med, >>>>>>>> >>>>>>>>        Not all transports support ECN marking, for example NSH over >>> MPLS. >>>>>>>> >>>>>>>>        [Med] Isn’t this covered by RFC5129? >>>>>>>> >>>>>>>>        And even where the transport supports ECN marking, note the >>> example >>>>>>>>        in Figure 1 in the draft where the outer encapsulation >>>>>>>> can be >>>>>>>>        stripped during SFF processing. In that case, the scope >>>>>>>> of the >>> ECN >>>>>>>>        marking is limited to individual SFF-SFF links. rather >>>>>>>> than end- >>> to- >>>>> end. >>>>>>>> >>>>>>>>        [Med] Why couldn’t SFF preserve ECN when doing its transport >>>>>>>>        decap/encap? >>>>>>>> >>>>>>>>        Cheers, >>>>>>>> >>>>>>>>        Andy >>>>>>>> >>>>>>>>        On Thu, Jan 17, 2019 at 9:12 AM >>>>>>>> >>>>>>>        > wrote: >>>>>>>> >>>>>>>>            Hi all, >>>>>>>> >>>>>>>>            I do think that ECN is naturally better handled at the >>> transport >>>>>>>>            encapsulation instead of the NSH itself. >>>>>>>> >>>>>>>>            Requiring the functionality to be handled at the >>>>>>>> transport >>> encap >>>>>>>>            (draft-ietf-tsvwg-rfc6040update-shim) and NSH is >>>>>>>> redundant, >>> IMO. >>>>>>>> >>>>>>>>            I like the approach we set in the SFC architecture in >>>>>>>> which >>> we >>>>>>>>            separated service matters from transport ones. I'd >>>>>>>> vote for >>>>>>>>            maintaining that separation cleaner as it was set in >>>>>>>> the arch >>>>> RFC. >>>>>>>> >>>>>>>>            Thank you. >>>>>>>> >>>>>>>>            Cheers, >>>>>>>>            Med >>>>>>>> >>>>>>>>             > -----Message d'origine----- >>>>>>>>             > De : sfc [mailto:sfc-bounces@ietf.org >>>>>>>>            ] De la part de IETF >>>>>>>> Secretariat >>>>>>>>             > Envoyé : jeudi 3 janvier 2019 06:11 >>>>>>>>             > À : sfc-chairs@ietf.org ; >>>>>>>>            draft-eastlake-sfc-nsh-ecn-support@ietf.org >>>>>>>>            ; >>>>>>>>             > sfc@ietf.org >>>>>>>>             > Objet : [sfc] The SFC WG has placed >>>>>>>>            draft-eastlake-sfc-nsh-ecn-support in >>>>>>>>             > state "Candidate for WG Adoption" >>>>>>>>             > >>>>>>>>             > >>>>>>>>             > The SFC WG has placed >>>>>>>> draft-eastlake-sfc-nsh-ecn-support >>> in >>>>>>> state >>>>>>>>             > Candidate for WG Adoption (entered by Joel Halpern) >>>>>>>>             > >>>>>>>>             > The document is available at >>>>>>>>             > >>>>>>>> >>>>>>>> https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn- >>>>>>> support/ >>>>>>>>             > >>>>>>>>             > Comment: >>>>>>>>             > This starts the WG call for adoption of this draft. >>>>>>>>             > Please respond to the list, indicating support for >>>>>>>> this as >>> a >>>>>>>>            work item of the >>>>>>>>             > working group with this document as the basis for the >>> work, >>>>>>>>            or objection to >>>>>>>>             > the working group adopting this item as a working >>>>>>>> group >>>>> draft. >>>>>>>>             > >>>>>>>>             > The authors should confirm to the chairs and WG >>>>>>>> secretary >>>>>>>>            that all IPR known >>>>>>>>             > to them relevant to this draft has been disclosed. >>>>>>>>             > >>>>>>>>             > The working group adoption call will last 2 weeks, >>>>>>>> ending >>> at >>>>>>>>            the end of the >>>>>>>>             > day on Thursday, January 17 2019 COB somewhere. >>>>>>>>             > >>>>>>>>             > Thank you, >>>>>>>>             > Joel >>>>>>>>             > >>>>>>>>             > _______________________________________________ >>>>>>>>             > sfc mailing list >>>>>>>>             > sfc@ietf.org >>>>>>>>             > https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jan 25 21:35:51 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75151128D0C; Fri, 25 Jan 2019 21:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 W6MWvoLhiW2f; Fri, 25 Jan 2019 21:35:46 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 59A25128CF3; Fri, 25 Jan 2019 21:35:46 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id z20so12746579itc.3; Fri, 25 Jan 2019 21:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=isBIKY67iB09hXZOkwG1N8Ygl3Tnq+ETsWfHNFEkXHI=; b=SNYQ/u6ucZ2Im/7aLNRDsVHWke/S1poW2kb7IUVlUDMhS8k94XjAE8fASh+KfAhtHy Cf3Uq/crNiEJ6Z4J2RILwHRrkAfL+jxKhNlpcuaIQytdzAzcjREkn/v4w76OtSnZqoJj lteTpPZp+oEihwA9Mc5uaY/GT9LSMVy9MffofZexJK2RvaRPiEBXBzQ6jU8n/VNo0yIV /NijyOBoirZsSo1p4aYeZbXlDSbdyoSXOlGx8Bw4PLS17p+8nQ+If+HGyFI8T9xUxny8 6JULZPg6vX3AlYCERk3pXqWQHlEHXACpXJ8sK6g/8CqnWz3a8zZfBxWGz6kc8lA71/7r tL0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=isBIKY67iB09hXZOkwG1N8Ygl3Tnq+ETsWfHNFEkXHI=; b=jZxeWeo4oia8RdYZAjPP4KEO9D61kSAfUus1mmSI2on1oub/yOVVd/QLUwUneZZRE8 cpeVRPSip0qlXElWFER7KfBn8wtFSu6bHZXBGTS4ZzForb7eSpldYDKj5qx+izDqqK2D uMNd68N5HOnhp0Op93qKYd0SKmchwKKnvHNiEBVNQ5Sdp7wJij3TEcPvDtt6GTFH97zL 6GpRwbzxKZbiY5yDIzoczoqcOB/aU4fR46+lyWr3wGm4xZjR8VZXn/owlNTaFQ6z48oT fR+D7/d3uu2f/KaSDDquXYP9+h3752Jp//FiR+wMANPcQVIkG85I8Myk9ro+nENudLdw LgDA== X-Gm-Message-State: AJcUukeBgFRUhVQgm+DzI+l8yW7FisJUEZT+/c7NHCrTnzDXFJ5SrMWX k5KYVZ3e+gyd5rhlJhKMVG2RohfIVWn0/HLFcsQ= X-Google-Smtp-Source: ALg8bN6ns8/5B2LNZmre1xzIn4v2DPq2GbD06Xzsq4kwLxA4uZI+qYr6goxRYe/MT8+1IBN5InOkGtNbSQVtAAJkxhQ= X-Received: by 2002:a24:36cf:: with SMTP id l198mr6342415itl.102.1548480945255; Fri, 25 Jan 2019 21:35:45 -0800 (PST) MIME-Version: 1.0 References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7899163b-e90e-4fec-a523-a7c4f2e881df@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Donald Eastlake Date: Sat, 26 Jan 2019 00:35:33 -0500 Message-ID: To: mohamed.boucadair@orange.com Cc: "Joel M. Halpern" , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2019 05:35:50 -0000 Hi Med, See below. On Thu, Jan 24, 2019 at 1:39 AM wrote: > > Joel, > > DSCP preservation is a trivial requirement for intra-domain SFC. Please r= efer to https://tools.ietf.org/html/rfc2983: > > When a tunnel is not end-to-end, there are > circumstances in which it may be desirable to propagate the DSCP > and/or some of the information that it contains to the outer IP > header on ingress and/or back to inner IP header on egress. So, I've read RFC 2983 and consulted with its author David Black. RFC 2983 is not a standards track or BCP RFP. It's just Informational. It focuses on two models, the "uniform" model you describe below and the "pipe model". > One of the models discussed in 2983 assumes the following. > > In this model, any packet has exactly one DS Field > that is used for traffic conditioning at any point, namely the DS > Field in the outermost IP header; any others are ignored. > Implementations of this model copy the DSCP value to the outer IP > header at encapsulation and copy the outer header's DSCP value to the > inner IP header at decapsulation. > > Because SFF is an encap/decpa function, it falls under the above implemen= tations. RFC 2983 doesn't say anything about which model should be used by SFC nor does it say which model should necessarily be used by an "encap/decap function". I continue to believe that the pipe model, which does not require any modification to the inner IP DSCP based on an outer IP DSCP, is more appropriate for SFC. The situation is quite different for ECN, as compared with DSCP. For example, standards track RFC 6040 requires examination of both the outer and inner ECN marking at egress and their combination (or dropping the packet). Thanks, Donald =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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com > Cheers, > Med > > > -----Message d'origine----- > > De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > > Envoy=C3=A9 : mercredi 23 janvier 2019 17:10 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN > > Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > > Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-supp= ort in > > state "Candidate for WG Adoption" > > > > > > Maybe I am missing something important, but I would not expect SFF to > > exhibit the behavior you describe relative to DSCPs. > > > > I do not know of any place where this is required for intra-domain > > tunnels. It is an interesting issue for inter-domain usage of SFC. Bu= t > > our scope is explicitly intra-domain. > > > > As far as I know, DSCPs are not re-marked within a domain. They are > > modified at entry / exit from a domain, but that is not an issue for an= SFF. > > > > Is there someplace where the behavior you are asking about is required > > by existing documents? > > > > Yours, > > Joel > > > > On 1/23/19 8:37 AM, mohamed.boucadair@orange.com wrote: > > > Hi Joel, > > > > > > The point Joel is SFFs has to preserve whatever DSCP marking when > > encapsulating/encapsulation (including cases where transport encap chan= ges). > > > > > > If you will, we can describe the scenario using your words: > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > Consider an SFF that receives a packet with a transport DSCP marking > > > and an NSH header. That SFF removes the transport header. It then > > > (usually) sends the packet via some other means to an SF, and gets th= e > > > packet back. After which it sends it on to the next SFF with a new > > > transport header carrying the NSH. > > > Let us take as given that we want to support DSCP marking preservatio= n. > > > Then we need to somehow preserve the DSCP information that the SFF > > > receives. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Cheers, > > > Med > > > > > >> -----Message d'origine----- > > >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > > >> Envoy=C3=A9 : mardi 22 janvier 2019 13:31 > > >> =C3=80 : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis > > >> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > > >> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-s= upport > > in > > >> state "Candidate for WG Adoption" > > >> > > >> (again: speaking personally) > > >> DSCP behavior is VERY different from ECN behavior in terms of > > >> intermediate router modification. DSCPs may get rewritten at certai= n > > >> specific places, but not generally at interior routers. So mapping = from > > >> the interior packet DSCP to the exterior packet DSCP and IEEE markin= g is > > >> normal and safe. there is no need to reverse the process. ECN mark= ing > > >> needs to reverse the process due to the fact that individual routers= are > > >> expected to change the marking based on local conditions. > > >> > > >> At least thaat is how I understand it, > > >> Joel > > >> > > >> On 1/22/19 1:25 AM, mohamed.boucadair@orange.com wrote: > > >>> Hi Joel, > > >>> > > >>> What makes ECN specific in this regards compared to DSCP marking > > >> preservation? > > >>> > > >>> Cheers, > > >>> Med > > >>> > > >>>> -----Message d'origine----- > > >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > > >>>> Envoy=C3=A9 : vendredi 18 janvier 2019 15:55 > > >>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis > > >>>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > > >>>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn= - > > support > > >> in > > >>>> state "Candidate for WG Adoption" > > >>>> > > >>>> > > >>>> Let me try as an individual to paraphrase what I understand the do= cument > > >>>> to be offering. That authors should feel free to comment further > > >>>> including if necessary telling me that I am confused. > > >>>> > > >>>> Consider an SFF that receives a packet with a transport ECN indica= tion > > >>>> and an NSH header. That SFF removes the transport header. It the= n > > >>>> (usually) sends the packet via some other means to an SF, and gets= the > > >>>> packet back. After which it sends it on to the next SFF with a ne= w > > >>>> transport header carrying the NSH. > > >>>> Let us take as given that we want to support effective ECN. > > >>>> Then we need to somehow preserve the ECN information that the SFF > > >> receives. > > >>>> > > >>>> One way would be to insist that the SFF, when it receives the ECN > > >>>> information, has to rummage through to find the internal IP packet= , and > > >>>> must update the internal ECN information therein. Ugg. IThat wou= ld be > > >>>> a pretty onerous requirement. > > >>>> > > >>>> Instead, the document suggests that the SFF transfer the marking t= o the > > >>>> NSH header, and then use that NSH marking when it generates the ne= w > > >>>> transport header. This can then be used when the packet exits the= NSH > > >>>> domain to propagate the information to the header (which is by > > >>>> definition exposed when the NSH header is removed.) > > >>>> > > >>>> Med, if I understand you properly you are suggesting that the SFF = should > > >>>> somehow keep the information from the transport header associated = with > > >>>> the packet, but not in the NSH header. In some SFF implementation= s, and > > >>>> with some ways of working with SFs, that is doable. Requiring tha= t > > >>>> would limit the implementation and deployment choices. > > >>>> > > >>>> > > >>>> Yours, > > >>>> Joel > > >>>> > > >>>> On 1/18/19 4:15 AM, mohamed.boucadair@orange.com wrote: > > >>>>> Hi Andy, > > >>>>> > > >>>>> Please see inline. > > >>>>> > > >>>>> Cheers, > > >>>>> > > >>>>> Med > > >>>>> > > >>>>> *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* Andrew G.= Malis > > >>>>> *Envoy=C3=A9 :* jeudi 17 janvier 2019 16:33 > > >>>>> *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > > >>>>> *Cc :* sfc-chairs@ietf.org; IETF Secretariat; > > >>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > > >>>>> *Objet :* Re: [sfc] The SFC WG has placed > > >>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Ado= ption" > > >>>>> > > >>>>> Med, > > >>>>> > > >>>>> Your point about RFC 5129 is correct, but I'm not personally awar= e of > > >>>>> any implementations. And I was just using MPLS as an example, the= re may > > >>>>> be others in the future as well. > > >>>>> > > >>>>> [Med] I understood this was an example, but still this is IMHO su= pposed > > >>>>> to be handled among the spirit of the effort led by Bob in 6040 a= nd its > > >>>>> current & futures updates. > > >>>>> > > >>>>> Your point about the SFF preserving ECN is implementation depende= nt, > > for > > >>>>> example the SFF could have separate input and output interfaces w= ithout > > >>>>> shared memory, or the transport encapsulation could change in dif= ferent > > >>>>> regions of the SFC domain. > > >>>>> > > >>>>> [Med] I don=E2=80=99t understand your point about separate inputs= /output > > >>>>> interfaces and the change of encap schemes. Let=E2=80=99s put asi= de SFC for a > > >>>>> moment and consider the example of a LISP XTR which is supporting= ECN > > >>>>> dissemination/handling. That xTR may not use the same in/out > > interfaces, > > >>>>> but still need to achieve some processing when doing its encap/de= cap. > > >>>>> > > >>>>> It's difficult to depend on SFFs being able to preserve > > >>>>> transport-header-dependent information without that becoming a > > >>>>> requirement in the SFC architecture. > > >>>>> > > >>>>> [Med] I don=E2=80=99t think that we can tag congestion notificati= on as > > >>>>> =E2=80=9Ctransport-header-dependent=E2=80=9D. There are ways to p= ass that info even > > when > > >>>>> the transport encap changes. > > >>>>> > > >>>>> This is IMHO among things that the WG is supposed to cover under = this > > >>>>> item in the charter (please note that those are clearing taged as > > >>>>> transport issues): > > >>>>> > > >>>>> =3D=3D > > >>>>> > > >>>>> 4) Transport Considerations - This will capture the expectations = SFC > > >>>>> places on transport behavior, including dealing with issues such = as > > >>>>> congestion indications and responses. > > >>>>> > > >>>>> =3D=3D > > >>>>> > > >>>>> Cheers, > > >>>>> > > >>>>> Andy > > >>>>> > > >>>>> On Thu, Jan 17, 2019 at 10:02 AM > >>>>> > wrote: > > >>>>> > > >>>>> Hi Andy, > > >>>>> > > >>>>> Please see inline. > > >>>>> > > >>>>> Cheers, > > >>>>> > > >>>>> Med > > >>>>> > > >>>>> *De :*Andrew G. Malis [mailto:agmalis@gmail.com > > >>>>> ] > > >>>>> *Envoy=C3=A9 :* jeudi 17 janvier 2019 15:50 > > >>>>> *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > > >>>>> *Cc :* IETF Secretariat; sfc-chairs@ietf.org > > >>>>> ; > > >>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org > > >>>>> ; > > sfc@ietf.org > > >>>>> > > >>>>> *Objet :* Re: [sfc] The SFC WG has placed > > >>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for = WG > > >> Adoption" > > >>>>> > > >>>>> Med, > > >>>>> > > >>>>> Not all transports support ECN marking, for example NSH ove= r > > MPLS. > > >>>>> > > >>>>> [Med] Isn=E2=80=99t this covered by RFC5129? > > >>>>> > > >>>>> And even where the transport supports ECN marking, note the > > example > > >>>>> in Figure 1 in the draft where the outer encapsulation can = be > > >>>>> stripped during SFF processing. In that case, the scope of = the > > ECN > > >>>>> marking is limited to individual SFF-SFF links. rather than= end- > > to- > > >> end. > > >>>>> > > >>>>> [Med] Why couldn=E2=80=99t SFF preserve ECN when doing its = transport > > >>>>> decap/encap? > > >>>>> > > >>>>> Cheers, > > >>>>> > > >>>>> Andy > > >>>>> > > >>>>> On Thu, Jan 17, 2019 at 9:12 AM > >>>>> > wrote: > > >>>>> > > >>>>> Hi all, > > >>>>> > > >>>>> I do think that ECN is naturally better handled at the > > transport > > >>>>> encapsulation instead of the NSH itself. > > >>>>> > > >>>>> Requiring the functionality to be handled at the transp= ort > > encap > > >>>>> (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redund= ant, > > IMO. > > >>>>> > > >>>>> I like the approach we set in the SFC architecture in w= hich > > we > > >>>>> separated service matters from transport ones. I'd vote= for > > >>>>> maintaining that separation cleaner as it was set in th= e arch > > >> RFC. > > >>>>> > > >>>>> Thank you. > > >>>>> > > >>>>> Cheers, > > >>>>> Med > > >>>>> > > >>>>> > -----Message d'origine----- > > >>>>> > De : sfc [mailto:sfc-bounces@ietf.org > > >>>>> ] De la part de IETF Secre= tariat > > >>>>> > Envoy=C3=A9 : jeudi 3 janvier 2019 06:11 > > >>>>> > =C3=80 : sfc-chairs@ietf.org ; > > >>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org > > >>>>> ; > > >>>>> > sfc@ietf.org > > >>>>> > Objet : [sfc] The SFC WG has placed > > >>>>> draft-eastlake-sfc-nsh-ecn-support in > > >>>>> > state "Candidate for WG Adoption" > > >>>>> > > > >>>>> > > > >>>>> > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-sup= port > > in > > >>>> state > > >>>>> > Candidate for WG Adoption (entered by Joel Halpern) > > >>>>> > > > >>>>> > The document is available at > > >>>>> > > > >>>>> https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh= -ecn- > > >>>> support/ > > >>>>> > > > >>>>> > Comment: > > >>>>> > This starts the WG call for adoption of this draft. > > >>>>> > Please respond to the list, indicating support for t= his as > > a > > >>>>> work item of the > > >>>>> > working group with this document as the basis for th= e > > work, > > >>>>> or objection to > > >>>>> > the working group adopting this item as a working gr= oup > > >> draft. > > >>>>> > > > >>>>> > The authors should confirm to the chairs and WG secr= etary > > >>>>> that all IPR known > > >>>>> > to them relevant to this draft has been disclosed. > > >>>>> > > > >>>>> > The working group adoption call will last 2 weeks, e= nding > > at > > >>>>> the end of the > > >>>>> > day on Thursday, January 17 2019 COB somewhere. > > >>>>> > > > >>>>> > Thank you, > > >>>>> > Joel > > >>>>> > > > >>>>> > _______________________________________________ > > >>>>> > sfc mailing list > > >>>>> > sfc@ietf.org > > >>>>> > https://www.ietf.org/mailman/listinfo/sfc > > >>>>> From nobody Sun Jan 27 18:08:29 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4B1130F2C for ; Sun, 27 Jan 2019 18:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XmLTtmUElsbp for ; Sun, 27 Jan 2019 18:08:24 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA50130F34 for ; Sun, 27 Jan 2019 18:08:23 -0800 (PST) Received: from [192.168.1.20] (unknown [119.94.174.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CA3371801591; Mon, 28 Jan 2019 03:08:17 +0100 (CET) To: sfc@ietf.org References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7899163b-e90e-4fec-a523-a7c4f2e881df@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Cc: Donald Eastlake , mohamed.boucadair@orange.co From: Loa Andersson Message-ID: <6474c06e-ae75-3bc7-c44e-13db155faf9e@pi.nu> Date: Mon, 28 Jan 2019 10:08:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 02:08:28 -0000 Working Group, I read the draft and tried to pin down the comments, as far as I can see there is nothing in the current comments that bloack working group adoption, everything could during normal working group process. I actually prefer that it is done this way, rather that in the individual document to better capture wg consensus. To this end the wg chairs may want to include a note in the mail that close the adoption poll to say what the outstanding issues to be solved by the wg are. /Loa On 2019-01-26 13:35, Donald Eastlake wrote: > Hi Med, > > See below. > > On Thu, Jan 24, 2019 at 1:39 AM wrote: >> >> Joel, >> >> DSCP preservation is a trivial requirement for intra-domain SFC. Please refer to https://tools.ietf.org/html/rfc2983: >> >> When a tunnel is not end-to-end, there are >> circumstances in which it may be desirable to propagate the DSCP >> and/or some of the information that it contains to the outer IP >> header on ingress and/or back to inner IP header on egress. > > So, I've read RFC 2983 and consulted with its author David Black. RFC > 2983 is not a standards track or BCP RFP. It's just Informational. It > focuses on two models, the "uniform" model you describe below and the > "pipe model". > >> One of the models discussed in 2983 assumes the following. >> >> In this model, any packet has exactly one DS Field >> that is used for traffic conditioning at any point, namely the DS >> Field in the outermost IP header; any others are ignored. >> Implementations of this model copy the DSCP value to the outer IP >> header at encapsulation and copy the outer header's DSCP value to the >> inner IP header at decapsulation. >> >> Because SFF is an encap/decpa function, it falls under the above implementations. > > RFC 2983 doesn't say anything about which model should be used by SFC > nor does it say which model should necessarily be used by an > "encap/decap function". I continue to believe that the pipe model, > which does not require any modification to the inner IP DSCP based on > an outer IP DSCP, is more appropriate for SFC. > > The situation is quite different for ECN, as compared with DSCP. For > example, standards track RFC 6040 requires examination of both the > outer and inner ECN marking at egress and their combination (or > dropping the packet). > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Envoyé : mercredi 23 janvier 2019 17:10 >>> À : BOUCADAIR Mohamed TGI/OLN >>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in >>> state "Candidate for WG Adoption" >>> >>> >>> Maybe I am missing something important, but I would not expect SFF to >>> exhibit the behavior you describe relative to DSCPs. >>> >>> I do not know of any place where this is required for intra-domain >>> tunnels. It is an interesting issue for inter-domain usage of SFC. But >>> our scope is explicitly intra-domain. >>> >>> As far as I know, DSCPs are not re-marked within a domain. They are >>> modified at entry / exit from a domain, but that is not an issue for an SFF. >>> >>> Is there someplace where the behavior you are asking about is required >>> by existing documents? >>> >>> Yours, >>> Joel >>> >>> On 1/23/19 8:37 AM, mohamed.boucadair@orange.com wrote: >>>> Hi Joel, >>>> >>>> The point Joel is SFFs has to preserve whatever DSCP marking when >>> encapsulating/encapsulation (including cases where transport encap changes). >>>> >>>> If you will, we can describe the scenario using your words: >>>> >>>> ======= >>>> Consider an SFF that receives a packet with a transport DSCP marking >>>> and an NSH header. That SFF removes the transport header. It then >>>> (usually) sends the packet via some other means to an SF, and gets the >>>> packet back. After which it sends it on to the next SFF with a new >>>> transport header carrying the NSH. >>>> Let us take as given that we want to support DSCP marking preservation. >>>> Then we need to somehow preserve the DSCP information that the SFF >>>> receives. >>>> ========== >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Envoyé : mardi 22 janvier 2019 13:31 >>>>> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis >>>>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support >>> in >>>>> state "Candidate for WG Adoption" >>>>> >>>>> (again: speaking personally) >>>>> DSCP behavior is VERY different from ECN behavior in terms of >>>>> intermediate router modification. DSCPs may get rewritten at certain >>>>> specific places, but not generally at interior routers. So mapping from >>>>> the interior packet DSCP to the exterior packet DSCP and IEEE marking is >>>>> normal and safe. there is no need to reverse the process. ECN marking >>>>> needs to reverse the process due to the fact that individual routers are >>>>> expected to change the marking based on local conditions. >>>>> >>>>> At least thaat is how I understand it, >>>>> Joel >>>>> >>>>> On 1/22/19 1:25 AM, mohamed.boucadair@orange.com wrote: >>>>>> Hi Joel, >>>>>> >>>>>> What makes ECN specific in this regards compared to DSCP marking >>>>> preservation? >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>>>> Envoyé : vendredi 18 janvier 2019 15:55 >>>>>>> À : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis >>>>>>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>>>>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn- >>> support >>>>> in >>>>>>> state "Candidate for WG Adoption" >>>>>>> >>>>>>> >>>>>>> Let me try as an individual to paraphrase what I understand the document >>>>>>> to be offering. That authors should feel free to comment further >>>>>>> including if necessary telling me that I am confused. >>>>>>> >>>>>>> Consider an SFF that receives a packet with a transport ECN indication >>>>>>> and an NSH header. That SFF removes the transport header. It then >>>>>>> (usually) sends the packet via some other means to an SF, and gets the >>>>>>> packet back. After which it sends it on to the next SFF with a new >>>>>>> transport header carrying the NSH. >>>>>>> Let us take as given that we want to support effective ECN. >>>>>>> Then we need to somehow preserve the ECN information that the SFF >>>>> receives. >>>>>>> >>>>>>> One way would be to insist that the SFF, when it receives the ECN >>>>>>> information, has to rummage through to find the internal IP packet, and >>>>>>> must update the internal ECN information therein. Ugg. IThat would be >>>>>>> a pretty onerous requirement. >>>>>>> >>>>>>> Instead, the document suggests that the SFF transfer the marking to the >>>>>>> NSH header, and then use that NSH marking when it generates the new >>>>>>> transport header. This can then be used when the packet exits the NSH >>>>>>> domain to propagate the information to the header (which is by >>>>>>> definition exposed when the NSH header is removed.) >>>>>>> >>>>>>> Med, if I understand you properly you are suggesting that the SFF should >>>>>>> somehow keep the information from the transport header associated with >>>>>>> the packet, but not in the NSH header. In some SFF implementations, and >>>>>>> with some ways of working with SFs, that is doable. Requiring that >>>>>>> would limit the implementation and deployment choices. >>>>>>> >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 1/18/19 4:15 AM, mohamed.boucadair@orange.com wrote: >>>>>>>> Hi Andy, >>>>>>>> >>>>>>>> Please see inline. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Med >>>>>>>> >>>>>>>> *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* Andrew G. Malis >>>>>>>> *Envoyé :* jeudi 17 janvier 2019 16:33 >>>>>>>> *À :* BOUCADAIR Mohamed TGI/OLN >>>>>>>> *Cc :* sfc-chairs@ietf.org; IETF Secretariat; >>>>>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org >>>>>>>> *Objet :* Re: [sfc] The SFC WG has placed >>>>>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" >>>>>>>> >>>>>>>> Med, >>>>>>>> >>>>>>>> Your point about RFC 5129 is correct, but I'm not personally aware of >>>>>>>> any implementations. And I was just using MPLS as an example, there may >>>>>>>> be others in the future as well. >>>>>>>> >>>>>>>> [Med] I understood this was an example, but still this is IMHO supposed >>>>>>>> to be handled among the spirit of the effort led by Bob in 6040 and its >>>>>>>> current & futures updates. >>>>>>>> >>>>>>>> Your point about the SFF preserving ECN is implementation dependent, >>> for >>>>>>>> example the SFF could have separate input and output interfaces without >>>>>>>> shared memory, or the transport encapsulation could change in different >>>>>>>> regions of the SFC domain. >>>>>>>> >>>>>>>> [Med] I don’t understand your point about separate inputs/output >>>>>>>> interfaces and the change of encap schemes. Let’s put aside SFC for a >>>>>>>> moment and consider the example of a LISP XTR which is supporting ECN >>>>>>>> dissemination/handling. That xTR may not use the same in/out >>> interfaces, >>>>>>>> but still need to achieve some processing when doing its encap/decap. >>>>>>>> >>>>>>>> It's difficult to depend on SFFs being able to preserve >>>>>>>> transport-header-dependent information without that becoming a >>>>>>>> requirement in the SFC architecture. >>>>>>>> >>>>>>>> [Med] I don’t think that we can tag congestion notification as >>>>>>>> “transport-header-dependent”. There are ways to pass that info even >>> when >>>>>>>> the transport encap changes. >>>>>>>> >>>>>>>> This is IMHO among things that the WG is supposed to cover under this >>>>>>>> item in the charter (please note that those are clearing taged as >>>>>>>> transport issues): >>>>>>>> >>>>>>>> == >>>>>>>> >>>>>>>> 4) Transport Considerations - This will capture the expectations SFC >>>>>>>> places on transport behavior, including dealing with issues such as >>>>>>>> congestion indications and responses. >>>>>>>> >>>>>>>> == >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> On Thu, Jan 17, 2019 at 10:02 AM >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi Andy, >>>>>>>> >>>>>>>> Please see inline. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Med >>>>>>>> >>>>>>>> *De :*Andrew G. Malis [mailto:agmalis@gmail.com >>>>>>>> ] >>>>>>>> *Envoyé :* jeudi 17 janvier 2019 15:50 >>>>>>>> *À :* BOUCADAIR Mohamed TGI/OLN >>>>>>>> *Cc :* IETF Secretariat; sfc-chairs@ietf.org >>>>>>>> ; >>>>>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org >>>>>>>> ; >>> sfc@ietf.org >>>>>>>> >>>>>>>> *Objet :* Re: [sfc] The SFC WG has placed >>>>>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG >>>>> Adoption" >>>>>>>> >>>>>>>> Med, >>>>>>>> >>>>>>>> Not all transports support ECN marking, for example NSH over >>> MPLS. >>>>>>>> >>>>>>>> [Med] Isn’t this covered by RFC5129? >>>>>>>> >>>>>>>> And even where the transport supports ECN marking, note the >>> example >>>>>>>> in Figure 1 in the draft where the outer encapsulation can be >>>>>>>> stripped during SFF processing. In that case, the scope of the >>> ECN >>>>>>>> marking is limited to individual SFF-SFF links. rather than end- >>> to- >>>>> end. >>>>>>>> >>>>>>>> [Med] Why couldn’t SFF preserve ECN when doing its transport >>>>>>>> decap/encap? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> On Thu, Jan 17, 2019 at 9:12 AM >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I do think that ECN is naturally better handled at the >>> transport >>>>>>>> encapsulation instead of the NSH itself. >>>>>>>> >>>>>>>> Requiring the functionality to be handled at the transport >>> encap >>>>>>>> (draft-ietf-tsvwg-rfc6040update-shim) and NSH is redundant, >>> IMO. >>>>>>>> >>>>>>>> I like the approach we set in the SFC architecture in which >>> we >>>>>>>> separated service matters from transport ones. I'd vote for >>>>>>>> maintaining that separation cleaner as it was set in the arch >>>>> RFC. >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>> >>>>>>>> > -----Message d'origine----- >>>>>>>> > De : sfc [mailto:sfc-bounces@ietf.org >>>>>>>> ] De la part de IETF Secretariat >>>>>>>> > Envoyé : jeudi 3 janvier 2019 06:11 >>>>>>>> > À : sfc-chairs@ietf.org ; >>>>>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org >>>>>>>> ; >>>>>>>> > sfc@ietf.org >>>>>>>> > Objet : [sfc] The SFC WG has placed >>>>>>>> draft-eastlake-sfc-nsh-ecn-support in >>>>>>>> > state "Candidate for WG Adoption" >>>>>>>> > >>>>>>>> > >>>>>>>> > The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support >>> in >>>>>>> state >>>>>>>> > Candidate for WG Adoption (entered by Joel Halpern) >>>>>>>> > >>>>>>>> > The document is available at >>>>>>>> > >>>>>>>> https://datatracker.ietf.org/doc/draft-eastlake-sfc-nsh-ecn- >>>>>>> support/ >>>>>>>> > >>>>>>>> > Comment: >>>>>>>> > This starts the WG call for adoption of this draft. >>>>>>>> > Please respond to the list, indicating support for this as >>> a >>>>>>>> work item of the >>>>>>>> > working group with this document as the basis for the >>> work, >>>>>>>> or objection to >>>>>>>> > the working group adopting this item as a working group >>>>> draft. >>>>>>>> > >>>>>>>> > The authors should confirm to the chairs and WG secretary >>>>>>>> that all IPR known >>>>>>>> > to them relevant to this draft has been disclosed. >>>>>>>> > >>>>>>>> > The working group adoption call will last 2 weeks, ending >>> at >>>>>>>> the end of the >>>>>>>> > day on Thursday, January 17 2019 COB somewhere. >>>>>>>> > >>>>>>>> > Thank you, >>>>>>>> > Joel >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > sfc mailing list >>>>>>>> > sfc@ietf.org >>>>>>>> > https://www.ietf.org/mailman/listinfo/sfc >>>>>>>> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Sun Jan 27 19:58:04 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654D2130F0F for ; Sun, 27 Jan 2019 19:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 0LC6JysGVS1Y for ; Sun, 27 Jan 2019 19:58:00 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 9078C12872C for ; Sun, 27 Jan 2019 19:57:59 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id k15-v6so12950874ljc.8 for ; Sun, 27 Jan 2019 19:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j1xCc8C1tvvlfHfwsz+T9kcJNJT29rnkJb9A0ISAN28=; b=IloUaQ7OdA2MlM7SKYDrdIbq19U08Uaij5sX8CHehHsRXPHWzhFtfcs3LceelFlf6a F974AqB+vP63x5fs5wGU83m2OJLtSQeAbwcTeOP6Frs/mvCJ3f4TklkhL1ggB1AzciIE anmgez6bvuY8iHXPrs0uczJ8Ogt3UyTtv5ja/5JgMyG0gq1J7xCTcVmfnV5VYPJyp7/N bW8wue7HQ4I5toDUi19tA82rZpoWdlGqobeiyOcUCgNQGYetIVShU4b3S/tJr9i79luK kHWGehW3POdW8rnvxc+nM8J4/Egljkjp+JMpZOapmENtg4oV+DngD3zJJM7pmTEV3nZd s9cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j1xCc8C1tvvlfHfwsz+T9kcJNJT29rnkJb9A0ISAN28=; b=i+f/ul99JuQGo7bni2b92r7/TCaRe61KFB+EhQlt4x90DRnGkdlNk+a845DZwstf8+ n816yAuAYMekqObdww0kUAErxexIQKENObJHasm0ug70dxpaNOD2d/aYz+/xAJ79D+Kf PU9NkHYDt/CeRYiQpfSXCtNRQbjGzJjVA6GZ2rzhWaq+ukg/BRREGLlVpxINoijQAypc oBw0PuOXQt1TOExPs76a5vSydHlKdVU+52x+bsfoiYFLH5bqwBz9gI/IC0CUn4W/YLvO 5ucliAAKSUX1dgVqupwze9lpD0n9NIxbr/bZVy1x6e7iGc3/Y3xEANiacCqBoSGQQupe W5Ig== X-Gm-Message-State: AHQUAuYZAlyN3NH/c6u4nGmlRA9VnT2PRodJJ69xQ6flz8S/1cLSnrcC llJo8sZ9qf04t6pJiAiDwG52dCfpG+r2jUvuexVi1fmXEXI= X-Google-Smtp-Source: AHgI3IaCK6ZGzRd1DDDCzQnSmwuQv6LWrMjdOLpki6KN8DnmHXhvIhD0YZLk3c6+2IAVhtunhnC3hx+IZ4KBWXknwLM= X-Received: by 2002:a2e:8446:: with SMTP id u6-v6mr4065523ljh.74.1548647877519; Sun, 27 Jan 2019 19:57:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Mon, 28 Jan 2019 11:57:47 +0800 Message-ID: To: "Joel M. Halpern" Cc: "sfc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009f2ecc05807cae82" Archived-At: Subject: Re: [sfc] Regarding draft-eastlake-sfc-nsh-ecn-support adoption call X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 03:58:03 -0000 --0000000000009f2ecc05807cae82 Content-Type: text/plain; charset="UTF-8" Hi, the problem presented in this draft is real, the document is well-written, and thus I support the adoption. I also concur with the proposal Loa have made on the other thread related to WG AP for this draft - summarize the discussion, comments received during the WG AP as To-Do list for the WG. Regards, Greg On Thu, Jan 24, 2019 at 7:14 AM Joel M. Halpern wrote: > While the time for the call has completed, I would like to see the > current discussion resolve before judging the adoption as chair (with Jim). > As a corollary, if anyone who has not spoken up has an opinion about the > adoption, it is still VERY helpful if you speak up. Please provide > motivation for your response. > > If things do not resolve clearly on their own, the chairs will (as is > required) reach a determination anyway, but WG clarity is preferred. > > Thank you, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --0000000000009f2ecc05807cae82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
the problem presented in this draft is real, the= =C2=A0document is well-written, and thus I support the adoption. I also con= cur with the proposal Loa have made on the other thread related to WG AP fo= r this draft - summarize the discussion, comments received during the WG AP= as To-Do list for the WG.

Regards,
Greg=

On Thu, Jan 24, 2019 at 7:14 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
While the time for the call has co= mpleted, I would like to see the
current discussion resolve before judging the adoption as chair (with Jim).=
As a corollary, if anyone who has not spoken up has an opinion about the adoption, it is still VERY helpful if you speak up.=C2=A0 Please provide motivation for your response.

If things do not resolve clearly on their own, the chairs will (as is
required) reach a determination anyway, but WG clarity is preferred.

Thank you,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--0000000000009f2ecc05807cae82-- From nobody Mon Jan 28 00:39:33 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C12130FCA; Mon, 28 Jan 2019 00:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 H-DF8sInBU6E; Mon, 28 Jan 2019 00:39:29 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3B1130FBA; Mon, 28 Jan 2019 00:39:29 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 43p32l4N1DzCrjZ; Mon, 28 Jan 2019 09:39:27 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 43p32l3M5mzDq7C; Mon, 28 Jan 2019 09:39:27 +0100 (CET) Received: from OPEXCAUBM6C.corporate.adroot.infra.ftgroup (10.114.13.35) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 28 Jan 2019 09:39:27 +0100 Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([fe80::f58e:8e9d:ae18:b9e3%21]) with mapi id 14.03.0415.000; Mon, 28 Jan 2019 09:39:26 +0100 From: To: Donald Eastlake CC: "Joel M. Halpern" , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" Thread-Index: AQHUtTj+IaW+OKp4sk2ZzGwoF4HouqXESdFA Date: Mon, 28 Jan 2019 08:39:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA0E314@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7899163b-e90e-4fec-a523-a7c4f2e881df@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 08:39:33 -0000 SGkgRG9uYWxkLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRG9uYWxkIEVhc3RsYWtlIFttYWls dG86ZDNlM2UzQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiBzYW1lZGkgMjYgamFudmllciAyMDE5 IDA2OjM2DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gQ2PCoDogSm9lbCBN LiBIYWxwZXJuOyBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnOw0K PiBzZmNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNl ZCBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0IGluDQo+IHN0YXRlICJDYW5kaWRh dGUgZm9yIFdHIEFkb3B0aW9uIg0KPiANCj4gSGkgTWVkLA0KPiANCj4gU2VlIGJlbG93Lg0KPiAN Cj4gT24gVGh1LCBKYW4gMjQsIDIwMTkgYXQgMTozOSBBTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBKb2VsLA0KPiA+DQo+ID4gRFNDUCBwcmVzZXJ2YXRp b24gaXMgYSB0cml2aWFsIHJlcXVpcmVtZW50IGZvciBpbnRyYS1kb21haW4gU0ZDLiBQbGVhc2UN Cj4gcmVmZXIgdG8gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzI5ODM6DQo+ID4NCj4g PiAgICBXaGVuIGEgdHVubmVsIGlzIG5vdCBlbmQtdG8tZW5kLCB0aGVyZSBhcmUNCj4gPiAgICBj aXJjdW1zdGFuY2VzIGluIHdoaWNoIGl0IG1heSBiZSBkZXNpcmFibGUgdG8gcHJvcGFnYXRlIHRo ZSBEU0NQDQo+ID4gICAgYW5kL29yIHNvbWUgb2YgdGhlIGluZm9ybWF0aW9uIHRoYXQgaXQgY29u dGFpbnMgdG8gdGhlIG91dGVyIElQDQo+ID4gICAgaGVhZGVyIG9uIGluZ3Jlc3MgYW5kL29yIGJh Y2sgdG8gaW5uZXIgSVAgaGVhZGVyIG9uIGVncmVzcy4NCj4gDQo+IFNvLCBJJ3ZlIHJlYWQgUkZD IDI5ODMgYW5kIGNvbnN1bHRlZCB3aXRoIGl0cyBhdXRob3IgRGF2aWQgQmxhY2suIFJGQw0KPiAy OTgzIGlzIG5vdCBhIHN0YW5kYXJkcyB0cmFjayBvciBCQ1AgUkZQLiBJdCdzIGp1c3QgSW5mb3Jt YXRpb25hbC4NCg0KW01lZF0gWWVzLCBidXQgYW4gaW50ZXJlc3RpbmcgUkZDIGFzIHJldmVhbGVk IGJ5IHRoZSB3b3JkaW5nIHVzZWQgaW4gc29tZSBkb2N1bWVudHMsIGUuZy4sIA0KDQpkcmFmdC1p ZXRmLWludGFyZWEtZ3VlOg0KICAgIkZvciBpbnN0YW5jZSwgaWYgYW4gSVAgcGFja2V0IGlzIGJl aW5nDQogICBlbmNhcHN1YWxhdGVkIGluIEdVRSB0aGVuIGRpZmZzZXJ2IGludGVyYWN0aW9uIFtS RkMyOTgzXSBhbmQgRUNODQogICBwcm9wYWdhdGlvbiBmb3IgdHVubmVscyBbUkZDNjA0MF0gU0hP VUxEIGJlIGZvbGxvd2VkLiINCg0Kb3IgUkZDODA4NToNCiAgICJEZXNpZ25pbmcgYSB0dW5uZWxp bmcgbWVjaGFuaXNtIHJlcXVpcmVzIHNpZ25pZmljYW50bHkgbW9yZSBleHBlcnRpc2UNCiAgIHRo YW4gbmVlZGVkIGZvciBtYW55IG90aGVyIFVEUCBhcHBsaWNhdGlvbnMsIGJlY2F1c2UgdHVubmVs cyBhcmUNCiAgIHVzdWFsbHkgaW50ZW5kZWQgdG8gYmUgdHJhbnNwYXJlbnQgdG8gdGhlIGVuZHBv aW50cyB0cmFuc21pdHRpbmcgb3Zlcg0KICAgdGhlbSwgc28gdGhleSBuZWVkIHRvIGNvcnJlY3Rs eSBlbXVsYXRlIHRoZSBiZWhhdmlvciBvZiBhbiBJUCBsaW5rDQogICBbSU5ULVRVTk5FTFNdLCBm b3IgZXhhbXBsZToNCg0KICAgbyAgUmVxdWlyZW1lbnRzIGZvciB0dW5uZWxzIHRoYXQgY2Fycnkg b3IgZW5jYXBzdWxhdGUgdXNpbmcgRUNOIGNvZGUNCiAgICAgIHBvaW50cyBbUkZDNjA0MF0uDQoN CiAgIG8gIFVzYWdlIG9mIHRoZSBJUCBEU0NQIGZpZWxkIGJ5IHR1bm5lbCBlbmRwb2ludHMgW1JG QzI5ODNdLiINCg0KIEl0DQo+IGZvY3VzZXMgb24gdHdvIG1vZGVscywgdGhlICJ1bmlmb3JtIiBt b2RlbCB5b3UgZGVzY3JpYmUgYmVsb3cgYW5kIHRoZQ0KPiAicGlwZSBtb2RlbCIuDQo+IA0KPiA+ IE9uZSBvZiB0aGUgbW9kZWxzIGRpc2N1c3NlZCBpbiAyOTgzIGFzc3VtZXMgdGhlIGZvbGxvd2lu Zy4NCj4gPg0KPiA+ICAgIEluIHRoaXMgbW9kZWwsIGFueSBwYWNrZXQgaGFzIGV4YWN0bHkgb25l IERTIEZpZWxkDQo+ID4gICAgdGhhdCBpcyB1c2VkIGZvciB0cmFmZmljIGNvbmRpdGlvbmluZyBh dCBhbnkgcG9pbnQsIG5hbWVseSB0aGUgRFMNCj4gPiAgICBGaWVsZCBpbiB0aGUgb3V0ZXJtb3N0 IElQIGhlYWRlcjsgYW55IG90aGVycyBhcmUgaWdub3JlZC4NCj4gPiAgICBJbXBsZW1lbnRhdGlv bnMgb2YgdGhpcyBtb2RlbCBjb3B5IHRoZSBEU0NQIHZhbHVlIHRvIHRoZSBvdXRlciBJUA0KPiA+ ICAgIGhlYWRlciBhdCBlbmNhcHN1bGF0aW9uIGFuZCBjb3B5IHRoZSBvdXRlciBoZWFkZXIncyBE U0NQIHZhbHVlIHRvIHRoZQ0KPiA+ICAgIGlubmVyIElQIGhlYWRlciBhdCBkZWNhcHN1bGF0aW9u Lg0KPiA+DQo+ID4gQmVjYXVzZSBTRkYgaXMgYW4gZW5jYXAvZGVjcGEgZnVuY3Rpb24sIGl0IGZh bGxzIHVuZGVyIHRoZSBhYm92ZQ0KPiBpbXBsZW1lbnRhdGlvbnMuDQo+IA0KPiBSRkMgMjk4MyBk b2Vzbid0IHNheSBhbnl0aGluZyBhYm91dCB3aGljaCBtb2RlbCBzaG91bGQgYmUgdXNlZCBieSBT RkMNCj4gbm9yIGRvZXMgaXQgc2F5IHdoaWNoIG1vZGVsIHNob3VsZCBuZWNlc3NhcmlseSBiZSB1 c2VkIGJ5IGFuDQo+ICJlbmNhcC9kZWNhcCBmdW5jdGlvbiIuDQoNCltNZWRdIEFncmVlLiBJIGNp dGVkIHRoZSB1bmlmb3JtIG1vZGVsIGJlY2F1c2UgdGhpcyBpcyB3aGF0IGlzIHJlY29tbWVuZGVk IGluIHNvbWUgbmV0d29ya3MgdG8gcHJlc2VydmUgUW9TIHBvbGljaWVzLCBzZWUgZm9yIGV4YW1w bGUgUkZDNjkwOC4NCg0KIEkgY29udGludWUgdG8gYmVsaWV2ZSB0aGF0IHRoZSBwaXBlIG1vZGVs LA0KPiB3aGljaCBkb2VzIG5vdCByZXF1aXJlIGFueSBtb2RpZmljYXRpb24gdG8gdGhlIGlubmVy IElQIERTQ1AgYmFzZWQgb24NCj4gYW4gb3V0ZXIgSVAgRFNDUCwgaXMgbW9yZSBhcHByb3ByaWF0 ZSBmb3IgU0ZDLg0KDQpbTWVkXSBUaGlzIHNob3VsZCBiZSBkZXBsb3ltZW50LXNwZWNpZmljLCBJ TU86IHRoZSBhcmNoaXRlY3R1cmUgc2hvdWxkIGFsbG93IGZvciBib3RoLiANCg0KSWYgd2UgZm9j dXMgb24gdGhlIHBpcGUgbW9kZWwsIGFuIFNGRiBoYXMgdG8gbG9vayBpbnRvIHRoZSBpbm5lciBo ZWFkZXIgZm9yIGRpZmZzZXJ2IG1hdHRlcnMuIFRoZW4sIGlmIGFuIFNGRiBkb2VzIHRoYXQgZm9y IERTQ1AsIGl0IGNhbiBkbyBpdCBmb3IgRUNOIHRvbyB3aXRob3V0IHJlcXVpcmluZyBkdXBsaWNh dGVkIGZ1bmN0aW9uYWxpdHkgYXQgdGhlIE5TSCBsZXZlbC4NCg0KPiANCj4gVGhlIHNpdHVhdGlv biBpcyBxdWl0ZSBkaWZmZXJlbnQgZm9yIEVDTiwgYXMgY29tcGFyZWQgd2l0aCBEU0NQLiBGb3IN Cj4gZXhhbXBsZSwgc3RhbmRhcmRzIHRyYWNrIFJGQyA2MDQwIHJlcXVpcmVzIGV4YW1pbmF0aW9u IG9mIGJvdGggdGhlDQo+IG91dGVyIGFuZCBpbm5lciBFQ04gbWFya2luZyBhdCBlZ3Jlc3MgYW5k IHRoZWlyIGNvbWJpbmF0aW9uIChvcg0KPiBkcm9wcGluZyB0aGUgcGFja2V0KS4NCj4gDQo+IFRo YW5rcywNCj4gRG9uYWxkDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gIERv bmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzAgKGNlbGwpDQo+ICAxNDI0IFBy byBTaG9wIENvdXJ0LCBEYXZlbnBvcnQsIEZMIDMzODk2IFVTQQ0KPiAgZDNlM2UzQGdtYWlsLmNv bQ0KPiANCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPiA+ID4gRGUgOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhh bHBlcm4uY29tXQ0KPiA+ID4gRW52b3nDqSA6IG1lcmNyZWRpIDIzIGphbnZpZXIgMjAxOSAxNzox MA0KPiA+ID4gw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+ID4gPiBDYyA6IGRyYWZ0 LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZw0KPiA+ ID4gT2JqZXQgOiBSZTogW3NmY10gVGhlIFNGQyBXRyBoYXMgcGxhY2VkIGRyYWZ0LWVhc3RsYWtl LXNmYy1uc2gtZWNuLQ0KPiBzdXBwb3J0IGluDQo+ID4gPiBzdGF0ZSAiQ2FuZGlkYXRlIGZvciBX RyBBZG9wdGlvbiINCj4gPiA+DQo+ID4gPiA8bm8gaGF0Pg0KPiA+ID4gTWF5YmUgSSBhbSBtaXNz aW5nIHNvbWV0aGluZyBpbXBvcnRhbnQsIGJ1dCBJIHdvdWxkIG5vdCBleHBlY3QgU0ZGIHRvDQo+ ID4gPiBleGhpYml0IHRoZSBiZWhhdmlvciB5b3UgZGVzY3JpYmUgcmVsYXRpdmUgdG8gRFNDUHMu DQo+ID4gPg0KPiA+ID4gSSBkbyBub3Qga25vdyBvZiBhbnkgcGxhY2Ugd2hlcmUgdGhpcyBpcyBy ZXF1aXJlZCBmb3IgaW50cmEtZG9tYWluDQo+ID4gPiB0dW5uZWxzLiAgSXQgaXMgYW4gaW50ZXJl c3RpbmcgaXNzdWUgZm9yIGludGVyLWRvbWFpbiB1c2FnZSBvZiBTRkMuICBCdXQNCj4gPiA+IG91 ciBzY29wZSBpcyBleHBsaWNpdGx5IGludHJhLWRvbWFpbi4NCj4gPiA+DQo+ID4gPiBBcyBmYXIg YXMgSSBrbm93LCBEU0NQcyBhcmUgbm90IHJlLW1hcmtlZCB3aXRoaW4gYSBkb21haW4uICBUaGV5 IGFyZQ0KPiA+ID4gbW9kaWZpZWQgYXQgZW50cnkgLyBleGl0IGZyb20gYSBkb21haW4sIGJ1dCB0 aGF0IGlzIG5vdCBhbiBpc3N1ZSBmb3IgYW4NCj4gU0ZGLg0KPiA+ID4NCj4gPiA+IElzIHRoZXJl IHNvbWVwbGFjZSB3aGVyZSB0aGUgYmVoYXZpb3IgeW91IGFyZSBhc2tpbmcgYWJvdXQgaXMgcmVx dWlyZWQNCj4gPiA+IGJ5IGV4aXN0aW5nIGRvY3VtZW50cz8NCj4gPiA+DQo+ID4gPiBZb3VycywN Cj4gPiA+IEpvZWwNCj4gPiA+DQo+ID4gPiBPbiAxLzIzLzE5IDg6MzcgQU0sIG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gPiA+IEhpIEpvZWwsDQo+ID4gPiA+DQo+ID4g PiA+IFRoZSBwb2ludCBKb2VsIGlzIFNGRnMgaGFzIHRvIHByZXNlcnZlIHdoYXRldmVyIERTQ1Ag bWFya2luZyB3aGVuDQo+ID4gPiBlbmNhcHN1bGF0aW5nL2VuY2Fwc3VsYXRpb24gKGluY2x1ZGlu ZyBjYXNlcyB3aGVyZSB0cmFuc3BvcnQgZW5jYXANCj4gY2hhbmdlcykuDQo+ID4gPiA+DQo+ID4g PiA+IElmIHlvdSB3aWxsLCB3ZSBjYW4gZGVzY3JpYmUgdGhlIHNjZW5hcmlvIHVzaW5nIHlvdXIg d29yZHM6DQo+ID4gPiA+DQo+ID4gPiA+ID09PT09PT0NCj4gPiA+ID4gQ29uc2lkZXIgYW4gU0ZG IHRoYXQgcmVjZWl2ZXMgYSBwYWNrZXQgd2l0aCBhIHRyYW5zcG9ydCBEU0NQIG1hcmtpbmcNCj4g PiA+ID4gYW5kIGFuIE5TSCBoZWFkZXIuICBUaGF0IFNGRiByZW1vdmVzIHRoZSB0cmFuc3BvcnQg aGVhZGVyLiAgSXQgdGhlbg0KPiA+ID4gPiAodXN1YWxseSkgc2VuZHMgdGhlIHBhY2tldCB2aWEg c29tZSBvdGhlciBtZWFucyB0byBhbiBTRiwgYW5kIGdldHMgdGhlDQo+ID4gPiA+IHBhY2tldCBi YWNrLiAgQWZ0ZXIgd2hpY2ggaXQgc2VuZHMgaXQgb24gdG8gdGhlIG5leHQgU0ZGIHdpdGggYSBu ZXcNCj4gPiA+ID4gdHJhbnNwb3J0IGhlYWRlciBjYXJyeWluZyB0aGUgTlNILg0KPiA+ID4gPiBM ZXQgdXMgdGFrZSBhcyBnaXZlbiB0aGF0IHdlIHdhbnQgdG8gc3VwcG9ydCBEU0NQIG1hcmtpbmcg cHJlc2VydmF0aW9uLg0KPiA+ID4gPiBUaGVuIHdlIG5lZWQgdG8gc29tZWhvdyBwcmVzZXJ2ZSB0 aGUgRFNDUCBpbmZvcm1hdGlvbiB0aGF0IHRoZSBTRkYNCj4gPiA+ID4gcmVjZWl2ZXMuDQo+ID4g PiA+ID09PT09PT09PT0NCj4gPiA+ID4NCj4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiBNZWQNCj4g PiA+ID4NCj4gPiA+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPj4gRGUg OiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiA+ID4gPj4g RW52b3nDqSA6IG1hcmRpIDIyIGphbnZpZXIgMjAxOSAxMzozMQ0KPiA+ID4gPj4gw4AgOiBCT1VD QURBSVIgTW9oYW1lZCBUR0kvT0xOOyBBbmRyZXcgRy4gTWFsaXMNCj4gPiA+ID4+IENjIDogZHJh ZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydEBpZXRmLm9yZzsgc2ZjQGlldGYub3JnDQo+ ID4gPiA+PiBPYmpldCA6IFJlOiBbc2ZjXSBUaGUgU0ZDIFdHIGhhcyBwbGFjZWQgZHJhZnQtZWFz dGxha2Utc2ZjLW5zaC1lY24tDQo+IHN1cHBvcnQNCj4gPiA+IGluDQo+ID4gPiA+PiBzdGF0ZSAi Q2FuZGlkYXRlIGZvciBXRyBBZG9wdGlvbiINCj4gPiA+ID4+DQo+ID4gPiA+PiAoYWdhaW46IHNw ZWFraW5nIHBlcnNvbmFsbHkpDQo+ID4gPiA+PiBEU0NQIGJlaGF2aW9yIGlzIFZFUlkgZGlmZmVy ZW50IGZyb20gRUNOIGJlaGF2aW9yIGluIHRlcm1zIG9mDQo+ID4gPiA+PiBpbnRlcm1lZGlhdGUg cm91dGVyIG1vZGlmaWNhdGlvbi4gIERTQ1BzIG1heSBnZXQgcmV3cml0dGVuIGF0IGNlcnRhaW4N Cj4gPiA+ID4+IHNwZWNpZmljIHBsYWNlcywgYnV0IG5vdCBnZW5lcmFsbHkgYXQgaW50ZXJpb3Ig cm91dGVycy4gIFNvIG1hcHBpbmcNCj4gZnJvbQ0KPiA+ID4gPj4gdGhlIGludGVyaW9yIHBhY2tl dCBEU0NQIHRvIHRoZSBleHRlcmlvciBwYWNrZXQgRFNDUCBhbmQgSUVFRSBtYXJraW5nDQo+IGlz DQo+ID4gPiA+PiBub3JtYWwgYW5kIHNhZmUuICB0aGVyZSBpcyBubyBuZWVkIHRvIHJldmVyc2Ug dGhlIHByb2Nlc3MuICBFQ04NCj4gbWFya2luZw0KPiA+ID4gPj4gbmVlZHMgdG8gcmV2ZXJzZSB0 aGUgcHJvY2VzcyBkdWUgdG8gdGhlIGZhY3QgdGhhdCBpbmRpdmlkdWFsIHJvdXRlcnMNCj4gYXJl DQo+ID4gPiA+PiBleHBlY3RlZCB0byBjaGFuZ2UgdGhlIG1hcmtpbmcgYmFzZWQgb24gbG9jYWwg Y29uZGl0aW9ucy4NCj4gPiA+ID4+DQo+ID4gPiA+PiBBdCBsZWFzdCB0aGFhdCBpcyBob3cgSSB1 bmRlcnN0YW5kIGl0LA0KPiA+ID4gPj4gSm9lbA0KPiA+ID4gPj4NCj4gPiA+ID4+IE9uIDEvMjIv MTkgMToyNSBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPiA+ID4+ PiBIaSBKb2VsLA0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gV2hhdCBtYWtlcyBFQ04gc3BlY2lmaWMg aW4gdGhpcyByZWdhcmRzIGNvbXBhcmVkIHRvIERTQ1AgbWFya2luZw0KPiA+ID4gPj4gcHJlc2Vy dmF0aW9uPw0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gQ2hlZXJzLA0KPiA+ID4gPj4+IE1lZA0KPiA+ ID4gPj4+DQo+ID4gPiA+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPj4+ PiBEZSA6IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+ID4g PiA+Pj4+IEVudm95w6kgOiB2ZW5kcmVkaSAxOCBqYW52aWVyIDIwMTkgMTU6NTUNCj4gPiA+ID4+ Pj4gw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBBbmRyZXcgRy4gTWFsaXMNCj4gPiA+ ID4+Pj4gQ2MgOiBkcmFmdC1lYXN0bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnOyBz ZmNAaWV0Zi5vcmcNCj4gPiA+ID4+Pj4gT2JqZXQgOiBSZTogW3NmY10gVGhlIFNGQyBXRyBoYXMg cGxhY2VkIGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLQ0KPiA+ID4gc3VwcG9ydA0KPiA+ID4g Pj4gaW4NCj4gPiA+ID4+Pj4gc3RhdGUgIkNhbmRpZGF0ZSBmb3IgV0cgQWRvcHRpb24iDQo+ID4g PiA+Pj4+DQo+ID4gPiA+Pj4+IDxjaGFpciBoYXQgb2ZmPg0KPiA+ID4gPj4+PiBMZXQgbWUgdHJ5 IGFzIGFuIGluZGl2aWR1YWwgdG8gcGFyYXBocmFzZSB3aGF0IEkgdW5kZXJzdGFuZCB0aGUNCj4g ZG9jdW1lbnQNCj4gPiA+ID4+Pj4gdG8gYmUgb2ZmZXJpbmcuICBUaGF0IGF1dGhvcnMgc2hvdWxk IGZlZWwgZnJlZSB0byBjb21tZW50IGZ1cnRoZXINCj4gPiA+ID4+Pj4gaW5jbHVkaW5nIGlmIG5l Y2Vzc2FyeSB0ZWxsaW5nIG1lIHRoYXQgSSBhbSBjb25mdXNlZC4NCj4gPiA+ID4+Pj4NCj4gPiA+ ID4+Pj4gQ29uc2lkZXIgYW4gU0ZGIHRoYXQgcmVjZWl2ZXMgYSBwYWNrZXQgd2l0aCBhIHRyYW5z cG9ydCBFQ04NCj4gaW5kaWNhdGlvbg0KPiA+ID4gPj4+PiBhbmQgYW4gTlNIIGhlYWRlci4gIFRo YXQgU0ZGIHJlbW92ZXMgdGhlIHRyYW5zcG9ydCBoZWFkZXIuICBJdCB0aGVuDQo+ID4gPiA+Pj4+ ICh1c3VhbGx5KSBzZW5kcyB0aGUgcGFja2V0IHZpYSBzb21lIG90aGVyIG1lYW5zIHRvIGFuIFNG LCBhbmQgZ2V0cw0KPiB0aGUNCj4gPiA+ID4+Pj4gcGFja2V0IGJhY2suICBBZnRlciB3aGljaCBp dCBzZW5kcyBpdCBvbiB0byB0aGUgbmV4dCBTRkYgd2l0aCBhIG5ldw0KPiA+ID4gPj4+PiB0cmFu c3BvcnQgaGVhZGVyIGNhcnJ5aW5nIHRoZSBOU0guDQo+ID4gPiA+Pj4+IExldCB1cyB0YWtlIGFz IGdpdmVuIHRoYXQgd2Ugd2FudCB0byBzdXBwb3J0IGVmZmVjdGl2ZSBFQ04uDQo+ID4gPiA+Pj4+ IFRoZW4gd2UgbmVlZCB0byBzb21laG93IHByZXNlcnZlIHRoZSBFQ04gaW5mb3JtYXRpb24gdGhh dCB0aGUgU0ZGDQo+ID4gPiA+PiByZWNlaXZlcy4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gT25l IHdheSB3b3VsZCBiZSB0byBpbnNpc3QgdGhhdCB0aGUgU0ZGLCB3aGVuIGl0IHJlY2VpdmVzIHRo ZSBFQ04NCj4gPiA+ID4+Pj4gaW5mb3JtYXRpb24sIGhhcyB0byBydW1tYWdlIHRocm91Z2ggdG8g ZmluZCB0aGUgaW50ZXJuYWwgSVAgcGFja2V0LA0KPiBhbmQNCj4gPiA+ID4+Pj4gbXVzdCB1cGRh dGUgdGhlIGludGVybmFsIEVDTiBpbmZvcm1hdGlvbiB0aGVyZWluLiAgVWdnLiAgSVRoYXQgd291 bGQNCj4gYmUNCj4gPiA+ID4+Pj4gYSBwcmV0dHkgb25lcm91cyByZXF1aXJlbWVudC4NCj4gPiA+ ID4+Pj4NCj4gPiA+ID4+Pj4gSW5zdGVhZCwgdGhlIGRvY3VtZW50IHN1Z2dlc3RzIHRoYXQgdGhl IFNGRiB0cmFuc2ZlciB0aGUgbWFya2luZyB0bw0KPiB0aGUNCj4gPiA+ID4+Pj4gTlNIIGhlYWRl ciwgYW5kIHRoZW4gdXNlIHRoYXQgTlNIIG1hcmtpbmcgd2hlbiBpdCBnZW5lcmF0ZXMgdGhlIG5l dw0KPiA+ID4gPj4+PiB0cmFuc3BvcnQgaGVhZGVyLiAgVGhpcyBjYW4gdGhlbiBiZSB1c2VkIHdo ZW4gdGhlIHBhY2tldCBleGl0cyB0aGUNCj4gTlNIDQo+ID4gPiA+Pj4+IGRvbWFpbiB0byBwcm9w YWdhdGUgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBoZWFkZXIgKHdoaWNoIGlzIGJ5DQo+ID4gPiA+ Pj4+IGRlZmluaXRpb24gZXhwb3NlZCB3aGVuIHRoZSBOU0ggaGVhZGVyIGlzIHJlbW92ZWQuKQ0K PiA+ID4gPj4+Pg0KPiA+ID4gPj4+PiBNZWQsIGlmIEkgdW5kZXJzdGFuZCB5b3UgcHJvcGVybHkg eW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgdGhlIFNGRg0KPiBzaG91bGQNCj4gPiA+ID4+Pj4gc29t ZWhvdyBrZWVwIHRoZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSB0cmFuc3BvcnQgaGVhZGVyIGFzc29j aWF0ZWQNCj4gd2l0aA0KPiA+ID4gPj4+PiB0aGUgcGFja2V0LCBidXQgbm90IGluIHRoZSBOU0gg aGVhZGVyLiAgSW4gc29tZSBTRkYgaW1wbGVtZW50YXRpb25zLA0KPiBhbmQNCj4gPiA+ID4+Pj4g d2l0aCBzb21lIHdheXMgb2Ygd29ya2luZyB3aXRoIFNGcywgdGhhdCBpcyBkb2FibGUuICBSZXF1 aXJpbmcgdGhhdA0KPiA+ID4gPj4+PiB3b3VsZCBsaW1pdCB0aGUgaW1wbGVtZW50YXRpb24gYW5k IGRlcGxveW1lbnQgY2hvaWNlcy4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gPGNoYWlyIGhhdCBz b21ld2hlcmU+DQo+ID4gPiA+Pj4+IFlvdXJzLA0KPiA+ID4gPj4+PiBKb2VsDQo+ID4gPiA+Pj4+ DQo+ID4gPiA+Pj4+IE9uIDEvMTgvMTkgNDoxNSBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbSB3cm90ZToNCj4gPiA+ID4+Pj4+IEhpIEFuZHksDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+ Pj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gQ2hlZXJzLA0K PiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IE1lZA0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICpE ZSA6KnNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSAqRGUgbGEgcGFydCBkZSogQW5k cmV3IEcuDQo+IE1hbGlzDQo+ID4gPiA+Pj4+PiAqRW52b3nDqSA6KiBqZXVkaSAxNyBqYW52aWVy IDIwMTkgMTY6MzMNCj4gPiA+ID4+Pj4+ICrDgCA6KiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xO DQo+ID4gPiA+Pj4+PiAqQ2MgOiogc2ZjLWNoYWlyc0BpZXRmLm9yZzsgSUVURiBTZWNyZXRhcmlh dDsNCj4gPiA+ID4+Pj4+IGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1cHBvcnRAaWV0Zi5v cmc7IHNmY0BpZXRmLm9yZw0KPiA+ID4gPj4+Pj4gKk9iamV0IDoqIFJlOiBbc2ZjXSBUaGUgU0ZD IFdHIGhhcyBwbGFjZWQNCj4gPiA+ID4+Pj4+IGRyYWZ0LWVhc3RsYWtlLXNmYy1uc2gtZWNuLXN1 cHBvcnQgaW4gc3RhdGUgIkNhbmRpZGF0ZSBmb3IgV0cNCj4gQWRvcHRpb24iDQo+ID4gPiA+Pj4+ Pg0KPiA+ID4gPj4+Pj4gTWVkLA0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IFlvdXIgcG9pbnQg YWJvdXQgUkZDIDUxMjkgaXMgY29ycmVjdCwgYnV0IEknbSBub3QgcGVyc29uYWxseSBhd2FyZQ0K PiBvZg0KPiA+ID4gPj4+Pj4gYW55IGltcGxlbWVudGF0aW9ucy4gQW5kIEkgd2FzIGp1c3QgdXNp bmcgTVBMUyBhcyBhbiBleGFtcGxlLCB0aGVyZQ0KPiBtYXkNCj4gPiA+ID4+Pj4+IGJlIG90aGVy cyBpbiB0aGUgZnV0dXJlIGFzIHdlbGwuDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gW01lZF0g SSB1bmRlcnN0b29kIHRoaXMgd2FzIGFuIGV4YW1wbGUsIGJ1dCBzdGlsbCB0aGlzIGlzIElNSE8N Cj4gc3VwcG9zZWQNCj4gPiA+ID4+Pj4+IHRvIGJlIGhhbmRsZWQgYW1vbmcgdGhlIHNwaXJpdCBv ZiB0aGUgZWZmb3J0IGxlZCBieSBCb2IgaW4gNjA0MCBhbmQNCj4gaXRzDQo+ID4gPiA+Pj4+PiBj dXJyZW50ICYgZnV0dXJlcyB1cGRhdGVzLg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IFlvdXIg cG9pbnQgYWJvdXQgdGhlIFNGRiBwcmVzZXJ2aW5nIEVDTiBpcyBpbXBsZW1lbnRhdGlvbg0KPiBk ZXBlbmRlbnQsDQo+ID4gPiBmb3INCj4gPiA+ID4+Pj4+IGV4YW1wbGUgdGhlIFNGRiBjb3VsZCBo YXZlIHNlcGFyYXRlIGlucHV0IGFuZCBvdXRwdXQgaW50ZXJmYWNlcw0KPiB3aXRob3V0DQo+ID4g PiA+Pj4+PiBzaGFyZWQgbWVtb3J5LCBvciB0aGUgdHJhbnNwb3J0IGVuY2Fwc3VsYXRpb24gY291 bGQgY2hhbmdlIGluDQo+IGRpZmZlcmVudA0KPiA+ID4gPj4+Pj4gcmVnaW9ucyBvZiB0aGUgU0ZD IGRvbWFpbi4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBbTWVkXSBJIGRvbuKAmXQgdW5kZXJz dGFuZCB5b3VyIHBvaW50IGFib3V0IHNlcGFyYXRlIGlucHV0cy9vdXRwdXQNCj4gPiA+ID4+Pj4+ IGludGVyZmFjZXMgYW5kIHRoZSBjaGFuZ2Ugb2YgZW5jYXAgc2NoZW1lcy4gTGV04oCZcyBwdXQg YXNpZGUgU0ZDIGZvcg0KPiBhDQo+ID4gPiA+Pj4+PiBtb21lbnQgYW5kIGNvbnNpZGVyIHRoZSBl eGFtcGxlIG9mIGEgTElTUCBYVFIgd2hpY2ggaXMgc3VwcG9ydGluZw0KPiBFQ04NCj4gPiA+ID4+ Pj4+IGRpc3NlbWluYXRpb24vaGFuZGxpbmcuIFRoYXQgeFRSIG1heSBub3QgdXNlIHRoZSBzYW1l IGluL291dA0KPiA+ID4gaW50ZXJmYWNlcywNCj4gPiA+ID4+Pj4+IGJ1dCBzdGlsbCBuZWVkIHRv IGFjaGlldmUgc29tZSBwcm9jZXNzaW5nIHdoZW4gZG9pbmcgaXRzDQo+IGVuY2FwL2RlY2FwLg0K PiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IEl0J3MgZGlmZmljdWx0IHRvIGRlcGVuZCBvbiBTRkZz IGJlaW5nIGFibGUgdG8gcHJlc2VydmUNCj4gPiA+ID4+Pj4+IHRyYW5zcG9ydC1oZWFkZXItZGVw ZW5kZW50IGluZm9ybWF0aW9uIHdpdGhvdXQgdGhhdCBiZWNvbWluZyBhDQo+ID4gPiA+Pj4+PiBy ZXF1aXJlbWVudCBpbiB0aGUgU0ZDIGFyY2hpdGVjdHVyZS4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+ Pj4+PiBbTWVkXSBJIGRvbuKAmXQgdGhpbmsgdGhhdCB3ZSBjYW4gdGFnIGNvbmdlc3Rpb24gbm90 aWZpY2F0aW9uIGFzDQo+ID4gPiA+Pj4+PiDigJx0cmFuc3BvcnQtaGVhZGVyLWRlcGVuZGVudOKA nS4gVGhlcmUgYXJlIHdheXMgdG8gcGFzcyB0aGF0IGluZm8gZXZlbg0KPiA+ID4gd2hlbg0KPiA+ ID4gPj4+Pj4gdGhlIHRyYW5zcG9ydCBlbmNhcCBjaGFuZ2VzLg0KPiA+ID4gPj4+Pj4NCj4gPiA+ ID4+Pj4+IFRoaXMgaXMgSU1ITyBhbW9uZyB0aGluZ3MgdGhhdCB0aGUgV0cgaXMgc3VwcG9zZWQg dG8gY292ZXIgdW5kZXINCj4gdGhpcw0KPiA+ID4gPj4+Pj4gaXRlbSBpbiB0aGUgY2hhcnRlciAo cGxlYXNlIG5vdGUgdGhhdCB0aG9zZSBhcmUgY2xlYXJpbmcgdGFnZWQgYXMNCj4gPiA+ID4+Pj4+ IHRyYW5zcG9ydCBpc3N1ZXMpOg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ID09DQo+ID4gPiA+ Pj4+Pg0KPiA+ID4gPj4+Pj4gNCkgVHJhbnNwb3J0IENvbnNpZGVyYXRpb25zIC0gVGhpcyB3aWxs IGNhcHR1cmUgdGhlIGV4cGVjdGF0aW9ucw0KPiBTRkMNCj4gPiA+ID4+Pj4+IHBsYWNlcyBvbiB0 cmFuc3BvcnQgYmVoYXZpb3IsIGluY2x1ZGluZyBkZWFsaW5nIHdpdGggaXNzdWVzIHN1Y2ggYXMN Cj4gPiA+ID4+Pj4+IGNvbmdlc3Rpb24gaW5kaWNhdGlvbnMgYW5kIHJlc3BvbnNlcy4NCj4gPiA+ ID4+Pj4+DQo+ID4gPiA+Pj4+PiA9PQ0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IENoZWVycywN Cj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBBbmR5DQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4g T24gVGh1LCBKYW4gMTcsIDIwMTkgYXQgMTA6MDIgQU0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20NCj4gPiA+ID4+Pj4+IDxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+ IHdyb3RlOg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICAgICAgIEhpIEFuZHksDQo+ID4gPiA+ Pj4+Pg0KPiA+ID4gPj4+Pj4gICAgICAgUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPiA+Pj4+Pg0K PiA+ID4gPj4+Pj4gICAgICAgQ2hlZXJzLA0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICAgICAg IE1lZA0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICAgICAgICpEZSA6KkFuZHJldyBHLiBNYWxp cyBbbWFpbHRvOmFnbWFsaXNAZ21haWwuY29tDQo+ID4gPiA+Pj4+PiAgICAgICA8bWFpbHRvOmFn bWFsaXNAZ21haWwuY29tPl0NCj4gPiA+ID4+Pj4+ICAgICAgICpFbnZvecOpIDoqIGpldWRpIDE3 IGphbnZpZXIgMjAxOSAxNTo1MA0KPiA+ID4gPj4+Pj4gICAgICAgKsOAIDoqIEJPVUNBREFJUiBN b2hhbWVkIFRHSS9PTE4NCj4gPiA+ID4+Pj4+ICAgICAgICpDYyA6KiBJRVRGIFNlY3JldGFyaWF0 OyBzZmMtY2hhaXJzQGlldGYub3JnDQo+ID4gPiA+Pj4+PiAgICAgICA8bWFpbHRvOnNmYy1jaGFp cnNAaWV0Zi5vcmc+Ow0KPiA+ID4gPj4+Pj4gICAgICAgZHJhZnQtZWFzdGxha2Utc2ZjLW5zaC1l Y24tc3VwcG9ydEBpZXRmLm9yZw0KPiA+ID4gPj4+Pj4gICAgICAgPG1haWx0bzpkcmFmdC1lYXN0 bGFrZS1zZmMtbnNoLWVjbi1zdXBwb3J0QGlldGYub3JnPjsNCj4gPiA+IHNmY0BpZXRmLm9yZw0K PiA+ID4gPj4+Pj4gICAgICAgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ID4gPiA+Pj4+PiAgICAg ICAqT2JqZXQgOiogUmU6IFtzZmNdIFRoZSBTRkMgV0cgaGFzIHBsYWNlZA0KPiA+ID4gPj4+Pj4g ICAgICAgZHJhZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydCBpbiBzdGF0ZSAiQ2FuZGlk YXRlIGZvciBXRw0KPiA+ID4gPj4gQWRvcHRpb24iDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4g ICAgICAgTWVkLA0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICAgICAgIE5vdCBhbGwgdHJhbnNw b3J0cyBzdXBwb3J0IEVDTiBtYXJraW5nLCBmb3IgZXhhbXBsZSBOU0ggb3Zlcg0KPiA+ID4gTVBM Uy4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiAgICAgICBbTWVkXSBJc27igJl0IHRoaXMgY292 ZXJlZCBieSBSRkM1MTI5Pw0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICAgICAgIEFuZCBldmVu IHdoZXJlIHRoZSB0cmFuc3BvcnQgc3VwcG9ydHMgRUNOIG1hcmtpbmcsIG5vdGUgdGhlDQo+ID4g PiBleGFtcGxlDQo+ID4gPiA+Pj4+PiAgICAgICBpbiBGaWd1cmUgMSBpbiB0aGUgZHJhZnQgd2hl cmUgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24gY2FuIGJlDQo+ID4gPiA+Pj4+PiAgICAgICBzdHJp cHBlZCBkdXJpbmcgU0ZGIHByb2Nlc3NpbmcuIEluIHRoYXQgY2FzZSwgdGhlIHNjb3BlIG9mDQo+ IHRoZQ0KPiA+ID4gRUNODQo+ID4gPiA+Pj4+PiAgICAgICBtYXJraW5nIGlzIGxpbWl0ZWQgdG8g aW5kaXZpZHVhbCBTRkYtU0ZGIGxpbmtzLiByYXRoZXIgdGhhbg0KPiBlbmQtDQo+ID4gPiB0by0N Cj4gPiA+ID4+IGVuZC4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiAgICAgICBbTWVkXSBXaHkg Y291bGRu4oCZdCBTRkYgcHJlc2VydmUgRUNOIHdoZW4gZG9pbmcgaXRzIHRyYW5zcG9ydA0KPiA+ ID4gPj4+Pj4gICAgICAgZGVjYXAvZW5jYXA/DQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gICAg ICAgQ2hlZXJzLA0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICAgICAgIEFuZHkNCj4gPiA+ID4+ Pj4+DQo+ID4gPiA+Pj4+PiAgICAgICBPbiBUaHUsIEphbiAxNywgMjAxOSBhdCA5OjEyIEFNIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+ID4gPiA+Pj4+PiAgICAgICA8bWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+PiB3cm90ZToNCj4gPiA+ID4+Pj4+DQo+ID4gPiA+ Pj4+PiAgICAgICAgICAgSGkgYWxsLA0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICAgICAgICAg ICBJIGRvIHRoaW5rIHRoYXQgRUNOIGlzIG5hdHVyYWxseSBiZXR0ZXIgaGFuZGxlZCBhdCB0aGUN Cj4gPiA+IHRyYW5zcG9ydA0KPiA+ID4gPj4+Pj4gICAgICAgICAgIGVuY2Fwc3VsYXRpb24gaW5z dGVhZCBvZiB0aGUgTlNIIGl0c2VsZi4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiAgICAgICAg ICAgUmVxdWlyaW5nIHRoZSBmdW5jdGlvbmFsaXR5IHRvIGJlIGhhbmRsZWQgYXQgdGhlDQo+IHRy YW5zcG9ydA0KPiA+ID4gZW5jYXANCj4gPiA+ID4+Pj4+ICAgICAgICAgICAoZHJhZnQtaWV0Zi10 c3Z3Zy1yZmM2MDQwdXBkYXRlLXNoaW0pIGFuZCBOU0ggaXMNCj4gcmVkdW5kYW50LA0KPiA+ID4g SU1PLg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICAgICAgICAgICBJIGxpa2UgdGhlIGFwcHJv YWNoIHdlIHNldCBpbiB0aGUgU0ZDIGFyY2hpdGVjdHVyZSBpbg0KPiB3aGljaA0KPiA+ID4gd2UN Cj4gPiA+ID4+Pj4+ICAgICAgICAgICBzZXBhcmF0ZWQgc2VydmljZSBtYXR0ZXJzIGZyb20gdHJh bnNwb3J0IG9uZXMuIEknZCB2b3RlDQo+IGZvcg0KPiA+ID4gPj4+Pj4gICAgICAgICAgIG1haW50 YWluaW5nIHRoYXQgc2VwYXJhdGlvbiBjbGVhbmVyIGFzIGl0IHdhcyBzZXQgaW4gdGhlDQo+IGFy Y2gNCj4gPiA+ID4+IFJGQy4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiAgICAgICAgICAgVGhh bmsgeW91Lg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+ICAgICAgICAgICBDaGVlcnMsDQo+ID4g PiA+Pj4+PiAgICAgICAgICAgTWVkDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gICAgICAgICAg ICA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4gPj4+Pj4gICAgICAgICAgICA+ IERlIDogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA+ID4+Pj4+ICAgICAg ICAgICA8bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnPl0gRGUgbGEgcGFydCBkZSBJRVRGDQo+ IFNlY3JldGFyaWF0DQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4gRW52b3nDqSA6IGpldWRpIDMg amFudmllciAyMDE5IDA2OjExDQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4gw4AgOiBzZmMtY2hh aXJzQGlldGYub3JnIDxtYWlsdG86c2ZjLWNoYWlyc0BpZXRmLm9yZz47DQo+ID4gPiA+Pj4+PiAg ICAgICAgICAgZHJhZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydEBpZXRmLm9yZw0KPiA+ ID4gPj4+Pj4gICAgICAgICAgIDxtYWlsdG86ZHJhZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tc3Vw cG9ydEBpZXRmLm9yZz47DQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4gc2ZjQGlldGYub3JnIDxt YWlsdG86c2ZjQGlldGYub3JnPg0KPiA+ID4gPj4+Pj4gICAgICAgICAgICA+IE9iamV0IDogW3Nm Y10gVGhlIFNGQyBXRyBoYXMgcGxhY2VkDQo+ID4gPiA+Pj4+PiAgICAgICAgICAgZHJhZnQtZWFz dGxha2Utc2ZjLW5zaC1lY24tc3VwcG9ydCBpbg0KPiA+ID4gPj4+Pj4gICAgICAgICAgICA+IHN0 YXRlICJDYW5kaWRhdGUgZm9yIFdHIEFkb3B0aW9uIg0KPiA+ID4gPj4+Pj4gICAgICAgICAgICA+ DQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4NCj4gPiA+ID4+Pj4+ICAgICAgICAgICAgPiBUaGUg U0ZDIFdHIGhhcyBwbGFjZWQgZHJhZnQtZWFzdGxha2Utc2ZjLW5zaC1lY24tDQo+IHN1cHBvcnQN Cj4gPiA+IGluDQo+ID4gPiA+Pj4+IHN0YXRlDQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4gQ2Fu ZGlkYXRlIGZvciBXRyBBZG9wdGlvbiAoZW50ZXJlZCBieSBKb2VsIEhhbHBlcm4pDQo+ID4gPiA+ Pj4+PiAgICAgICAgICAgID4NCj4gPiA+ID4+Pj4+ICAgICAgICAgICAgPiBUaGUgZG9jdW1lbnQg aXMgYXZhaWxhYmxlIGF0DQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4NCj4gPiA+ID4+Pj4+ICAg ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1lYXN0bGFrZS1z ZmMtbnNoLQ0KPiBlY24tDQo+ID4gPiA+Pj4+IHN1cHBvcnQvDQo+ID4gPiA+Pj4+PiAgICAgICAg ICAgID4NCj4gPiA+ID4+Pj4+ICAgICAgICAgICAgPiBDb21tZW50Og0KPiA+ID4gPj4+Pj4gICAg ICAgICAgICA+IFRoaXMgc3RhcnRzIHRoZSBXRyBjYWxsIGZvciBhZG9wdGlvbiBvZiB0aGlzIGRy YWZ0Lg0KPiA+ID4gPj4+Pj4gICAgICAgICAgICA+IFBsZWFzZSByZXNwb25kIHRvIHRoZSBsaXN0 LCBpbmRpY2F0aW5nIHN1cHBvcnQgZm9yDQo+IHRoaXMgYXMNCj4gPiA+IGENCj4gPiA+ID4+Pj4+ ICAgICAgICAgICB3b3JrIGl0ZW0gb2YgdGhlDQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4gd29y a2luZyBncm91cCB3aXRoIHRoaXMgZG9jdW1lbnQgYXMgdGhlIGJhc2lzIGZvciB0aGUNCj4gPiA+ IHdvcmssDQo+ID4gPiA+Pj4+PiAgICAgICAgICAgb3Igb2JqZWN0aW9uIHRvDQo+ID4gPiA+Pj4+ PiAgICAgICAgICAgID4gdGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRpbmcgdGhpcyBpdGVtIGFzIGEg d29ya2luZw0KPiBncm91cA0KPiA+ID4gPj4gZHJhZnQuDQo+ID4gPiA+Pj4+PiAgICAgICAgICAg ID4NCj4gPiA+ID4+Pj4+ICAgICAgICAgICAgPiBUaGUgYXV0aG9ycyBzaG91bGQgY29uZmlybSB0 byB0aGUgY2hhaXJzIGFuZCBXRw0KPiBzZWNyZXRhcnkNCj4gPiA+ID4+Pj4+ICAgICAgICAgICB0 aGF0IGFsbCBJUFIga25vd24NCj4gPiA+ID4+Pj4+ICAgICAgICAgICAgPiB0byB0aGVtIHJlbGV2 YW50IHRvIHRoaXMgZHJhZnQgaGFzIGJlZW4gZGlzY2xvc2VkLg0KPiA+ID4gPj4+Pj4gICAgICAg ICAgICA+DQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4gVGhlIHdvcmtpbmcgZ3JvdXAgYWRvcHRp b24gY2FsbCB3aWxsIGxhc3QgMiB3ZWVrcywNCj4gZW5kaW5nDQo+ID4gPiBhdA0KPiA+ID4gPj4+ Pj4gICAgICAgICAgIHRoZSBlbmQgb2YgdGhlDQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4gZGF5 IG9uIFRodXJzZGF5LCBKYW51YXJ5IDE3IDIwMTkgQ09CIHNvbWV3aGVyZS4NCj4gPiA+ID4+Pj4+ ICAgICAgICAgICAgPg0KPiA+ID4gPj4+Pj4gICAgICAgICAgICA+IFRoYW5rIHlvdSwNCj4gPiA+ ID4+Pj4+ICAgICAgICAgICAgPiBKb2VsDQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4NCj4gPiA+ ID4+Pj4+ICAgICAgICAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+ID4gPj4+Pj4gICAgICAgICAgICA+IHNmYyBtYWlsaW5nIGxpc3QNCj4g PiA+ID4+Pj4+ICAgICAgICAgICAgPiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+ID4gPiA+Pj4+PiAgICAgICAgICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4gPiA+ID4+Pj4+DQo= From nobody Mon Jan 28 06:59:07 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C8F128D52; Mon, 28 Jan 2019 06:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 mvVu8CCJJewl; Mon, 28 Jan 2019 06:59:02 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 0E894124408; Mon, 28 Jan 2019 06:59:02 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id d15so9549579qkj.0; Mon, 28 Jan 2019 06:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QuyguDB/TQA4q+scPmwCdBwsOSNk2uyZJ3uGTLQfjNI=; b=pR3SD3vmraMorASwaVASy6FOFy06ODxz496PUJ0SBFceYTcHcYpumSsfMtF15JUwwj a74f1exz2+7c6IcQEmu0LZ8JLOOHh/80ZFNXov4Qp1v2SOYMmQLZSQ7c09BKE3GHU9Px zihG1Et9Y5N3hfU6lJ19qTKLWpLze03FocJPIQANSIKsgMx40VYRT0lw9y9xq8Jj9Esa xJpMTWpFu0kv+rIeDL4R7fZ0UT+MNUvh1S5URczipLJGrjnGPEnppMkecO20vzEcFbP5 QRQ//2T7UHGHmrcR6tzvTOq+c5mVfQUJeup+/xdx2g3yi+q/VpRXuqAJhAmk1AMSSyte TDWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QuyguDB/TQA4q+scPmwCdBwsOSNk2uyZJ3uGTLQfjNI=; b=Q91+uicE4Wd9O2/Kia3gHfEDlofFIIYb0UG+nefnwtnYAqnATUgs8SCKrV16qFc8t/ XNdeIHj4XH836yVUGISVAKVCe18piDyajwy7/UgnSYrNN8YWorr5CN4ckrwlO3S6UWXi XJuMfUzRnfG7ELm2YrWorwOOZ7FqR+xPFbM4SSLlxR3WYuScTTg5zBsBdXupwIXu9NrM f5BvLnHebGy4n1ivKBr0iM6Ez+HqsL6BGsTuCSIxe9DPTvcK+y+oxtjBtOabSZ+61mOz /GfJ4hKsSiqVwHBbhYsHbmk8V5WQMIlDTLlQHrmo//WM+pJ2XTwIhaEqMMIPpfU80kJc 82XA== X-Gm-Message-State: AJcUukc2ucanjjFNREfTYYKUttQB723JMo8K8FFZmNCwbPCbFeP1BU6g Y98Z7BAPRqGizntNFV557UOcpCDcJM67XpiV6Ak= X-Google-Smtp-Source: ALg8bN6majS3qKNqKXe7dtHVEDuN2Y4C3b7ASEL99tq/d/1Z5iTEkQBkIW6OQEwoU4/NbE4Y4/kaR0eQa1Vu+kFBrDk= X-Received: by 2002:a37:7a06:: with SMTP id v6mr19130600qkc.10.1548687541163; Mon, 28 Jan 2019 06:59:01 -0800 (PST) MIME-Version: 1.0 References: <154822457647.13175.11898836000808295251.idtracker@ietfa.amsl.com> In-Reply-To: <154822457647.13175.11898836000808295251.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Mon, 28 Jan 2019 09:58:50 -0500 Message-ID: To: Tal Mizrahi Cc: sfc-chairs@ietf.org, Martin Vigoureux , sfc@ietf.org Content-Type: multipart/alternative; boundary="000000000000c25b8c058085eaf8" Archived-At: Subject: Re: [sfc] sfc - New Meeting Session Request for IETF 104 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 14:59:05 -0000 --000000000000c25b8c058085eaf8 Content-Type: text/plain; charset="UTF-8" Tal, Please add detnet as a conflict to avoid. At IETF 103, sfc and detnet were at the same time, which inconvenienced a bunch of people (I believe including you :-). Thanks, Andy On Wed, Jan 23, 2019 at 1:23 AM IETF Meeting Session Request Tool < session-request@ietf.org> wrote: > > > A new meeting session request has just been submitted by Tal Mizrahi, a > Secretary of the sfc working group. > > > --------------------------------------------------------- > Working Group Name: Service Function Chaining > Area Name: Routing Area > Session Requester: Tal Mizrahi > > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 100 > Conflicts to Avoid: > First Priority: bess idr i2nsf ippm mpls spring rtgwg lisp ntp teas > > > > > People who must be present: > Joel M. Halpern > Jim Guichard > Martin Vigoureux > Tal Mizrahi > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --000000000000c25b8c058085eaf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tal,

Please add detnet as a conflict to= avoid. At IETF 103, sfc and detnet=C2=A0were at the same time, which incon= venienced a bunch of people (I believe including you :-).

Thanks,
Andy


On Wed, Jan 23, 2019 at 1:23 AM IETF Meeting Session Request Tool <<= a href=3D"mailto:session-request@ietf.org" target=3D"_blank">session-reques= t@ietf.org> wrote:


A new meeting session request has just been submitted by Tal Mizrahi, a Sec= retary of the sfc working group.


---------------------------------------------------------
Working Group Name: Service Function Chaining
Area Name: Routing Area
Session Requester: Tal Mizrahi

Number of Sessions: 1
Length of Session(s):=C2=A0 2 Hours
Number of Attendees: 100
Conflicts to Avoid:
=C2=A0First Priority:=C2=A0 bess idr i2nsf ippm mpls spring rtgwg lisp ntp = teas




People who must be present:
=C2=A0 Joel M. Halpern
=C2=A0 Jim Guichard
=C2=A0 Martin Vigoureux
=C2=A0 Tal Mizrahi

Resources Requested:

Special Requests:

---------------------------------------------------------

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--000000000000c25b8c058085eaf8-- From nobody Mon Jan 28 13:18:21 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F06C130F03 for ; Mon, 28 Jan 2019 13:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 NM0y3uYpY9sy for ; Mon, 28 Jan 2019 13:18:16 -0800 (PST) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (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 915C912E7C1 for ; Mon, 28 Jan 2019 13:18:16 -0800 (PST) Received: by mail-ua1-f43.google.com with SMTP id d21so6126669uap.9 for ; Mon, 28 Jan 2019 13:18:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i9XCRnGRo0pANWP39ddym0ty2IPPuekr7TrbiCxXZaA=; b=bAsu5eZSYT6dswhXtxmOw5Vt4sP0HhXG7XRu/nasF3KPMlegLxOina5I+OWI8LZfXn HWHqXkGBas8ninFxb/KPCIk69Bv0MqBJCn2akBCdN55c7T+HlG5Ze4qnAkk9cJ0AJr4y 0C7Cpyagb/xef7fVNw04RSR/bjy5fn8rUiZI2Zj/7Y8cLBKK4LU4KU2uMdSgrDji0QRR K9SkuO1AbeCcO124/J/fHEbUMK4OHXezL83j7+PC7xSAvYwW3G9x7Ong4iOTQP0GEKzU NX5wg35ibbFnXmHcId1pqBMBL90OR5TLqONKlmfyqHlOvPQwGdnrnvPaSbAuwgGrjIBR NEgw== X-Gm-Message-State: AJcUukeozarceH4TyLE/83q4mAfJxwzR+dzI7PBpXYok/vH5ucY5w2oC plri2re6nMpqPMU/HrEw+rYU6O2JJ48kKqpGNt46pQ== X-Google-Smtp-Source: ALg8bN5r9HW3Z2csvy4GFGOfXSldNAXHUTyTebdtyOU+dzCDvjIz1UfTmp2ONwVBjM4f4oATOkXkbnf0iJ1tPCXWbNo= X-Received: by 2002:ab0:148e:: with SMTP id d14mr9608049uae.23.1548710295472; Mon, 28 Jan 2019 13:18:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Anoop Ghanwani Date: Mon, 28 Jan 2019 13:18:02 -0800 Message-ID: To: "Joel M. Halpern" Cc: "sfc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sfc] Regarding draft-eastlake-sfc-nsh-ecn-support adoption call X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 21:18:19 -0000 I read the draft and had a clarification question about Section 1.3 and Section 4. Is the draft suggestion an alternate congestion control mechanism between tunnel ingress and tunnel egress which is working separately from end-to-end congestion control that requires ECN? If it's just about propagation of bits for the original feedback loop (i.e. before the tunnel header is added), I support the draft. If it's attempting to define a new congestion feedback loop and mechanism, I think it may need more discussion. Thanks, Anoop On Wed, Jan 23, 2019 at 3:14 PM Joel M. Halpern wrote: > > While the time for the call has completed, I would like to see the > current discussion resolve before judging the adoption as chair (with Jim). > As a corollary, if anyone who has not spoken up has an opinion about the > adoption, it is still VERY helpful if you speak up. Please provide > motivation for your response. > > If things do not resolve clearly on their own, the chairs will (as is > required) reach a determination anyway, but WG clarity is preferred. > > Thank you, > Joel > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jan 28 13:20:12 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC0D131200 for ; Mon, 28 Jan 2019 13:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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=joelhalpern.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 xvKA2hz6lxtA for ; Mon, 28 Jan 2019 13:20:09 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 EFBE21311FE for ; Mon, 28 Jan 2019 13:20:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43pMwS4gQnzj3p4; Mon, 28 Jan 2019 13:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1548710408; bh=2lLmtl0hbF9zrr+JNSMiYqc4Bthdt06jZHUUre9ci/E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LP5/eykVNwEu0Jeni2z1VbaoNJ4bGzqsw3aU1R7BNv5kv3KyGoyvabKIf0u5/6q8D zPhCUqVTvB189GN3k3TpbcP/d+ktqtLxU/Ee4/Z5D6PVAl3znaWFBbxTlnN6OWL43S 2uSUi7hX1I0bHLOWrIKQ4Sb9b1r8IhOxZv4FM028= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43pMwR5jPyzj3kq; Mon, 28 Jan 2019 13:20:07 -0800 (PST) To: Anoop Ghanwani Cc: "sfc@ietf.org" References: From: Joel Halpern Direct Message-ID: <2a7e8ef0-4528-663e-89f6-51a0ea729013@joelhalpern.com> Date: Mon, 28 Jan 2019 16:20:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 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: Re: [sfc] Regarding draft-eastlake-sfc-nsh-ecn-support adoption call X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 21:20:11 -0000 I am pretty sure that what is intended is exactly what you say you support, namely simple propagation of the information for the ECN control loop, not a new loop. Can you suggest additional or modified owrding for the document to help make this clear to readers? Thank you, Joel On 1/28/19 4:18 PM, Anoop Ghanwani wrote: > I read the draft and had a clarification question about Section 1.3 > and Section 4. > > Is the draft suggestion an alternate congestion control mechanism > between tunnel ingress and tunnel egress which is working separately > from end-to-end congestion control that requires ECN? > > If it's just about propagation of bits for the original feedback loop > (i.e. before the tunnel header is added), I support the draft. If > it's attempting to define a new congestion feedback loop and > mechanism, I think it may need more discussion. > > Thanks, > Anoop > > On Wed, Jan 23, 2019 at 3:14 PM Joel M. Halpern wrote: >> >> While the time for the call has completed, I would like to see the >> current discussion resolve before judging the adoption as chair (with Jim). >> As a corollary, if anyone who has not spoken up has an opinion about the >> adoption, it is still VERY helpful if you speak up. Please provide >> motivation for your response. >> >> If things do not resolve clearly on their own, the chairs will (as is >> required) reach a determination anyway, but WG clarity is preferred. >> >> Thank you, >> Joel >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jan 28 13:23:16 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE14C12E7C1 for ; Mon, 28 Jan 2019 13:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 c10rlbmbfdkL for ; Mon, 28 Jan 2019 13:23:13 -0800 (PST) Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (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 97E59131204 for ; Mon, 28 Jan 2019 13:23:13 -0800 (PST) Received: by mail-vs1-f43.google.com with SMTP id v205so10685803vsc.3 for ; Mon, 28 Jan 2019 13:23:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7oAnOtzINrceSqvDNZqDBfpW9nTXKyItBs/MSoBOUEs=; b=dOEd83kkNwyO5/bCjnAwFUE3teLv2rdjGJA9jflHpkUWJ55RAkgI24PM5btCOcqmIV BCRtFGYb4F9rAMi/6k4VcjzTZ5iXUfCvh1WvYhvvpTDXme2kkgDQC1ONzoMdbSIVwLuj wjpR30JmmdT9x/6AJ63/PtTvoL0jjlIKLSv8ZhZEZ5aICQVYfNacQyyKixOlKuJMLaQl PuuvciLGI8kl8Qph958w0bXQYcnCismvbx5qGnSBR48bj5NzHOMeAqT6f7w/TSnRdgUJ FBsicIuaKT5xhYalEF9YJYtaIadr8djRSFmJZSjgkL10yy56Tx4Z1xL7udn+xxKJFyg9 gDEA== X-Gm-Message-State: AJcUukdy2MzJTIgMj/i94FDieJw5PFEk1yI14vGQ8RGHFnnrDa3hbkq1 C0BBoXpJMKcrXJQxkAcx0rCzEYYUZ/gNlpchB9w= X-Google-Smtp-Source: ALg8bN77vX3i+kmSvZnXPweIJONSepmoEd9YuRzCn12Bt3i57jH9SYCuLHsQwCk3d3QKaIacK+m22eJxMhXY+x6P+wE= X-Received: by 2002:a67:4bcd:: with SMTP id f74mr9795225vsg.60.1548710592596; Mon, 28 Jan 2019 13:23:12 -0800 (PST) MIME-Version: 1.0 References: <2a7e8ef0-4528-663e-89f6-51a0ea729013@joelhalpern.com> In-Reply-To: <2a7e8ef0-4528-663e-89f6-51a0ea729013@joelhalpern.com> From: Anoop Ghanwani Date: Mon, 28 Jan 2019 13:23:00 -0800 Message-ID: To: Joel Halpern Direct Cc: "sfc@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sfc] Regarding draft-eastlake-sfc-nsh-ecn-support adoption call X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 21:23:16 -0000 Hi Joel, If that is truly the case, then I think Sections 1.3 and 4 should be removed. Otherwise, I myself am not clear what 1.3 and 4 are trying to accomplish and therefore would need clarification on that from the authors. Thanks, Anoop On Mon, Jan 28, 2019 at 1:20 PM Joel Halpern Direct wrote: > > I am pretty sure that what is intended is exactly what you say you > support, namely simple propagation of the information for the ECN > control loop, not a new loop. > > Can you suggest additional or modified owrding for the document to help > make this clear to readers? > > Thank you, > Joel > > On 1/28/19 4:18 PM, Anoop Ghanwani wrote: > > I read the draft and had a clarification question about Section 1.3 > > and Section 4. > > > > Is the draft suggestion an alternate congestion control mechanism > > between tunnel ingress and tunnel egress which is working separately > > from end-to-end congestion control that requires ECN? > > > > If it's just about propagation of bits for the original feedback loop > > (i.e. before the tunnel header is added), I support the draft. If > > it's attempting to define a new congestion feedback loop and > > mechanism, I think it may need more discussion. > > > > Thanks, > > Anoop > > > > On Wed, Jan 23, 2019 at 3:14 PM Joel M. Halpern wrote: > >> > >> While the time for the call has completed, I would like to see the > >> current discussion resolve before judging the adoption as chair (with Jim). > >> As a corollary, if anyone who has not spoken up has an opinion about the > >> adoption, it is still VERY helpful if you speak up. Please provide > >> motivation for your response. > >> > >> If things do not resolve clearly on their own, the chairs will (as is > >> required) reach a determination anyway, but WG clarity is preferred. > >> > >> Thank you, > >> Joel > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jan 28 17:48:34 2019 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB72127B4C; Mon, 28 Jan 2019 17:48:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <154872650438.3046.15979562979593264804@ietfa.amsl.com> Date: Mon, 28 Jan 2019 17:48:24 -0800 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 01:48:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Active OAM for Service Function Chains in Networks Authors : Greg Mirsky Wei Meng Bhumip Khasnabish Cui Wang Filename : draft-ietf-sfc-multi-layer-oam-01.txt Pages : 15 Date : 2019-01-28 Abstract: A set of requirements for active Operation, Administration and Maintenance (OAM) of Service Function Chains (SFCs) in networks is presented. Based on these requirements an encapsulation of active OAM message in SFC and a mechanism to detect and localize defects described. Also, this document updates RFC 8300 in the definition of O (OAM) bit in the Network Service Header (NSH) and defines how the active OAM message identified in SFC NSH. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-01 https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-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 Mon Jan 28 17:52:50 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C6F12875B for ; Mon, 28 Jan 2019 17:52:49 -0800 (PST) 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, FREEMAIL_FROM=0.001, 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=gmail.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 I_0n9PfUqGHn for ; Mon, 28 Jan 2019 17:52:47 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 E5781127B4C for ; Mon, 28 Jan 2019 17:52:46 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id s5-v6so16009126ljd.12 for ; Mon, 28 Jan 2019 17:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fp8FX8YF1T0PTcZOFMibn283ubziBVAGudpsrhZ1NYE=; b=vRygL/wuhjU+5OXYrSG1S5rHzchsOwKe9AT31r4ViVbjBAkfdvbLv8hbMjSxGWD2lm Iims1x4ayxgRwGKIBld9YOZjB8mJLZ32IBjJ2+U2rgR44Q1ZYZwInaVEjXeexu1A3K+1 xSZ/y+t9vx0OAdnoOip7Hp+2zG05LDqS0cSZIGdgPH0Px1LTIpfMNaitcaWTWy/SSw3I nMqt9xin0p46V9uOnKaLvcFZ8H6QVyCrNzEIRu/JwmPVVkPyX43Bt3a+i8q2eT+fZD73 flQXv/+QAcFrhx7kHenm3qYSJ4jUQM0wxiGhC8AQkS43na8lJgvlwsn/D/yoB/kffTZN wgxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=fp8FX8YF1T0PTcZOFMibn283ubziBVAGudpsrhZ1NYE=; b=BebIBOlqTLH3Ayr038AH9qDPvU/uTkOzzXITyzxmumyqiDQw8v0KXnZFfnlv3qTPXe v4sKyxUYhJN5eZxNXrVpyj6TGbbnv0WyMNXS+UfN7tXafvaUOMxs07cpKPVBLcFqHzcr HPZ0loL0nbQsCNPWWSBa6mP/vOt/o2hMJb/Vkgq4LlH5GeMOnhQNlQeW9fucmn3Fb2+I fL8k125bpGwwstwZLmQPUcF9oB8K9sGJSfXq2h3TCXjoK6359PeE+Cs8kA1EPbbs5zOY 3T2Sdj4zVXWk658L0IPplaRT4OOsNSm+cpcwrkunwhMSUI1k/iEFHWuWsYfCSjzJp9oj U9uw== X-Gm-Message-State: AJcUukcnPo1iDmpp0l/VayepSBGkA7vppii2mvWaNQu+9EY9+KmNDsE3 5m5MS2uhQEjQCp7RuJF3G7zRzoBQIozRk/oH73CdqbD9 X-Google-Smtp-Source: ALg8bN4gKWK9SRgOU+LRtjuaFw6g2hpqcTnTBFM1pfJqMrRhopE+H6m+Tv9dmnL/SpSeWwJUfb6eKe3TZWZmcGeJSms= X-Received: by 2002:a2e:9f0b:: with SMTP id u11-v6mr17399968ljk.99.1548726764517; Mon, 28 Jan 2019 17:52:44 -0800 (PST) MIME-Version: 1.0 References: <154872650456.3046.12486139930224299393.idtracker@ietfa.amsl.com> In-Reply-To: <154872650456.3046.12486139930224299393.idtracker@ietfa.amsl.com> From: Greg Mirsky Date: Tue, 29 Jan 2019 09:52:35 +0800 Message-ID: To: Service Function Chaining IETF list Content-Type: multipart/alternative; boundary="000000000000a73e0005808f0c52" Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-ietf-sfc-multi-layer-oam-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 01:52:49 -0000 --000000000000a73e0005808f0c52 Content-Type: text/plain; charset="UTF-8" Dear All, this version includes updates to address (apologies it took too long) comments received at our meeting in Bangkok from Adrian. Much appreciate your reviews, comments, and question on the draft. Regards, Greg ---------- Forwarded message --------- From: Date: Tue, Jan 29, 2019 at 9:48 AM Subject: New Version Notification for draft-ietf-sfc-multi-layer-oam-01.txt To: , Gregory Mirsky , Bhumip Khasnabish , Wei Meng , Cui(Linda) Wang A new version of I-D, draft-ietf-sfc-multi-layer-oam-01.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-sfc-multi-layer-oam Revision: 01 Title: Active OAM for Service Function Chains in Networks Document date: 2019-01-28 Group: sfc Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-ietf-sfc-multi-layer-oam-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/ Htmlized: https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-multi-layer-oam-01 Abstract: A set of requirements for active Operation, Administration and Maintenance (OAM) of Service Function Chains (SFCs) in networks is presented. Based on these requirements an encapsulation of active OAM message in SFC and a mechanism to detect and localize defects described. Also, this document updates RFC 8300 in the definition of O (OAM) bit in the Network Service Header (NSH) and defines how the active OAM message identified in SFC NSH. 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 --000000000000a73e0005808f0c52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
this version includes updates to address (ap= ologies it took too long) comments received at our meeting in Bangkok from = Adrian.
Much appreciate your reviews, comments, and question on t= he draft.

Regards,
Greg

---------- Forwarde= d message ---------
From: <internet-drafts@ietf.org>
Date: Tue, J= an 29, 2019 at 9:48 AM
Subject: New Version Notification for draft-ietf-= sfc-multi-layer-oam-01.txt
To: <sfc-chairs@ietf.org>, Gregory Mirsky <gregimirsky@gmail.com>, Bhumip Khasnabish <vumip1@gmail.com>, Wei Meng <meng.wei2@zte.com.cn>, Cui(Linda) = Wang <lindawangjoy@gmail.com>



A new version of I-D, draft-ietf-sfc-multi-laye= r-oam-01.txt
has been successfully submitted by Greg Mirsky and posted t= o the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-sfc-multi-laye= r-oam
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Active OAM for Service Function Chains in Networks
Doc= ument date:=C2=A0 2019-01-28
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sf= c
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15
URL:=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.ietf.org/internet-drafts/draft-ietf-sfc-multi-layer-oam-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam= /
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-sfc-multi-layer-oam-01
= Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-mult= i-layer-oam-01

Abstract:
=C2=A0 =C2=A0A set of requirements for active Operation, A= dministration and
=C2=A0 =C2=A0Maintenance (OAM) of Service Function Cha= ins (SFCs) in networks is
=C2=A0 =C2=A0presented.=C2=A0 Based on these r= equirements an encapsulation of active
=C2=A0 =C2=A0OAM message in SFC a= nd a mechanism to detect and localize defects
=C2=A0 =C2=A0described.=C2= =A0 Also, this document updates RFC 8300 in the definition of
=C2=A0 =C2= =A0O (OAM) bit in the Network Service Header (NSH) and defines how the
= =C2=A0 =C2=A0active OAM message identified in SFC NSH.




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

The IETF Secretariat

--000000000000a73e0005808f0c52-- From nobody Wed Jan 30 18:14:52 2019 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFCB1271FF; Wed, 30 Jan 2019 18:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 w7QnLzMY5qzU; Wed, 30 Jan 2019 18:14:48 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 5AA01130EBA; Wed, 30 Jan 2019 18:14:48 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id g8so1341038iok.4; Wed, 30 Jan 2019 18:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AP5lg2OstijlpZXB7tFSYnjcdv8geMxnEWV8TVMjmjQ=; b=WNsShMtVSZaLJhZ/alG3tJ+YdMWpEVMF5T8kGHhm0MVj5miqjTQTvpW26a53GOhu8n fy1aWIuei73MBRi9LcvONMQGx1qAsRkKQsXq+ZRHPXdhESpqDS0pZQ6YbOBvyE5YMHkO NCgTn4YBgu7p/9lV+us0NV/8LIG+rpoHEPOVAhKA0Gw4Gc7+3WPdXxV/ediTjWktKhuI xrMsHAm6fhSzkhQjTLJx9bvyOA6BRumzrIJ105P3PxwOrbKcvLoO+8RtBJYclVVR25E7 aJOcAsYyD3sfAs/Nv1JALFLk+s9EhQpWwJWQV1qducJO7ayUUCIuCet1gpMrz8EWsr7R jNuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AP5lg2OstijlpZXB7tFSYnjcdv8geMxnEWV8TVMjmjQ=; b=RnviQElGysO/XMtseIJ9/7pEb/fcCP0z3tTnAlynPuZt+e2nclKqvGVJZd7HUSjarA ZXnwb+ps/hkvcxefTybYyJ3MQUx0nhN0f/08mASrViuR07ZTYEmR/jXQBBeMeK0qD8Zi ybOr83e3PK/1TYzCcbKRM5PPl82qRdVfx8XY/TXIB1d15Qb1+AuJaC2c1Oa7+CSw7Vdk bh4HdVFljxnZtwsoCsTe8HXFSNJn7cvtvTQiBue1kgsbh27J6da1J2sR7oooxDcpizbN 8CB2qjEew55hwVGIgy4e+sS0W6X2ns5oVxcSq6LxIzP/RnkTufMrKrc5qZUn54yEC1vq fQhw== X-Gm-Message-State: AHQUAuYrOZs6OyuoEUpgzAWnTK9I941WwNfvQATWCkTGK1Jbc/KGfPGo 30EnCv9cOT4+1S27exfFJ/EMonJv2hff5TVDR/g= X-Google-Smtp-Source: AHgI3IaSIIqI/nFJWTgVEt1bWIeKSahAccWdsBV7DqQQdnjenWmGMoJgBCpTYcGPkbajdPSXZ1YsWfRnw6N6v1htH8M= X-Received: by 2002:a6b:3945:: with SMTP id g66mr2580859ioa.131.1548900887344; Wed, 30 Jan 2019 18:14:47 -0800 (PST) MIME-Version: 1.0 References: <154649225579.32607.12231566034033496144.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA09352@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA095B8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0A2A3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <63f32944-4adf-cb3b-ad6c-aaf3cc8f0a99@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0B65E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0CA9A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7899163b-e90e-4fec-a523-a7c4f2e881df@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93302EA0CF5E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA0E314@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA0E314@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Donald Eastlake Date: Wed, 30 Jan 2019 21:14:35 -0500 Message-ID: To: mohamed.boucadair@orange.com Cc: "Joel M. Halpern" , "draft-eastlake-sfc-nsh-ecn-support@ietf.org" , "sfc@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG Adoption" X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 02:14:51 -0000 I guess that at this point it depends mostly on how often you think the different circumstances will occur. I don't think people will use outer DSCP marking that much in SFC domains. While it is plausible for the egress SFF to change the DSCP, I think it would only rarely depend on how an outer DSCP was manipulated across the SFC domain. If I am correct then it is significantly more effort to handle ECN between the outer and inner IP. Maybe we need to make competing presentations and see which way the room hums in Prague... Thanks, Donald =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 Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Mon, Jan 28, 2019 at 3:39 AM wrote: > > Hi Donald, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Donald Eastlake [mailto:d3e3e3@gmail.com] > > Envoy=C3=A9 : samedi 26 janvier 2019 06:36 > > =C3=80 : BOUCADAIR Mohamed TGI/OLN > > Cc : Joel M. Halpern; draft-eastlake-sfc-nsh-ecn-support@ietf.org; > > sfc@ietf.org > > Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn-supp= ort in > > state "Candidate for WG Adoption" > > > > Hi Med, > > > > See below. > > > > On Thu, Jan 24, 2019 at 1:39 AM wrote: > > > > > > Joel, > > > > > > DSCP preservation is a trivial requirement for intra-domain SFC. Plea= se > > refer to https://tools.ietf.org/html/rfc2983: > > > > > > When a tunnel is not end-to-end, there are > > > circumstances in which it may be desirable to propagate the DSCP > > > and/or some of the information that it contains to the outer IP > > > header on ingress and/or back to inner IP header on egress. > > > > So, I've read RFC 2983 and consulted with its author David Black. RFC > > 2983 is not a standards track or BCP RFP. It's just Informational. > > [Med] Yes, but an interesting RFC as revealed by the wording used in some= documents, e.g., > > draft-ietf-intarea-gue: > "For instance, if an IP packet is being > encapsualated in GUE then diffserv interaction [RFC2983] and ECN > propagation for tunnels [RFC6040] SHOULD be followed." > > or RFC8085: > "Designing a tunneling mechanism requires significantly more expertise > than needed for many other UDP applications, because tunnels are > usually intended to be transparent to the endpoints transmitting over > them, so they need to correctly emulate the behavior of an IP link > [INT-TUNNELS], for example: > > o Requirements for tunnels that carry or encapsulate using ECN code > points [RFC6040]. > > o Usage of the IP DSCP field by tunnel endpoints [RFC2983]." > > It > > focuses on two models, the "uniform" model you describe below and the > > "pipe model". > > > > > One of the models discussed in 2983 assumes the following. > > > > > > In this model, any packet has exactly one DS Field > > > that is used for traffic conditioning at any point, namely the DS > > > Field in the outermost IP header; any others are ignored. > > > Implementations of this model copy the DSCP value to the outer IP > > > header at encapsulation and copy the outer header's DSCP value to = the > > > inner IP header at decapsulation. > > > > > > Because SFF is an encap/decpa function, it falls under the above > > implementations. > > > > RFC 2983 doesn't say anything about which model should be used by SFC > > nor does it say which model should necessarily be used by an > > "encap/decap function". > > [Med] Agree. I cited the uniform model because this is what is recommende= d in some networks to preserve QoS policies, see for example RFC6908. > > I continue to believe that the pipe model, > > which does not require any modification to the inner IP DSCP based on > > an outer IP DSCP, is more appropriate for SFC. > > [Med] This should be deployment-specific, IMO: the architecture should al= low for both. > > If we focus on the pipe model, an SFF has to look into the inner header f= or diffserv matters. Then, if an SFF does that for DSCP, it can do it for E= CN too without requiring duplicated functionality at the NSH level. > > > > > The situation is quite different for ECN, as compared with DSCP. For > > example, standards track RFC 6040 requires examination of both the > > outer and inner ECN marking at egress and their combination (or > > dropping the packet). > > > > Thanks, > > Donald > > =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 > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 1424 Pro Shop Court, Davenport, FL 33896 USA > > d3e3e3@gmail.com > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > > > > Envoy=C3=A9 : mercredi 23 janvier 2019 17:10 > > > > =C3=80 : BOUCADAIR Mohamed TGI/OLN > > > > Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > > > > Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-ecn- > > support in > > > > state "Candidate for WG Adoption" > > > > > > > > > > > > Maybe I am missing something important, but I would not expect SFF = to > > > > exhibit the behavior you describe relative to DSCPs. > > > > > > > > I do not know of any place where this is required for intra-domain > > > > tunnels. It is an interesting issue for inter-domain usage of SFC.= But > > > > our scope is explicitly intra-domain. > > > > > > > > As far as I know, DSCPs are not re-marked within a domain. They ar= e > > > > modified at entry / exit from a domain, but that is not an issue fo= r an > > SFF. > > > > > > > > Is there someplace where the behavior you are asking about is requi= red > > > > by existing documents? > > > > > > > > Yours, > > > > Joel > > > > > > > > On 1/23/19 8:37 AM, mohamed.boucadair@orange.com wrote: > > > > > Hi Joel, > > > > > > > > > > The point Joel is SFFs has to preserve whatever DSCP marking when > > > > encapsulating/encapsulation (including cases where transport encap > > changes). > > > > > > > > > > If you will, we can describe the scenario using your words: > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D > > > > > Consider an SFF that receives a packet with a transport DSCP mark= ing > > > > > and an NSH header. That SFF removes the transport header. It th= en > > > > > (usually) sends the packet via some other means to an SF, and get= s the > > > > > packet back. After which it sends it on to the next SFF with a n= ew > > > > > transport header carrying the NSH. > > > > > Let us take as given that we want to support DSCP marking preserv= ation. > > > > > Then we need to somehow preserve the DSCP information that the SF= F > > > > > receives. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > >> -----Message d'origine----- > > > > >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > > > > >> Envoy=C3=A9 : mardi 22 janvier 2019 13:31 > > > > >> =C3=80 : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis > > > > >> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > > > > >> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh-e= cn- > > support > > > > in > > > > >> state "Candidate for WG Adoption" > > > > >> > > > > >> (again: speaking personally) > > > > >> DSCP behavior is VERY different from ECN behavior in terms of > > > > >> intermediate router modification. DSCPs may get rewritten at ce= rtain > > > > >> specific places, but not generally at interior routers. So mapp= ing > > from > > > > >> the interior packet DSCP to the exterior packet DSCP and IEEE ma= rking > > is > > > > >> normal and safe. there is no need to reverse the process. ECN > > marking > > > > >> needs to reverse the process due to the fact that individual rou= ters > > are > > > > >> expected to change the marking based on local conditions. > > > > >> > > > > >> At least thaat is how I understand it, > > > > >> Joel > > > > >> > > > > >> On 1/22/19 1:25 AM, mohamed.boucadair@orange.com wrote: > > > > >>> Hi Joel, > > > > >>> > > > > >>> What makes ECN specific in this regards compared to DSCP markin= g > > > > >> preservation? > > > > >>> > > > > >>> Cheers, > > > > >>> Med > > > > >>> > > > > >>>> -----Message d'origine----- > > > > >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > > > > >>>> Envoy=C3=A9 : vendredi 18 janvier 2019 15:55 > > > > >>>> =C3=80 : BOUCADAIR Mohamed TGI/OLN; Andrew G. Malis > > > > >>>> Cc : draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > > > > >>>> Objet : Re: [sfc] The SFC WG has placed draft-eastlake-sfc-nsh= -ecn- > > > > support > > > > >> in > > > > >>>> state "Candidate for WG Adoption" > > > > >>>> > > > > >>>> > > > > >>>> Let me try as an individual to paraphrase what I understand th= e > > document > > > > >>>> to be offering. That authors should feel free to comment furt= her > > > > >>>> including if necessary telling me that I am confused. > > > > >>>> > > > > >>>> Consider an SFF that receives a packet with a transport ECN > > indication > > > > >>>> and an NSH header. That SFF removes the transport header. It= then > > > > >>>> (usually) sends the packet via some other means to an SF, and = gets > > the > > > > >>>> packet back. After which it sends it on to the next SFF with = a new > > > > >>>> transport header carrying the NSH. > > > > >>>> Let us take as given that we want to support effective ECN. > > > > >>>> Then we need to somehow preserve the ECN information that the = SFF > > > > >> receives. > > > > >>>> > > > > >>>> One way would be to insist that the SFF, when it receives the = ECN > > > > >>>> information, has to rummage through to find the internal IP pa= cket, > > and > > > > >>>> must update the internal ECN information therein. Ugg. IThat= would > > be > > > > >>>> a pretty onerous requirement. > > > > >>>> > > > > >>>> Instead, the document suggests that the SFF transfer the marki= ng to > > the > > > > >>>> NSH header, and then use that NSH marking when it generates th= e new > > > > >>>> transport header. This can then be used when the packet exits= the > > NSH > > > > >>>> domain to propagate the information to the header (which is by > > > > >>>> definition exposed when the NSH header is removed.) > > > > >>>> > > > > >>>> Med, if I understand you properly you are suggesting that the = SFF > > should > > > > >>>> somehow keep the information from the transport header associa= ted > > with > > > > >>>> the packet, but not in the NSH header. In some SFF implementa= tions, > > and > > > > >>>> with some ways of working with SFs, that is doable. Requiring= that > > > > >>>> would limit the implementation and deployment choices. > > > > >>>> > > > > >>>> > > > > >>>> Yours, > > > > >>>> Joel > > > > >>>> > > > > >>>> On 1/18/19 4:15 AM, mohamed.boucadair@orange.com wrote: > > > > >>>>> Hi Andy, > > > > >>>>> > > > > >>>>> Please see inline. > > > > >>>>> > > > > >>>>> Cheers, > > > > >>>>> > > > > >>>>> Med > > > > >>>>> > > > > >>>>> *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de* Andre= w G. > > Malis > > > > >>>>> *Envoy=C3=A9 :* jeudi 17 janvier 2019 16:33 > > > > >>>>> *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > > > > >>>>> *Cc :* sfc-chairs@ietf.org; IETF Secretariat; > > > > >>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org; sfc@ietf.org > > > > >>>>> *Objet :* Re: [sfc] The SFC WG has placed > > > > >>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate for WG > > Adoption" > > > > >>>>> > > > > >>>>> Med, > > > > >>>>> > > > > >>>>> Your point about RFC 5129 is correct, but I'm not personally = aware > > of > > > > >>>>> any implementations. And I was just using MPLS as an example,= there > > may > > > > >>>>> be others in the future as well. > > > > >>>>> > > > > >>>>> [Med] I understood this was an example, but still this is IMH= O > > supposed > > > > >>>>> to be handled among the spirit of the effort led by Bob in 60= 40 and > > its > > > > >>>>> current & futures updates. > > > > >>>>> > > > > >>>>> Your point about the SFF preserving ECN is implementation > > dependent, > > > > for > > > > >>>>> example the SFF could have separate input and output interfac= es > > without > > > > >>>>> shared memory, or the transport encapsulation could change in > > different > > > > >>>>> regions of the SFC domain. > > > > >>>>> > > > > >>>>> [Med] I don=E2=80=99t understand your point about separate in= puts/output > > > > >>>>> interfaces and the change of encap schemes. Let=E2=80=99s put= aside SFC for > > a > > > > >>>>> moment and consider the example of a LISP XTR which is suppor= ting > > ECN > > > > >>>>> dissemination/handling. That xTR may not use the same in/out > > > > interfaces, > > > > >>>>> but still need to achieve some processing when doing its > > encap/decap. > > > > >>>>> > > > > >>>>> It's difficult to depend on SFFs being able to preserve > > > > >>>>> transport-header-dependent information without that becoming = a > > > > >>>>> requirement in the SFC architecture. > > > > >>>>> > > > > >>>>> [Med] I don=E2=80=99t think that we can tag congestion notifi= cation as > > > > >>>>> =E2=80=9Ctransport-header-dependent=E2=80=9D. There are ways = to pass that info even > > > > when > > > > >>>>> the transport encap changes. > > > > >>>>> > > > > >>>>> This is IMHO among things that the WG is supposed to cover un= der > > this > > > > >>>>> item in the charter (please note that those are clearing tage= d as > > > > >>>>> transport issues): > > > > >>>>> > > > > >>>>> =3D=3D > > > > >>>>> > > > > >>>>> 4) Transport Considerations - This will capture the expectati= ons > > SFC > > > > >>>>> places on transport behavior, including dealing with issues s= uch as > > > > >>>>> congestion indications and responses. > > > > >>>>> > > > > >>>>> =3D=3D > > > > >>>>> > > > > >>>>> Cheers, > > > > >>>>> > > > > >>>>> Andy > > > > >>>>> > > > > >>>>> On Thu, Jan 17, 2019 at 10:02 AM > > > >>>>> > wrote: > > > > >>>>> > > > > >>>>> Hi Andy, > > > > >>>>> > > > > >>>>> Please see inline. > > > > >>>>> > > > > >>>>> Cheers, > > > > >>>>> > > > > >>>>> Med > > > > >>>>> > > > > >>>>> *De :*Andrew G. Malis [mailto:agmalis@gmail.com > > > > >>>>> ] > > > > >>>>> *Envoy=C3=A9 :* jeudi 17 janvier 2019 15:50 > > > > >>>>> *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > > > > >>>>> *Cc :* IETF Secretariat; sfc-chairs@ietf.org > > > > >>>>> ; > > > > >>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org > > > > >>>>> ; > > > > sfc@ietf.org > > > > >>>>> > > > > >>>>> *Objet :* Re: [sfc] The SFC WG has placed > > > > >>>>> draft-eastlake-sfc-nsh-ecn-support in state "Candidate = for WG > > > > >> Adoption" > > > > >>>>> > > > > >>>>> Med, > > > > >>>>> > > > > >>>>> Not all transports support ECN marking, for example NSH= over > > > > MPLS. > > > > >>>>> > > > > >>>>> [Med] Isn=E2=80=99t this covered by RFC5129? > > > > >>>>> > > > > >>>>> And even where the transport supports ECN marking, note= the > > > > example > > > > >>>>> in Figure 1 in the draft where the outer encapsulation = can be > > > > >>>>> stripped during SFF processing. In that case, the scope= of > > the > > > > ECN > > > > >>>>> marking is limited to individual SFF-SFF links. rather = than > > end- > > > > to- > > > > >> end. > > > > >>>>> > > > > >>>>> [Med] Why couldn=E2=80=99t SFF preserve ECN when doing = its transport > > > > >>>>> decap/encap? > > > > >>>>> > > > > >>>>> Cheers, > > > > >>>>> > > > > >>>>> Andy > > > > >>>>> > > > > >>>>> On Thu, Jan 17, 2019 at 9:12 AM > > > >>>>> > wrote: > > > > >>>>> > > > > >>>>> Hi all, > > > > >>>>> > > > > >>>>> I do think that ECN is naturally better handled at = the > > > > transport > > > > >>>>> encapsulation instead of the NSH itself. > > > > >>>>> > > > > >>>>> Requiring the functionality to be handled at the > > transport > > > > encap > > > > >>>>> (draft-ietf-tsvwg-rfc6040update-shim) and NSH is > > redundant, > > > > IMO. > > > > >>>>> > > > > >>>>> I like the approach we set in the SFC architecture = in > > which > > > > we > > > > >>>>> separated service matters from transport ones. I'd = vote > > for > > > > >>>>> maintaining that separation cleaner as it was set i= n the > > arch > > > > >> RFC. > > > > >>>>> > > > > >>>>> Thank you. > > > > >>>>> > > > > >>>>> Cheers, > > > > >>>>> Med > > > > >>>>> > > > > >>>>> > -----Message d'origine----- > > > > >>>>> > De : sfc [mailto:sfc-bounces@ietf.org > > > > >>>>> ] De la part de IETF > > Secretariat > > > > >>>>> > Envoy=C3=A9 : jeudi 3 janvier 2019 06:11 > > > > >>>>> > =C3=80 : sfc-chairs@ietf.org ; > > > > >>>>> draft-eastlake-sfc-nsh-ecn-support@ietf.org > > > > >>>>> ; > > > > >>>>> > sfc@ietf.org > > > > >>>>> > Objet : [sfc] The SFC WG has placed > > > > >>>>> draft-eastlake-sfc-nsh-ecn-support in > > > > >>>>> > state "Candidate for WG Adoption" > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > The SFC WG has placed draft-eastlake-sfc-nsh-ecn= - > > support > > > > in > > > > >>>> state > > > > >>>>> > Candidate for WG Adoption (entered by Joel Halpe= rn) > > > > >>>>> > > > > > >>>>> > The document is available at > > > > >>>>> > > > > > >>>>> https://datatracker.ietf.org/doc/draft-eastlake-sfc= -nsh- > > ecn- > > > > >>>> support/ > > > > >>>>> > > > > > >>>>> > Comment: > > > > >>>>> > This starts the WG call for adoption of this dra= ft. > > > > >>>>> > Please respond to the list, indicating support f= or > > this as > > > > a > > > > >>>>> work item of the > > > > >>>>> > working group with this document as the basis fo= r the > > > > work, > > > > >>>>> or objection to > > > > >>>>> > the working group adopting this item as a workin= g > > group > > > > >> draft. > > > > >>>>> > > > > > >>>>> > The authors should confirm to the chairs and WG > > secretary > > > > >>>>> that all IPR known > > > > >>>>> > to them relevant to this draft has been disclose= d. > > > > >>>>> > > > > > >>>>> > The working group adoption call will last 2 week= s, > > ending > > > > at > > > > >>>>> the end of the > > > > >>>>> > day on Thursday, January 17 2019 COB somewhere. > > > > >>>>> > > > > > >>>>> > Thank you, > > > > >>>>> > Joel > > > > >>>>> > > > > > >>>>> > _______________________________________________ > > > > >>>>> > sfc mailing list > > > > >>>>> > sfc@ietf.org > > > > >>>>> > https://www.ietf.org/mailman/listinfo/sfc > > > > >>>>>